Lucas Paganini (00:01.903)
Hello, welcome to Adventures in Angular, the podcast where we keep you updated on all things Angular related. This show is produced by two companies, Top End Devs and Unvoid. Top End Devs is where we create top end devs who get top end pay and recognition while working on interesting problems and making meaningful community contributions. And Unvoid
Marek Panti (00:49.907)
Hi, thank you, Lucas, for the invitation. I'm very happy to attend this podcast.
Lucas Paganini (00:56.559)
Marek Panti (01:23.506)
some vector objects and we're moving it in some square. So this is the idea.
Lucas Paganini (03:02.339)
and nowadays it's a much more complete language. But by the way, I've been using something that has been in the language for a while, but I wasn't actually using it in production yet, but I've been using this technique for the past three weeks on a project that we're working on at Envoyed, and I was blown away with how easy it is, and I'm talking about async generators.
Generators in general were a feature that people are like, oh yeah, that function with an asterisk exists, but let's just forget about it. But I'm actually using it a lot to do a background synchronization process. And it is extremely easy to deal with back pressure because you can just pull...
Marek Panti (04:23.028)
Lucas Paganini (04:28.655)
Marek Panti (04:48.978)
but as a computer and hardware progressed and internet was faster, we started to have a server communication. And the server communication at its beginning was looking like that, that you press the button and the whole page was refreshed. Yeah, but everyone realized that this is no way to go. So there were, I don't want to mention the concept before Ajax, but there were some concepts from Java, some concepts.
Marek Panti (07:08.49)
Right now we are talking about 2004, let's say. And this is the year where MySpace started. And three years later there was Facebook and each of those big websites were actually applications. They had their own front end and their own idea of how the things should be connected to each other. And it was really crazy because when you went from one company to another,
completely different job because everyone thought about it differently. And also it was a time where I think every country in Europe or in every continent had its own chat application. And this chat application was quite on top. It was actually before Facebook. Yeah. But it was on top of the country list.
And then when you look from today's eyes on those applications, they were very easy. Like now I think we would be able to develop it in two months, but before as there were no concept, nothing it was job for three years. So this is the difference. Now we have a new complexity here.
Lucas Paganini (09:28.831)
Marek Panti (09:38.424)
Lucas Paganini (09:54.531)
I think that might be another show, which is when to install another library, when to do it yourself, because I think there's a line to draw. Sometimes people just install too many dependencies and, and I'm not even talking about this from the side of, oh, it's gonna, the bundle is gonna be too big. Like, it's not just about that, although that could be a something to, to think about, but, um,
mostly from the side of your installing code that although it does what you seemingly wanted to do, you don't actually understand how it does that. So it might be introducing security issues in your code base or maybe just unperformant code. So yeah, but anyways, there's this entire ecosystem of things.
Marek Panti (11:10.494)
the gap between the frameworks started to be lower and lower because Angular adapted signals and standalone components. Vue and Solid.js had it before, but they didn't have the time to have a big user base. So in my opinion, in some time, there will be maybe only Angular, Quick and React.
because the differences between the frameworks will disappear. And it's also now, it's good and a bad. The good thing is that now we have standard, because signals, they finally, it's basically a final rendering solution because React in the past, they had a virtual DOM and Angular had the zone.js and change detection. But none of these was a good and optimal solution because
When you do some change with the data, you want to see just this change in the view. You don't want to wait until something happens somewhere. Basically, signals is the solution, right? And signals is one of the examples that shows us some direction that the front end is becoming more and more unified. There are unified solutions to some problems that before were maybe opiated.
that is really a good direction. And also the tooling, I think the TypeScript and Dart are the way to go. Before it wasn't like this. And also there are some other stuff with ECMAScript. For example, this year ECMAScript introduced new functions that I personally was missing because, for example, before when you wanted to add
Marek Panti (13:33.49)
a new item to the array or remove an item to the array, you were always mutating the original array. But if you wanted to do it without mutating the array, you had to manually copy the array and add or remove that item. Or you could of course use a filter or map method. But now they introduce slice at. Yeah, so before you had only slice method. Now you have slice at.
Lucas Paganini (14:15.727)
Marek Panti (14:29.174)
So I stopped talking about the year 2004 about a lot of frameworks and so on. And when we started in the moment, I think around 2007 or eight, whenever we had smartphones, we had so many websites and so on, there became some feeling that the front end needs to have some unification. The first real framework was AngularJS. But...
First framework is something like the first car. You don't really remember the first brand. Everyone remembers Ford, yeah, because Ford, it wasn't the first car. First car was even in somewhere in 19th century, but it was undeveloped and something like that was unglourgious. It just brought a concept and it shows how things could be done. Then basically React quite overtook it because React changed.
a lot of things that Angular did not see before and they started from scratch. And after some time, Angular had to completely remove their old project and start from scratch again. I think it was a good idea and quite clever. And this is, I think this point, it was, it was around 2008. And this is the point where frontend started to be more and more complex. Because
Marek Panti (16:51.126)
microservice and APIs started to evolve more and more. And it's funny because this year, now I will also talk a little bit about this now. This year, as there is this war and everything, the prices for server are very big. And companies started again to dump
the clouds and started to have their own servers. And there is now discussions whether we shouldn't go back to monolith or maybe there should be some part, some monolithic part and only small part of APIs. And I think this is also a good way because only monolith and only APIs are a bit extreme. But we needed to work to see what is optimal. Yeah, and this is quite a funny story.
Lucas Paganini (17:49.075)
Yeah, man, the web in general, it's funny that we kept evolving in a direction, but sometimes I feel like the whole world doesn't stop to ask, should we go in this direction? It's kind of like what happened with serverless functions. They are incredibly useful. I love the idea of serverless computing. I would happily work on a project.
with an API entirely serverless, but you have to be aware of the trade-offs. Like I was talking to a company the other day and they were talking about some of the challenges that they were facing going serverless. And one of them was actually something that it's obvious once you realize, but it's not so obvious if you're just thinking about serverless, which is every request is gonna create a new connection to the database.
So the database also has a limit of connections. So sometimes it's like you tried to break the application in to so many small pieces that in some point it actually introduces more complexity than it solves. Yes.
Marek Panti (18:47.766)
Marek Panti (19:10.159)
Exactly. And I think this is one of the things that we can call a craftsmanship. Yeah, because you cannot have real rules of how to develop something. You need to have enough experience. And basically, once you get that experience, it's like in the old times that...
the old senior guys has these craftsmanship and he can sell it to a new generation basically. And it was really can see the, even in the software development itself during the last 12 years. This is exactly funny. And now I would like to talk about a funny thing called immediately involved functions to bring some concrete example.
it was always connected to the index HTML and its scope. So now take this, you want to, you have whatever route you are on, on 80% you have var name, because in each project, in each component, usually you have something that is var name. Yeah, now let, but before it was var name. But...
Marek Panti (21:27.858)
Lucas Paganini (21:48.311)
Marek Panti (21:56.886)
Marek Panti (22:02.97)
everything that is loaded on the browser. Then you have a browser database and you have also local storage. Now you can think what should be stored and what should be online when the communication between offline and online can happen. This is also part of the complexity. But now we have another topic that is
that naturally, five years ago, I had an array with, I don't know, 1 million items. And usually it had to be filtered, sorted on server because in front of it would be complicated or it could crash. But now with WebAssembly, we can control what is rendered.
or what is run by browser or directly by our hardware of our computer. And the next topic in next five years could be CSS rendering. Imagine if CSS wouldn't be rendered by browser but by hardware itself. Because CSS I think is one of the thing which will stay with us because it's one of the best position language, I would say.
but the browser is slow. If you have, imagine if you have a table with 5,000 items, the rendering can become slow, yeah, if you have some older computer. But if you would have CSS rendering not on a browser level, but on a hardware, then it would be fast, it would be crazy. And I think this is the direction where front-end is going through.
Marek Panti (24:26.762)
But there is also another topic and that complexity bring us to issue that frontend, like the general frontend is now more complicated than backend if we are not talking about low coding. Because on frontend you have a lot of complexity, a lot of layers and also creation of UI components. Then you basically
when you do some date picker, calendar, you have to think about responsibility, about touch, click, keyboard events, about focus. And then you need to think about all browsers and also need to think about accessibility. So, and when you connect all of these two together, this is crazy.
Lucas Paganini (25:26.347)
Yeah, a lot of power, but a lot of complexity too. But I kind of like that. I think that front-end developers should have more power because for a long time, CPU heavy stuff would, or just not even CPU heavy stuff, but like basically there are protocols that we couldn't run on the front end. So we had to delegate such things to the backend.
Marek Panti (25:31.254)
Lucas Paganini (25:55.287)
And nowadays, I think there's still this notion that the back-end engineer is somehow smarter than the front-end engineer because they have to deal with more complexity. And I'm not going to take away the... I can't generalize that for sure, but I do know that in general...
Marek Panti (26:09.366)
Lucas Paganini (26:24.527)
the backend is a bigger responsibility than the frontend. I wouldn't say that it's necessarily more complex, but just the fact that the frontend can be killed and spun up again and no problem, like we're not holding your data, that's like a major win for frontend developers in terms of making the process easier.
If you're the backend developer, then you can have nightmares thinking that the database went down and you don't have backups, for example. So it's, yeah, it's more responsibility if you look at it that way. But I don't like how most companies think that the backend engineers somehow necessarily deal with more complexity than the front end engineers.
Marek Panti (27:01.998)
Lucas Paganini (27:22.783)
I think there's a lot that can be done in the front end nowadays. And I think there are a lot of applications taking advantage of that. So if you're really stretching up the possibilities of your front end framework, then you're probably doing something very complex in the front end. Something that if you just get a senior and senior backend engineer to look at, they might not be able to figure their way.
and quickly. So, yeah, I do like the power. I just hope that the industry overall realizes that and increases their market value for front-end developers accordingly, because there is a noticeable gap between salaries from front-end and back-end engineers nowadays.
Marek Panti (27:53.217)
Lucas Paganini (28:21.711)
And I think it should be smaller. I wouldn't say that it shouldn't exist, but I think it should be smaller.
Marek Panti (28:31.05)
Nowadays it's really about engineering stuff. But I think a lot of companies started to realize it because before you had usually one tag lead per team or in company who was responsible for some direction. And now I saw a lot of companies had a special, they had special front end tag lead and back end tag lead because
one person is no more able to grasp everything. Also, it's not all because a front-end taglet can decide that some smaller backend stuff could be done in Node.js. And now you need to decide on questions whether you should have a monorepo, separated applications.
how the models could communicate if you have some third party and that backend for front-end in Node.js is connected to the third party. This is also some, like Sam would say, it's a backend work, but I think that this Node.js is becoming more, integrated more and more into the front-end sort of, I don't know.
Marek Panti (30:49.002)
he comes to, let's say he jumps into the Angular and then you look on his code and suddenly you see there are classes everywhere. And there are classes for things that should be interfaces, for example. And he does a lot of, or RxJS and streams. It also requires some knowledge because, for example, operator tap.
Operator tab is an operator that returns the original stream. And it should be used only for, basically only for debugging. Yeah. Instead it's better to use map. Yeah. And backend developer usually from my experience is using a tab and because he don't know what is behind or what is behind the scenes.
Lucas Paganini (31:45.443)
Yep, yep, I've seen that.
Lucas Paganini (31:53.65)
Marek Panti (32:08.258)
Definitely. Maybe before I would get to this point, I would like to mention ChetGPT and Copilot because there was also a question whether this ChetGPT or Copilot could replace developers in general and even I started to have fear for two weeks.
But when I saw how many mistakes it does and also, I don't know how it's possible, but I think three or four weeks ago there was a study that chat GPT is now a little bit stupider than before. The new model, I mean, it's also true. And I think they did it on purpose. So you would have to buy the full license or something like this. But...
I think, personally, I think the future will be, will add us more and more complexity. And personally, I think that there will be something with the UI in terms of nowadays, the UI is very simple and a flood design gain its popularity or material or how we call it. But I think
that something will happen like in 2000, because there was a small gap from 2005 until 2008 where the websites started to look really beautiful and each website was like an art. But when a smartphone came, we started to do a responsive websites and the flat design was very popular and it's still somehow popular. And I think we will have animation.
Marek Panti (34:28.894)
and I think called Game Experience. It started to be popular this year. Game Experience is basically something what you saw on Udemy or on some learning classes there when you had some badges, when you did something successful and you received some plus. So I think gamification would be a next part of
of user experience, but it will also add a new layer of complexity.
Marek Panti (35:07.366)
or an ordinate.
Lucas Paganini (35:07.683)
I'm personally, yeah, I'm personally excited about this complexity. I like the idea of building systems that have designed gamification. But there's a little bit of, ethical worries about that because sometimes I think gamification makes people addicted to the wrong things. But, but overall I think.
Marek Panti (35:14.498)
Marek Panti (35:21.098)
Yeah, I agree.
Marek Panti (35:33.17)
Lucas Paganini (35:36.799)
Yeah, it works and it makes the experience more, it can make the experience more enjoyable.
Marek Panti (35:43.218)
Yeah, exactly. And next point, it just came in is, when we were talking about those changes, now one can imagine how it's possible that your application is still running on the most modern version with the most modern system and with a readable code.
This is one of the topics why so many projects failed because there are also a lot of projects that weren't prepared for the change. And they still, they said, we will use the old system, we won't accommodate because we are too big and we are not able to do the change. But with that decision came a lot of problems. And after some time, usually it was five years after, after that time, they needed to start from scratch.
And that facade will take care of the logic. So when some refactoring will come in the future, we will do it only in the facade. You won't have to touch all of your files. This is, this is really important note.
Lucas Paganini (37:29.112)
Yeah, that's a pattern I've been using for a lot of things, actually. Even just to simplify classes that expose too many methods and too many properties. Like most times, for example, you're using a library and, for example, data stores. So you're using NGRX, for example.
Marek Panti (37:52.683)
Lucas Paganini (37:55.279)
they expose just so many things if you're using NGRX data. For example, there are just so many methods and properties and you don't always want to expose all that to the clients that are gonna consume that. So you can always just have a facade that simplifies the interaction with this massive object.
Marek Panti (38:18.266)
Exactly. And this also, I will say, I will tell an example. We have now signals, yeah? And let's say that you decide you want to remove NGRX or store and use just the signals. And if you have a facade, the change is quite easy. Because
At first point, you can use just to signal in the first step. It's a method that converts observable to signal. Then you can change the logic inside some RxJS pipe with computed and you can update it step by step. But if you have everything in a component or everything together in some files, you...
It won't be possible. We would need to start from scratch. And there were so many examples in the past where this pattern helped. So just as a reminder.
Lucas Paganini (39:28.295)
should be mentioned before we wrap things up.
Marek Panti (39:59.958)
maybe maximum five years old tutorials, I would say. You shouldn't really go to the past because now it's not really necessary to know how it was before. You can learn it afterwards, but it could be very confusing.
Lucas Paganini (40:52.92)
Yep. Okay. Mark, do you have anything that you would like to promote? Any project that you're doing, anything that's happening and you would like to shamelessly advertise?
Marek Panti (41:09.69)
Yes, I have or I might have in a couple of months. I work currently I work on a startup called Sayre. It's a reservation system, quite complex where you will be able to create a company, your structure, your employees. And then when you have clients and your clients have some appointments, your employees are able to create a calendar and your and the client is able to appoint.
to do an appointment for whatever he needs. And it's gonna be quite complex and it will start, the first beta version will start in January next year. And I was working on a calendar and I decided that I don't want to use any library for the calendar. And I spent four months on a calendar.
because I didn't realize how complex a calendar can be just from the visual point of view. And it's funny because then I realized why so many calendars are paid, because you need a very specific algorithm that shows events in a column between and you have all of these things. So this is this low-level UI or
Lucas Paganini (42:45.955)
Yeah, that's really interesting because creating such components...
Marek Panti (42:47.586)
but I don't have link to the project yet because...
Lucas Paganini (42:54.607)
Sorry, go ahead.
Marek Panti (42:54.919)
Marek Panti (42:58.523)
Yeah, I just wanted to say that I don't have the link for the project because it will be online in January. Now it's still only in demo, sorry, in development version.
Lucas Paganini (43:13.607)
Just to simplify my own understanding of this project, I might be wrong, but would you say that's kind of like... How does that differ from, for example, a more popular booking system such as Calendly, for example, that I think should be familiar to a lot of people?
Marek Panti (43:38.886)
Yeah, the difference is that in Calendly, you have usually only functionality of the calendar itself, which is done, which is made for a different purpose than ours. Yeah, Calendly is done for appointments, that you can share the appointment and you can create free slots. And Sayre would be for organizations such as, let's say you have a gym.
And the gym has a regular event such as fitness at 6 p.m. every Tuesday, but also they have a trainer's and you can do appointment directly with the trainer on a random date when he has free slots. So the use case is very, very variable. It can be also used in a healthcare to create an appointment to the doctor. And from the point of view from the organization,
they will have their time list. They will be able to write with their clients and so on.
Lucas Paganini (44:44.175)
Got you. Interesting. Nice. Well, from my end, I'm gonna promote my company, Unvoid. So, if you're looking for a company to help you develop an application, or you're looking for training, or just staff augmentation, like you don't really want to fully outsource the project, but you would like to bring on external...
contractors to help you on your project on a specific need or for a specific time, then be sure to check out Envoy.com. And yeah, so that's going to be my promo for today.
Marek Panti (45:29.006)
Thank you very much.
Lucas Paganini (45:32.471)
Yes, thanks Mark and I'll see you in the next one.
Marek Panti (45:37.282)
Thank you very much.