 Alex, and I'm here to talk to you about Svelte. So yeah, has anyone heard of Svelte in the audience? Okay, and how many of you people have actually used Svelte at all? No, so that's good, that makes my job easier, right? So Svelte, yeah, we'll see a bit more about it. So this is me, I'm Alex, front-end developer at Hook, and I've lived in Singapore for about four years now. Some of you may remember me from my GraphQL talk a few months ago, and then also I've been to a few of the meetups as well, so this is me. Okay, so this is a bit of an overview of what we're gonna be going through. Gonna be looking at front-end frameworks, then we've got a bit more into Svelte itself. So front-end frameworks, a little bit of a history comes down to we started with jQuery. We now all hate jQuery, but back in the early 2000s, everyone loved jQuery. So JavaScript has evolved a lot over these past, yeah, like 15 years. Now our APIs are way better, and we're expecting more, and this is where things like AngularJS came. This was really the big changing moment in front-end frameworks, and I think most people here probably used AngularJS to some level before moving on to the more modern frameworks, which you have at the bottom. So generally, I spent most of my time with React, but I have had some experience with Angular as well, and then view is quite nice. So I guess in the audience, as everyone used one of these three modern frameworks, yeah, okay, and how many people have actually used View? Okay, that's also good, so that'll be relevant. So the other question is, why do we care about framework? So we all use frameworks with JavaScript, but why? So they don't have any good answer for me as to why you want to use a framework yourself, yeah? So we include spaghetti. Yes, that definitely is one of the problems with JavaScript. So yeah, it's, can be an organizational tool is one of the things we can do with it. Anyone else, anyone else who uses frameworks feels that it's better than vanilla JavaScript? To make everyone follow the same path. Okay, yeah, so like on big projects, especially JavaScript is very, very flexible, which we love from time to time, but we also hate more often than we love. So obviously a frameworks, especially ones like Angular, really enforce a certain style, react to a bit less so, so not always with React, I think. But yeah, there's a lot of reasons we use frameworks. That's some good ones. There's also a lot of additional power that we get given by the developer of these frameworks. Okay, so this is probably one of the reasons why we use it because JavaScript often makes no sense. We have very interesting uses of the double equal sign, which is also why we avoid the double equal sign. But yeah, JavaScript, it can be a really weird language where stuff doesn't make sense. Okay, so Svelte, what really is Svelte? Svelte is a front-end framework, but it's not like the rest. It's a bit different. It's actually compiler. So Svelte will compile your code. You write it in Svelte format. It will compile it down to a bundle. Then we use, the same way you use any other bundle, you just put it in and it will play as normal. That's what's quite nice about Svelte. It's low dependency, pretty quick, and then also the bundle sizes tend to be very tiny. So it's a brand new approach to frameworks because the other three, and then frameworks before that, what much more dependency-based, dependency-orientated, you had to get libraries and install everything. Could be a hassle, it's hard to upgrade. Svelte kind of centralizes it into more of a compiler. And it's a really good idea. That's kind of surprising. No one's really thought about it in the past. So yeah, it's a new approach. It was also from Rich Harris of the New York Times. So he's pretty much the main driving force behind it. Kind of like with Vue, it's pretty much a one-man team. They have some other people that helps out, but it's very much a passion project that you can see that he's really pushing it across the thing. And it started in the late 2016s, and we're currently on version three. Version two to three had some big changes. So that kind of made a lot of improvements over what it was doing previously. But Svelte really is starting to get a bit more traction in certain areas, but it's still very new. So yeah, it is compiled JavaScript. So one of the main benefits we get from compiling it is we get these tiny bundle size, which is really helpful when we care about how big these libraries are getting, especially things like Angular is massive. And even React these days, like React DOM is also a very big dependency to include. So this can really help when you have very critical speeds that you want your networks to be achieving. Yeah, also because it's a compiler, you can do better error tracing, because again, as we know, JavaScript, the type errors for everything never really helps. The load dependency is another huge bonus that we get. And you can get the extra efficiency because you're not requiring a library to kind of interpret the APIs that you're writing. It's going directly to vanilla JavaScript. So the bundle itself is just down to vanilla JavaScript. It'll work everywhere with every browser. Yes, I guess the other question which I didn't actually answer was what does Svelte mean? So Svelte is a French word, and it just means slim or small. And that's kind of very reflecting in the actual technology itself. So some of the technology it uses observables, partly for the way it's storing data, which is actually quite nice, similar to what Angular does, but then the actual structure is very resembling of view. So that's also why I asked who's using a view, because when I show the code, I think in the next slide, you will see it is a very similar format to view. So that often will turn off a lot of developers, especially React developers, because React and view are very different. But yeah, the version three does help to reduce boilerplate a lot. So one of the big things was, version three changed the way that the kind of the state was handled. So it means that it will actually update variables on the fly without having to require additional requests, which has been a lot better. And it's kind of the way that React has also gone, they've kind of streamlined some of their processes. Okay, so the code, the general style is like this. You have a script at the top, a style, and then you have your HTML at the bottom. Unlike React, the HTML doesn't have to be one object. There can be many objects here. That's one of the big differences. Then on top of this, we basically just have our scripting here. So this is very similar to view in the general look of it. You kind of put everything into one place. And I think you get a lot of opinions on both sides. Some people love it, some people hate it, and especially if you're more used to things like React, it's probably quite a worry. So yeah, there's a lot of things you can do. This one, you also have the lifecycle hooks. So this is similar to what we have in React in general. So we have the things like the on mount on destroy. This reacts similar to lifecycle hooks that we get in React. Then we also, this one is basically use of a store to store data in memory in a similar way to you would use redux in React. Using observables instead in this situation. So it's a little bit more, it's less opinionated. So this kind of comes down to developer themselves and the discipline they have. Then we just have our styling and our HTML tech. So a little bit more detailed code where we kind of breaking it down into the script and the HTML. So the HTML does have similar attributes that you get in view and in Angular. So you're getting things like, you're putting the each over here instead into their own declarative ways. And then you have the curly braces to insert the variables that you want. So it kind of mixes the languages together or mix the frameworks together a little bit and it produces something that is a little bit different but at the same time I think it's quite accessible to anybody who has worked with any of the other frameworks in the past. It provides, usually you can get quite a lot done with not writing too much boilerplate as well which is a nice thing with it and then just the stylings in general. Okay, so generally one of the things we've felt is it's a very, very new technology. It's not really been taken up massively by any one company. You see in a few small areas, I guess the biggest companies like New York Times and GoDaddy which apparently use it in some areas but it's still not hugely used currently in those. Yeah, one of the big things that people like about it is the tiny bundling you can get out of it which is really nice compared to, because that's one of the things oftentimes people complain about with a lot of these other frameworks is the bundles are too big and this really addresses that problem but it doesn't really cut the corners which is nice. The version two to three big changes both a good and a bad thing because I found when I started looking at Spelt when version three first came out it's such a big shift and there are so many previous packages and previous things created for it that it was hard to kind of find the new stuff that would actually work with the new version of it which is a little bit of a problem and I think because of this and the rapidly evolving part Spelt can be a little bit of a problem. There's a lot of changes happening very fast because it's kind of like one person's passion project so it kind of progresses along very, very quickly which I think can be a problem when you want to build a big, robust application in it it's hard to keep up and hard to keep up dating the compiler itself along the way because the APIs can change quite a lot still. Then the developer base is also very limited partly because it's still a new thing that you just don't have the community you get with like React or view Angular it's still growing it's not growing at the same rate as any of those three which can be a problem when you're trying to find help or you want to find information about things you have with it however the actual documentation on the website is really good and the community behind it is actually pretty good as well just that even in like a lot of the code editors because you're using dot spelt files most of the time that's usually not so well optimized even like in Visual Studio Code which I use it in when you have the plugins for it it still has some wonky parts to it it kind of interprets it like TypeScript sometimes for me which is a bit weird so I think it's one of those things it's still near, it's still evolving there's a lot happening there I think it's a fun thing to play around with and it's a good thing to kind of get a few small services up and running with but I think in terms of you think it for a big project in a major way it still has its problems that you'd play better off using Polyview would be one of the closer ones to at this stage so yeah it's interesting I would also advise people to also like play around with it the website is pretty good it has some interactive tutorials that work quite well but yeah, there's still a long way to go I think before it's really a viable big viably used in big projects okay so how about any questions about Svelte yeah, yes? Lider, compliance from language that's the language we're compliance from oh so basically you're writing I mean it's a version of JavaScript in general so it's the Svelte API itself where it gives you yeah, a few shortcuts and like kind of similar to what we see in the code it has the different APIs that it has with it and it is just a variant on JavaScript but instead of kind of like with almost libraries they will kind of keep it in so it'll be interpreted when the browser is using it this one it kind of bundles it all up previously it takes out all these dependencies and it fills them in with the equivalent and the vanilla JavaScript so it's trying to make the lower level a little bit more accessible as well so you are basically just writing JavaScript but it has the Svelte APIs in there and the hooks in there that allow you to operate like a normal framework but pulling them out before compiled pull them out before it's actually put into the browser which then improves bundling and size and efficiency as well so yeah, it's just JavaScript really at the end of the day but it's a slightly different way of doing it okay anyone else? you mentioned like no dependencies if you want to make a simple hello world can you just do it with a single file plus the Svelte file? yeah, yeah, so go back into JSON and all that others no, you don't need any of this type of thing to get it going obviously like when you get like bigger projects you will have other dependencies but in terms of Svelte itself you can get a very simple just like the Svelte file you can run it through the compiler itself it'll give you the bundle file at the end of it and then that will be all that requires and then like I say the bundling size that they give you is always very good so even for like larger applications it will compile down to actually pretty small a pretty small file itself so the actual efficiency is really nice and that's been one of the big kind of driving forces behind it one of the big things that people take away from Svelte in general is like the bundling because I know bundling especially with Angular has been like a big kind of big issue where people are always like wanting it small and small like Google is trying to make it smaller but there's still limits and there's a lot of optimisation so this is kind of like a novel way of addressing that problem taking it from the other direction which works pretty well actually for size so compiling it rather than having it execute as a framework in runtime is an interesting flip have the other frameworks taken notice and have they sort of investigated whether it's possible to keep their existing syntax but generate a compiled time version of the framework instead? Has there been that shift? Not that I'm aware of at the moment I mean if they are looking into it I guess it's not being something that's been made openly I'm not sure how much work it would require for any of the other free frameworks to kind of flip it it's an interesting idea I think it can work with them as well but it would probably require quite a lot of changes in the way that they currently build their product so I guess it's one of the things they might just be like a wait and see like they'll see how this catches on they'll see the community that goes behind it if it becomes like a really big thing and like the next big thing then I'm sure they'll invest their time into doing it as well at the moment I think it's still quite early in the life cycle for it that it doesn't actually really eat into their market at the moment but I wouldn't be surprised if they were looking into more of this solution I'd be interested to see if there's even more companies moving this direction whether using it more like compiled JavaScript because then you're getting real dependencies on things like Babel or TypeScript you can kind of just really you can write in any language you want at the end of the day so yeah yeah Do you see it as like once it's developed and matured do you see it as like a real competition to react because it seems like it's moving back to the DOM right as you said it's like it's reactively like an abstraction to the DOM do you see it it's more like vanilla JavaScript friendly yeah yeah so I think it can potentially be quite a big yeah like I think it is trying to compete in some ways with react because react one of the big points with that is that it is like a smaller more agile framework as well and this is trying to be even smaller and more agile from that perspective also because this one doesn't deal with things like the virtual DOM which you get in react it also does improve efficiency of the site as well and then also because it compiles into vanilla JavaScript it means things like if you want to create this view with like web components and such it also kind of works into that ecosystem as well so I think if the web community does evolve and it does use more like web components and more baseline vanilla JavaScript this type of thing would definitely start picking up more and more I think it's one of the things where a lot of these ideas like web components are still a little bit new and yeah I think it could be real competition for them but at the same time because these companies are also massive like I'm sure there would be like a react compiler if it really did compete in that kind of way before too long so I think so but I mean like of all these things when you have like a small develop as like a small single developer more or less they tend to move pretty quickly they tend to get good results I mean look at view view has progressed and matured pretty well over a pretty short period as well so I think there's definitely a lot of potential behind it okay any more questions yeah yeah yeah absolutely so like the thing the nice thing about spell is it just compiles down to vanilla JavaScript so you can quite easily mix and match it between like you can put react into it as well if you would like it would change the dynamic of what you're doing I suppose but there's no reason where you can't mix and match them it just means the bundling might be a little bit different and it is fine from that perspective because you can also do like the plug and play kind of like you're gonna do like a web component or certainly it's easy to plug in as well so yeah there's nothing stopping you mixing and matching it it just might have a bit of overlap that doesn't make it necessary as well I think would be the hope any other question yeah so it is a component based framework as well similar to of components I guess why is that there so from a component standpoint where is it at the end so from a component standpoint this is not the right one this is TypeScript there's no wrong one so yeah it does do components this one and where are we at so I basically have the root type so here I have the different components that I kind of group together and then from here for example what's the smaller one the input I think this one it then has separate components structure as well and it's similar to view as well that the styling is very localized to this file so on the base level you can break them up into the components that you want can arrange them any way that you want as well and then internally it's just writing the parts breaking the components down into smaller things were possible also using different handlers and such so yeah it does operate very similar to all the other modern frameworks they are very component driven which does help because then it's the same style even using the whole time as well any other questions no are we okay okay sure no problem