 It's not mine, but I'm organizing the swell meet up in New York and someone from the stickers, so I just brought some. I thought you're inviting us to come to New York. So the original idea was to talk about basically, everyone here knows Gatsby. I miss Gatsby in Svelte. Svelte has a metaphor called Sapper. It's not very good for static site generation and I started building my own called SSG because I took the MPM name. It's a tree like this. It's very nice. But I thought that that would not be as relevant for people who are not using Svelte. Be my guest to play with it. My own personal site uses that. But I think it's more relevant for general audience to just talk about this compiled approach which I think basically every framework except React is doing and I think it's worth exploring what that is. So, do I start? Ya, we're just having some clinical issues but I think we're now done. Okay, cool. So, this is Compile Swallowing Ahead and it's kind of like a look at the before and after. Lihao already kind of gave you a little bit of that intro so the impact of this will be less impressive. But I still think it's worth going over because it's a very foundational part of Svelte. One of the things that I helped to do in New York, mainly because there was no meet up in New York and Rich Harris is based in New York. And I was like, I will just be very disappointed if no one actually steps up. So, I did and now we have this thing. So, we can consider this the first meet up of the Singaporeans chapter. There's one in Sweden, there's one in New York and then it's now in Singapore. So, before we get here, I'll do a little refresher. I think, again, I was telling all this really nice intro and then Lihao already kind of took away a lot of it. But just as a quick refresher of how we write raw JavaScript, to get anything on the page in terms of raw JavaScript, we have to do sort of manual creation of HTML and every element and then append it. And then if you want to add color, for example, we can do something like this. If I want to remove, I'm going to write document or body.remove child. It's obvious. If I want to add color alongside of an existing element, I can basically append child to the head with a style element and then set the content of that. And you can see that show up here also with a DOM element. And if I want to add a button, I have to add event listeners. So, button.addEventListener and then something like that. And then you can just click this. So, what is what you do without a framework? It's the bare minimum that you can do. So, the idea is to write a compiler to write the source code that we want that compiles to this as close as possible. And we already had a preview of that with Lihao's talk. We'll talk a little bit about the syntax. So, this is the kind of thing that we want to be able to write. So, I'm going to briefly review the source syntax and then we'll go into how it compiles out. So, this is how you write hello world and a basic element that's kind of static. This is how you write it with attached styles. So, each one is going to be styled with a color of Rebecca Purple. This is how you parameterize something in JavaScript and insert it into the DOM. So, that's source syntax. I think everyone's kind of familiar. And it's basically not possible to make this any more concise, right? Like, there's no use state. There's no decoration of anything else. And the way that you set state, I'll get to that later. But here's event listeners where you just do an on quick. So, that looks slightly different from React, but everything else is just regular GSX in React. What you do start to differ a lot from the React model is you do direct manipulation. Any assignment operator becomes a set state, but you don't have to write it. The difference goes more profound than that. And for example, in React, we schedule updates, right? And then we batch them together for performance. This one, you do more or less direct DOM manipulation and we'll see what that compiles to underneath. But that's the main, these are the main language syntaxes. Like, which kind of regards file as a language. And you'll see how it pans out. But the idea is to stick to HTML as much as possible for tooling benefit as well as server-side rendering because you're no longer executing JavaScript in order to server-side render. You're just concatenating strings because every file is a valid HTML file. So, yeah, okay. So, now we're going to the compiler in your head part. So, what does this look like under the hood? It's actually surprisingly big. But I sort of annotated the important parts. Every component is basically considered a fragment. I don't think I have my mouse here. I don't know why. So, every component is considered a fragment. There's three sort of primary, I don't know why you call it, methods on that fragment. The C method creates the element, right? Basically, the element function is the alias for document.createElement. The M method is for mount. You're mounting onto some element that's existing on the DOM. If you have the boot element, there's a render method that does that initial mount. And then there's D, which is detaching, like how do you clean up after yourself as you detach? So, every single sort of component declaration must compound to create a mount and sort of destruct, this detach, this dismount. And apart from the fragment, there's also a concept of a small component. This looks extremely familiar. And it runs all this stuff, as well as some other helper functions which I've kind of just glossed over in an init function. And we'll look at that init function. But it's a lot more cost-based than that sort of function-based, like functional programming-based model that React has. But so far, this is what we know. HTML, anything that's HTML compounds to a C and M and D function. And then for anything that you're mounting for the first time, you also call an init. It's a good that init. So this init function basically has all the metadata surrounding a component. You have that fragment that was passed in and that function is the one that was defined earlier that's create fragment over here that's create fragment passed into the init function. And then once that's invoked over here, that's invoked over here. It's actually attached onto this magic $$ sign which is actually all the way up there which is that these are basically all the internals as well. I don't know if this is safe or not, but you can access them at any point in time and so it's just exposed to you, everything. If you want to randomly inside of your code randomly call after update lifecycle method for some reason, you can. I think that's just a factor of like if you choose this $$ in text, you've shown that you know that you're tapping into the internals. There's state which includes a prop and an update function should be located inside here as well as a bunch of lifecycle callbacks which you as a spell author can write and just be put into an array and just run through this array when you're mounting your component. Blah, blah, blah and then we're just going to mount the component in that init function. Put stuff onto the DOM. In it, the main is what I want to show is this is the fundamental object or class or whatever you call it of every component and that is very similar to React. Let's get on to styles. We move from just simple hello world to now styles. This is already very different from React. React has no idea what styles are. Over here we also want to compile CSS as well. Svelte cannot be used in a style tag. It has to be used together with a bundler. But for that one trade off you get some nice things with regards to be able to generate both your JS and CSS and pair them together. So here we auto generate a hash version of that class and then we attach it to that class for a very strict binding. This is something that I did not understand when I first looked at Svelte. How come each one class doesn't leak to any descendants? If I style this as a div and this as a div and then I have a child of that which is also a div, it doesn't leak. It just only stays at the top level and that's because the Svelte class attach there is only on that one element. So that makes a lot more sense once you get that style. So now we know style tags you add CSS class and then you attach the class into a DOM element with set attribute. These are all DOM APIs. Perlaminators. So now we're not looking at static hello world. We're actually putting that parameter inside of that name JavaScript variable. And what it I guess compiles to is this very nice subtle upgrade from here to a parameterized thing. So we have to break every single part of this up. This is string variable string. So we can see that as t0, t1, t2. And then for every creation that we have to do, we also have to do mounting. So a pen, a pen, a pen. And then we can detach just the root because that detaches all the children as well. So that makes a lot of sense. The other thing that you should also take note of is what happens to the script tag. The script tag is just copy pasted all the way down there. So that's a very, very simple programming model for how to create a function like that. Because when you update later it's actually quite easy. Anyway, so script tag, this is part one of the script tag. You either paste verbatim the JS code down into the generated JS or we'll get there. This is still pasting. So we also have to care about event handlers. So now we've evolved this into, okay, there's an event handler over there and then we'll define that function. So we're very much making use of scope. This is top-level scope, counter- top-level scope, handle-quickest top-level scope. Therefore we can use it inside of our template syntax. Anything that's scope underneath that we're not going to have access to. Okay, so yeah, so that counter is used generated against C, the C function, the M function. That's all makes sense. I also want to pay attention to that copy-pasting of that JavaScript code. There's no change at all, which is good until you start having to modify things. So until now I haven't modified I just only bother our console log. So now when we introduce reactivity this is the secret source of Svelte which is now you need to update something. So there's this new P function over there. I actually asked Richard I was like, why is it called P? And he was like, it's up, date. He was already taken by some of the internals and he was like, I'm just going to P. Set data, that's just that element dot data attribute. It's actually a DOM attribute. I did not know that. You can just change numbers like that. The other thing to note as well is that the script tag is wrapped inside this instance function. This instance function gives you access to the self variable, the props variable, as well as invalidate variable. Here we're only using the magic invalidate variable. So you can think of this as a babel transform. The moment you spot plus equals or plus, sorry, plus equals minus equals or equals, right? Or times equals, whatever that is sort of modifying assignment. It doesn't track dot slice. There are some array methods that modify the actual array itself which is super annoying. So it doesn't do that. I just have to keep that in mind. There's only a white listed list of assignments for which this is valid. So they just wrap it around with the invalidate function and that tells the spell runtime that this whole component is dirty. Let's re-render it again. But for that one piece of magic, you are now able to just write vanilla HTML and do direct plus minus equals. There's no set state or anything like that. And that's very interesting. There's a function for update and the spell runtime that tells you exactly what variable was changed. So if the count variable was changed here, so at the top level it's called count and handle quick. Handle quick is never going to change because we declared it once. But count is going to change and if count is changed based on this update count plus equals 1 if count is changed this spell runtime will say yeah. So to me, this is like the main I can trust this now because there is no longer any magic because I've explained every single thing all the way down to the updates. So I think this is what we've learnt so far like HTML, composter, C, MD function as well as this new P function for update. There's set data, set text, set whatever there's a whole bunch of I'll show you the place in the source code that you can read this. One thing that we're talking about earlier was that this file source code is very readable. It's a part-time project by MaxMode3 guys. So it's very, very readable. So the script tag either you do verbatim pasting if you're not doing anything complicated but the moment you do anything that requires the instance information then it will just wrap it in an instance give you access to self and props for anything that modifies variables you have to invalidate the current state. Okay, so this is what we've learnt. I've added a few extra things that I don't cover here. For example, the other the bingre thing from Sfalt2 to Sfalt3 is the addition of this $reactive declarations and this is such a nice hack. So basically anytime you run an update if you have a dollar decoration the Sfalt compiler just attaches to an update lifecycle and it's just an array. So it's a very nice way to introduce some reactivity. The view comparison of this would be computed variables for example but with just this one decoration you can replicate a lot of that and I use this all the time. Okay, so I think that's essentially the Sfalt compiler pitch. Obviously there's a lot more that I skimmed over but basically this is the max that I can do. I like to write things from scratch. I cannot write a compiler from scratch. So the best I can do is to show you before and after and then the more you look at before and after, you have the mental model of the compiler in your head versus. So the way that we get all this is you go to a repo and then you paste in whatever was your source code and then you look at the compiled output and you get a very strong sense of what the compiler does for you as well as the source code inside of the Sfalt report itself. Let me show you it really is very simple. So those insert the detach method is literally just insert before. So these are all dawn elements. I suppose it minifies better or something that's why you put it into a function instead of using them directly but it really is just 300 lines of this kind of stuff. So nothing too crazy and I think if you have something where you can read the whole thing in a reasonable human lifespan then Sfalt is for you. Okay, cool. Thank you. Question time. So at the beginning of this talk, you all mentioned that previously we have one of our member here sharing about Svelte and Stenzo. So have you tried to do something similar with Stenzo? No. I just haven't had the time. Do you think using Sfalt can be used for big scale does it scale? So I mean I don't know. I don't care. We have to I think remember the origin of the provenance of Sfalt is that it is created by someone who works on interactive graphics for the New York Times their emphasis is speed and time to delivery and more than oh, look at my 500 megabyte application this is the scales. There are different measures of what scale means and different goals that you should optimize for and the doesn't scale question doesn't really answer that kind of thing. So one of the productivity examples that he always brings up is how Sfalt is actually deployed on the payment systems or where they have like 200,000 payment machines because Sfalt compiles to such a small runtime like only in the futures that you use the whole point of doing this like let's say I don't have any updates I don't have that P function at all so I just don't even compile that into my raw JavaScript that's why the compile output of a Sfalt app is typically a lot smaller but there are a lot more devices including low-power devices like the ones that have seen some success but so far there haven't been huge applications no I think it's really up to people to really push their boundaries that's why it's a newer framework I think one thing so one thing that interest me a lot about this as an offering format is that um like this is basically HTML and so an application built with a bunch of Sfalt components is basically nested HTML files one inside of each other and I always want to say this is what components done right where you actually have a sense of context where you actually have a sense of we actually have a very simple model instead of the kind of components philosophy where you have to declare a bunch of very complicated classes for doing a simple thing as updating he has some examples in his blog post about why he doesn't use web components which I guess answers the stencil question stencil does essentially that but focus on web components so I'm very interested in using this format for writing static-side generators because layout format the moment I can declare the moment I can declare this and value of this becomes a prop so anything that passed in and says my component name equals and then some data object I can then use inside of here as together with syntax this becomes a very flexible layout format for any sort of content that also takes care of styling and transitions and animations which is I think everything I ever want so the way I'm at right now is swell for sites, wear for apps yeah no more question? okay, you're done thank you so thank you Sean don't worry, excuse me