The Evolution of JavaScript - AiA 390

Marek Panti is an Angular developer at UNIQA Insurance Group AG. They dive into the world of artificial intelligence and its impact on developers, exploring the future of JavaScript and UI design, and delving into the evolution of JavaScript frameworks. Additionally, they discuss the challenges faced by front-end developers, the complexities of back-end development, and the ongoing debate on front-end vs. back-end salaries. Marek also shares insights from their own project, giving us a glimpse into the intricate world of calendar development.

Hosted by: Lucas Paganini
Special Guests: Marek Panti
RSS Spotify Apple Podcasts YouTube Amazon Music

Show Notes

Marek Panti is an Angular developer at UNIQA Insurance Group AG. They dive into the world of artificial intelligence and its impact on developers, exploring the future of JavaScript and UI design, and delving into the evolution of JavaScript frameworks. Additionally, they discuss the challenges faced by front-end developers, the complexities of back-end development, and the ongoing debate on front-end vs. back-end salaries. Marek also shares insights from their own project, giving us a glimpse into the intricate world of calendar development. 

On YouTube

Sponsors


Links

  • Unvoid - Angular Experts - Design and web development services with enormous expertise in Angular for companies that truly care about quality https://unvoid.com/

Social Media

Transcript


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
 
which offers remote design and web development services with specialization in Angular for companies that truly care about quality. In today's episode, we'll talk about the evolution of JavaScript. My name is Lucas Paganini. I am the CEO of Envoyed and your host in the podcast. And joining me in today's episode is Marek Pentti.
 
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)
Thank you for joining. Marek, he's been in the show before, so I highly recommend that you also check out the episode that we had with him previously, which was fantastic too. So Marek, thank you for being back on the show, and let's get into it. So I suppose we should start with, what do we mean by the evolution of JavaScript?
 
Marek Panti (01:23.506)
Yeah, this is actually very interesting topic because this topic came to my mind when I did some courses for backend developers and they view on JavaScript is like a little bit superficial yet they looked on it like how it was that language that doesn't have types. How does it work? How it's possible that you can do an addition of
 
string and a number and when you do a minus, it's something else. And how is it like that they are basically laughing at it or they were. And I started to do a lot of investigation about the JavaScript past, yeah. So I think everything started in around at the end of 90s basically. If you remember there was like before the
 
web interaction or when web interaction started, there was a flash and the flash was using action script. And I actually didn't find some article that's connected JavaScript to action script. But when you look on the first JavaScript, it looks exactly the same as action script. You were able to create some games in the action script and then you had...
 
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...
 
data as you need it, and then you can just map your async generator to another async generator and then you have this entire stream of things that the last one pulls and then pulls from the previous ones and goes up until the first and then you have this very, very memory efficient program. So it's amazing how much we can do with JavaScript nowadays.
 
Marek Panti (04:23.028)
Yes.
 
Lucas Paganini (04:28.655)
So yes, I believe this is a very, very interesting topic. So yeah, let's get into it. So where do we start? Because if we really take it from the absolute beginning of JavaScript, then I'm not even sure if we can fit that in 24 hours.
 
Marek Panti (04:48.978)
Yeah, yeah. I would actually start maybe from the generators, as you mentioned, because what is still wrong about JavaScript? I think it's documentation, because when I talk with Meet developer in frontend and I ask him a simple question, if he knows how the stack in the runtime works.
 
and what is the event loop in JavaScript. Usually they even don't know the term, what does it mean? When I show them that you can actually see the stack and the queues in a browser, they start to realize, aha, they have this aha moment. And this is one of the issues because we have a lot of documentation and a lot of tutorials from the old world, let's say.
 
And I think this can be the starting point that how one person can learn JavaScript now without going to the old concept. And the first idea is that, the first idea is that in the past, you had only a static websites. There wasn't even Ajax, there wasn't even a server communication, but in...
 
In some time after the static websites, we wanted to have some flashing button or some animation going on And this was the purpose of JavaScript. And also this is the reason why JavaScript was very simple It wasn't mentioned like the language itself. It wasn't mentioned to do a big things Its its purpose was to create Two to ten lines of code and that's it and run some animation. Yeah
 
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)
from C and then so on. But then the Ajax came and it was like first protocol via web and the server that was official and that was integrated by browsers. And this is the point where the things started to be a little bit different. And also this is the point where the JavaScript started to be used for something it hasn't been...
 
it hasn't been built at the beginning. So those are also the following reasons why we had a lot of concepts and a lot of hacky things such as closures in JavaScript, such as immediately invoked functions. And then also another topic is JavaScript canvas that was inbuilt later on. And it started to be quite complicated. And
 
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)
And I wouldn't just say that it's about the JavaScript language in isolation, but also the JavaScript ecosystem. For example, nowadays you can very easily install libraries that are going to give you all the functionalities that you want. And then I'm not saying that I, that that's the part that we could go on, but
 
Marek Panti (09:38.424)
Yes.
 
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.
 
nowadays that would allow you to build this chat application in like one week if you're willing to just do it with the solutions that are already existent instead of trying to code your own from scratch. So yeah, it's crazy the amount of things that we can do nowadays in a short period of time using JavaScript.
 
Marek Panti (11:10.494)
Yeah, exactly. And now I would like, I would continue also with the end or with the JavaScript nowadays, then I will come back. So basically with the frameworks, what is the funny thing is that before there was React, Angular, View, Svelte. Now we have a Quik that is very good. But my feeling is that...
 
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.
 
And it's doing basically the same, but without mutating the original array. And for my brain, I was always a little bit unhappy when I was using filter for not filtering, but for removing an item from an array because methodologically filter is not used to that is used to filter things. Yeah. So basically JavaScript improved even things like this. And now I will go back to the past.
 
Lucas Paganini (14:15.727)
Mm-hmm.
 
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
 
after the frameworks were introduced, yeah, when AngularJS died, new Angular started to use TypeScript, for example. So now you had evolution of JavaScript and evolution of the ecosystem. And from with today's eyes, this is again, old technology and primitive technology and has nothing and easy, but in that moment you had
 
TypeScript that was compiled to JavaScript. Then you had to have polyfills and you had to still think about compatibility with Internet Explorer and so on. And you had all those tools that did it for you. And also server side rendering started. So there were so many topics that came just like this. Also, that was the moment where
 
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)
Yes.
 
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.
 
So basically imagine that you have a web app. Yeah, now when you have a new component, you write new class and new class is basically a separated scope. But before, imagine you have just index HTML and you'll have a script tag. And your scope was in the script tag of the index HTML. So even if you separated it into some smaller JavaScript files,
 
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...
 
If you had 10 times var name, it was in one scope of the index HTML. So there was some fight between the variables, yeah? So there was a hack how to create a scope without the class because JavaScript wasn't all OOP. And it is a immediately invoked function. It's actually function that is immediately invoked.
 
Marek Panti (21:27.858)
And the scope is only within that function. And AngularJS components were basically under the hood. It was a lot of, immediately involved functions because of the scope. And it's again, it's again, the issue from the old time that JavaScript wasn't meant to do such application at the beginning. But this is also part of the evolution. And I think this is the biggest reason why.
 
Lucas Paganini (21:48.311)
Mm-hmm.
 
Marek Panti (21:56.886)
why some backend developers were laughing at the JavaScript.
 
Marek Panti (22:02.97)
even me, yeah. But now it's completely different, but it's also more complex because beside those rules and if you forget about tooling, if you forget about everything else and we look only on browser and JavaScript, today we can have progressive web apps. And when you take progressive web apps that you basically cache,
 
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)
Yeah.
 
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)
Yeah.
 
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)
Exactly, exactly.
 
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)
Uh huh.
 
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)
Yeah, I completely agree. And I think the reason for this is also now in the past, where in the past frontend developer, his responsibility was to get the PSD file to create HTML, CSS, and maybe some JavaScript. And basically that was it. It was only pure programming. And
 
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.
 
it's hard to explain and also when you have a Node.js, the runtime of the JavaScript is a little bit different than in the browser. And so we have a lot of things to think about. And the reason why the Node.js or the JavaScript is a little bit different than the backend are two small details, yeah, because JavaScript is still a functional language. When you have someone from Java world and...
 
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)
Yeah. And what comes after that? Do you have any other points that you think would be relevant to bring in terms of the evolution of JavaScript?
 
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...
 
it cannot grasp the whole complexity, but it's very useful for small functions and for testing if you know how to use it properly. It's very useful for Regex, for example, and for write unit tests. And now in terms of the future development or future points with the JavaScript.
 
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)
Yes.
 
Marek Panti (35:21.098)
Yeah, I agree.
 
Marek Panti (35:33.17)
Mm-hmm.
 
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 now the question is how you should optimize your system or how the front and architecture should look like. And again, I just want to remind to everyone who is listening to this, you should really concentrate on the MVP. So basically your HTML in whatever framework, even in vanilla JavaScript, your HTML should be as pure as possible. And you should have some layer such let's call it facade.
 
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)
Yes.
 
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)
Well, it was a lot. I think there are still countless hours for us to talk about new things in JavaScript and how the language has evolved in the ecosystem too. But I think we should probably start wrapping up just because we're close to 40 minutes already. But do you think there's anything in particular that...
 
should be mentioned before we wrap things up.
 
Marek Panti (39:59.958)
Yeah, I think definitely we can mention, we can mention var and var-leden-const. For someone who is just starting learning JavaScript and when you see in your tutorial that there is used var in some example, just close it and find something else. Basically, you shouldn't... For a person who is learning JavaScript from scratch, you should be looking just for...
 
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
 
When you start build the components in JavaScript, it becomes really crazy. It's start to be similar to low level programming.
 
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)
Definitely.
 
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.
 
Album Art
The Evolution of JavaScript - AiA 390
0:00
44:38
Playback Speed: