This week the panel is joined by Mark Volkmann to discuss Svelte and how it compares and differs from front-end frameworks such as React and Angular. Mark has written a book and has given talks about Svelte and also about Sapper, an application framework built on top of Svelte. He explains to the panel how Svelte components are defined differently than other JavaScript frameworks, and how they are actually compiled into the production code, which isn’t dependent on any external libraries. He also explains why and how Svelte forgoes the use of a virtual DOM, using direct DOM manipulations instead. Finally he describes Sapper and explains how it can be used to quickly and easily create Web-apps that use SSR, static pages generation and dynamic routing.

Sponsors

Panel

Special Guest

Links

Picks

Steve

Aimee

Dan

Mark Volkmann

Follow JavaScript Jabber on Twitter: @JSJabber

Special Guest: Mark Volkmann.

Sponsored By:

DAN_SHAPPIR: Hello, everybody, and welcome to another episode of JavaScript Jabber. My name is Dan Shapir. I'll be your host today coming to you from Tel Aviv. And today on our show, we have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

DAN_SHAPPIR: Steve Edwards. 

STEVE_EDWARDS Hello from the incredibly rainy Portland. 

DAN_SHAPPIR: And our guest for today is Mark Vaughnman. 

MARK_VOLKMANN: Hi, great to be here. 

 

Hey, folks. One of the things that I find that really makes a difference for people being happy in their job is working in a place that makes a difference. And there's a terrific company out there that's looking to hire full stack developer just like you. And that's Faithlife. Their average tenure is five years. I mean, five years, that's forever in developer years. Usually, I see people changing jobs every one to two years. People are sticking around because they're great. They have a great values-based culture and they are hiring developers in the United States. They're looking for full-stack developers who can do C-sharp or JavaScript on the backend and React on the front end. Go check them out at devchat.tv slash faithlife. That's devchat.tv slash faithlife.

 

DAN_SHAPPIR: Hi Mark. Mark, I understand that you're going to be talking to us about Svelte and about Sapper, correct? 

MARK_VOLKMANN: That is correct. 

DAN_SHAPPIR: But before we begin, maybe you can give us a little bit of your own background. 

MARK_VOLKMANN: Yeah, so I've been in software development for a really long time. I'll date myself too much if I say everything that I've worked on. But I've worked in a number of programming languages and worked with many different web frameworks, including raw DOM manipulation using jQuery, Angular 1, lots of React, some Angular 2 and beyond, some Vue, and now Svelte. And so I've seen a lot of things. 

DAN_SHAPPIR: Yeah, that's quite a way to go. So what's missing? Is there any framework that we neglected to mention? 

MARK_VOLKMANN: None that I feel compelled to dig into because I feel like Svelte really hits a sweet spot in simplicity, which I'm sure we'll get into in the show, but maybe you're asking about past things that I've done. And no, I've never done anything with MooTools. I think I've mostly listed everything except for I've also done some work with Ruby and a little bit with Rails. 

DAN_SHAPPIR: And apparently now that you're working with Svelte, you're really excited about it because as I understand, you've actually written a book about it. 

MARK_VOLKMANN: That's right. I was so convinced that it was a unique new approach that I felt compelled to write about it. And so I have a book published by Manning called Svelte and Sapper in Action that has been available in print for I guess a couple of months now. 

STEVE_EDWARDS So inaction is one word in two words, not one word, right? Just check. 

MARK_VOLKMANN: It's two words. That's right. 

STEVE_EDWARDS Not inaction. Right. That was a joke. 

MARK_VOLKMANN: Okay. 

DAN_SHAPPIR: So that means you're really excited about Svelte. So tell us why you're so excited about Svelte.

MARK_VOLKMANN: Yeah, so there's so many things about Svelte that make it easier in my mind than the other approaches. I feel like as developers, we've allowed our budget for complexity to gradually grow to a level that is just too high. And so for me, Svelte represents a step in the opposite direction, reducing complexity, especially in the area of state management. 

DAN_SHAPPIR: Yeah, state management is a really contentious topic because you have some frameworks like Angular where it's effectively built in and it's very opinionated about how it manages state and then you have frameworks or sometimes they like to call themselves libraries like React or Preact that to an extent push off state management off to somebody else. Although they actually do have a bit of state management built in, but they like to say that they depend on other libraries or frameworks like Redux or MobX. How is it with Svelte? 

MARK_VOLKMANN: So with Svelte, it is built in. You can tack on additional approaches, but most developers will find that the way that it works in the built-in approach is just so simple and supports all of their needs that there really isn't a reason to reach out to another outside state management library. Really, this needs to be broken down into two pieces. So first is how do you manage state within a component? And for listeners that are familiar with React, they probably know about the use state hook and are familiar with how you declare that I want this bit of state, and then I get a function that I can call when I wanna update that state. In Svelte, the way that it works is that you just declare a variable. And so if you've declared a variable in the script tag of your component and you use that variable in your HTML, then that is a part of your component state. And if you have a function in your component that gets called maybe in response to some user action, and that function updates the value of a variable, that changed the state. And any part of the HTML that was using that is going to get re-rendered. And so you don't really think about it. You just declare a variable, change it when you want to, and know that you'll get those updates. So that is state within a component. And then going up from there, if I need to share state between components, then I use what are called stores. And there are a few different kinds of stores in Svelte. So the first kind to think about is called a writable store. So you create a writable store just by passing it the current value. That's the simplest way to do it. And then that store could be defined in a JavaScript file that many of your components import. And those components can change the value of that store by calling a set method on it, or they can call update, pass it a function that, as you might guess, is going to be pass a function that receives the current value, and its job is to return what you want the new value to be. So that's a really simple way of having data that can be shared between a bunch of components. And you know that if you're subscribed to that store your component will receive updates and can re-render. And so we can get into all the details of exactly what it means to subscribe to a store and some variations on stores, but that's the basics of how state management works in Svelte. 

DAN_SHAPPIR: If I go back to the state of a component, which like you said, is essentially just a variable declared within a file. So it's as if, it seems like it's a globally scoped variable, but in actuality, from my understanding, it's actually scoped to an instance of the component described by that file. What makes this magic possible, that you write one thing and then get seemingly something else, is the fact that Svelte is actually compiled, right? That what you write is not exactly what the browser executes, but rather it goes through generates code from what you wrote, and that is what actually gets executed by the browser. 

MARK_VOLKMANN: That's exactly right. And so if you looked at the generated code, you would see that all the places in your HTML where you are using that bit of state, there will be JavaScript code that is conditional logic wrapped around that bit that generates that part of the DOM. And so that part's going to be re-triggered if that piece of state changes. And then it can generate new DOM for that part. So all of that magic comes via the Svelte compiler. 

DAN_SHAPPIR: And that's the big difference, I guess, so the big selling point of one of the big selling points of Svelte versus the other frameworks, I guess, that instead of the framework being code that you just import and use, oh, OK, so you know. Some of the frameworks do also provide some sort of a compiler. For example, in the case of React, what compiles the JSX into the appropriate React function calls. But essentially, they're primarily just importing code from an external source, whereas with Svelte, there is no import of code from an external source, correct? 

MARK_VOLKMANN: Right, you're using the code that was generated by the compiler. And while we're on this topic, this is a good point to bring up the fact that Svelte does not use a virtual DOM, and it can get away from using a virtual DOM for exactly that reason, that the compiler can generate code that knows what would trigger a bit of the HTML to have to change. And so it just includes the code to do all the DOM manipulation that is required. And so this is a big deal in Svelte because Rich Harris, the creator of Svelte feels strongly that virtual DOM is just not a good idea. When you think about all the work that is going on behind the scenes to make that work, that we have to create a new version of the DOM we're trying to produce in memory and then do a diff between that and the previous version, figure out what changes are required and then make those changes in the actual DOM. It's hard to imagine that if we were starting over now and thinking, what's the best way to implement a web framework that we would land on using a virtual DOM? It seems so incredibly inefficient. Yet we kind of put up with it because things seem okay. It seems fast enough. But Svelte takes an opposite approach and says, that was a crazy idea to begin with. And we can do better than that by generating exactly the JavaScript we need to surgically make the DOM manipulations that are required and not have to generate a virtual DOM and not have to go through that diffing process? 

DAN_SHAPPIR: Well, to be fair, there are actually two motivations for the virtual DOM that give it legitimacy that I'm kind of interested in, indeed in how Svelte addresses these. One is that it synchronizes access to the DOM, one of the problem with the DOM that inexperienced people who were using direct DOM access would occasionally hit that snag would be that if you intersperse reads and writes to the DOM, it creates thrashing because the DOM needs to re-render certain properties because you're just trying to read them. And the virtual DOM synchronizes that. So you read from the virtual DOM, which is just reading from JavaScript, which is really fast, and then you write into the virtual DOM and then React, for example, can decide when it actually wants to dump everything from the virtual DOM into the DOM. So it avoids the thrashing, it just does it all as a sequential write, sequence of write operations into the DOM. So that's one thing and I'm kind of curious about how Svelte avoids this sort of thrashing. And the other one is essentially the fact that you simplify state management because it's like with, it's kind of tries to simulate multi-page application in a single page application type environment where you're dumping out the entire new DOM that you want and then it's React that does the diffing and knows how to modify in the DOM just the bits that you need to modify and not rewrite everything. How does Svelte deal with both these points? 

MARK_VOLKMANN: So I can't speak to the implementation details of how it does it, but Svelte also is batching the DOM updates that it's going to make. So there's some optimization that is happening there by the Svelte compiler. And can you remind me what is the second point again? 

DAN_SHAPPIR: The second point is about the fact that you re-render the entire, well, actually that also turned out in the end to be problematic from a performance perspective. But if I take the naive approach, then you re-render the entire virtual DOM as if you're building your entire UI from scratch, and then the React is smart enough to do the diffing and only update those parts of the DOM that actually change. I guess that in your case, you would say that Svelte is again smart enough to just know what actually needs to be re-rendered and just render that directly to the DOM. 

MARK_VOLKMANN: Right. That's exactly right. So it's not the case that when any piece of state in a component changes that it re-renders all of the DOM for that component. It's re-rendering only the parts of the DOM that have changed. 

AIMEE_KNIGHT: So I kind of, as we're talking about the kind of differences between React, it sounds like, and Svelte, and it doesn't do the DOM diffing. And as you were explaining it before, like the immediate question to me that comes to mind is the bundle size of components. And so I'm curious if you can talk about that. I'm looking at a GitHub issue, like some graphs where you know, initially Svelte kind of starts off pretty small, but you do hit like an inflection point. So can you kind of talk about when that may be and probably maybe some tips for people who are interested in this as to how to prevent that? 

MARK_VOLKMANN: Yes, so the issue here is that Svelte bundles are really small when you have a small application, but as the number of components in a Svelte app grows, the difference between its bundle size and the bundle size of say an equivalent React application, it gets closer and closer. And for a long time, a lot of people in the Svelte community just assume that this probably is not an issue, but we don't really know where the crossover happens. But there have been a couple of people in the last few months that have looked at this very closely. And so one person that goes by the tag name half Nelson on Twitter did a study of this and he found out that the inflection point is at about 120K of component source code. So it's hard to relate that exactly to say a number of components, but the upshot of this is that you have to have a really large application before this becomes a concern. And so maybe if you're trying to implement Facebook and Svelte, you might find that you could have a smaller bundle size if you use React but for reasonable applications that most people are writing, it's still gonna be smaller in Svelte. 

DAN_SHAPPIR: I think this directly goes to, we don't have them on the show today, but AJ likes to bring up this whole thing of copy versus reuse. Whether you should create a reusable function or module and reload it, or whether you should copy it over. And both approaches have their advantages and disadvantages. Obviously, if you're doing a lot of reuse, you're creating dependencies which can create issues. With React, at the very least, you're reusing the React code, which is bundled as a downloadable module or bundle, but it's a one-time tax. You pay it once regardless of the size of your application. The larger your application becomes, the relative cost of that library goes down with Svelte because I guess because each component is compiled independently, then you're indeed risking a situation in which the code gets repeated over and over again. So I guess, well, I would guess that the solution for something like that would be the fact that Rich Harris, the guy who created Svelte, also created Rollup find those repeated pieces of code and then do some sort of deduping or something? 

MARK_VOLKMANN: Yeah, I think that that's correct. And I believe that the Svelte core team feels that this is something that they could address if they wanted to. There's just very little motivation to do it right now because as these couple of studies have shown, you have to have such a large app for this to even become an issue. But if people start writing larger Svelte apps in the future where this is an issue. I think that the core team can address this by doing some of what you just said to try to reduce that duplication and get the bundle sizes smaller for large apps. 

DAN_SHAPPIR: I believe that Svelte version 3, I think, was relatively recently released, correct? 

MARK_VOLKMANN: I don't remember the exact date, but I think version 3 has been out for at least a year now. So, no, it's not recent. The thing that is recent is official support for TypeScript.

DAN_SHAPPIR: Can you elaborate on that a little bit? 

MARK_VOLKMANN: Yeah, so for a long time, you have been able to use TypeScript inside Svelte apps. It's just that you had to manually configure the use of Svelte pre-process to do it. And so it was a little tricky to set up and it couldn't type-check all of your code. So inside the HTML, you can use things that are called interpolations where you have JavaScript expressions inside curly braces. And if there, for example, you called a TypeScript function, it wasn't able to see if you were passing the correct kinds of values, but it could do type checking in your code within a script tag. So it was like partial support for TypeScript. But this has been something that users of Svelte have been asking for for quite a long time. And so back in August, they officially announced support for TypeScript. And so the way that this works is that when you start up a project, you run a utility that gives you a starting point for the app. And the app does not out-of-the-box support using TypeScript, but there is a script that ships with it that if you run this script, it changes your starter template to then support using TypeScript and sets you off in that direction. And so now it's really easy to start a Svelte project and have TypeScript support. So that just became available in August.

DAN_SHAPPIR: Cool. Are you using it in your projects? 

MARK_VOLKMANN: I haven't been using it much yet. And I think this is related to the idea that for a lot of JavaScript developers, they tend to want to use TypeScript when it's a large project and not as much on smaller projects. And what I've been doing more recently have all been of the smaller variety. So I'm not an anti-TypeScript person, but for a lot of these projects where I might be the sole developer, I haven't found it important to use just my own use? 

DAN_SHAPPIR: One of the question, another question that I wanted to ask about Svelte and actually the decision to use or not to use TypeScript is kind of related to that is about debugging and the fact that it's compiled code. I know that TypeScript being a superset of JavaScript usually generates JavaScript that's almost like the TypeScript with the types removed. So it's usually relatively straightforward to debug. But still, whenever you're adding any sort of a bundling step or transpilation step or be it what it may, it adds complexity when you're debugging. Because you end up debugging code that is different than what you wrote, originally wrote. And source maps, they're kind of crap. So I'm kind of wondering, how do you go about debugging Svelte when it's being compiled the way that it is. 

MARK_VOLKMANN: So for the most part, I've found source maps and Svelte to be okay, but I have to admit to being kind of old school in my approach to debugging, by which I mean lots of console logs, lots of rendering additional things in the DOM just for debugging purposes. And that has taken me a long way. I would say that I use way more console logs than I do adding things to the DOM. But in my experience, that hasn't been an issue. And I've taken that same approach, really, with every web framework that I've used, Angular, React, Vue, all the same, and it's been fine for me. 

STEVE_EDWARDS Hey, what's your name? Dan. Gosh darn it. So you're talking about source maps and debugging and stuff. So for maybe those that don't understand the relation, you want to explain how source maps work with your DevTools and debugging and so on? 

DAN_SHAPPIR: Well. A source map is just a file that is generated when you do some transformation on the code that results in the code that's actually downloaded to the browser being significantly different than the code that you originally typed in your IDE or editor or whatever. It might be because you're doing some bundling or because of obviously minification or agglification, or because you're transpiling or compiling some other programming language into JavaScript, whatever it is, the end, the resulting code looks really different than the code that you originally wrote. And source maps are just this format which tries to match between that modified code and the original code. So it associates, it associates the, for example, let's say you minified your code, and that changes the variable names because you had meaningful long variable names hopefully and now instead they're just called X or A or dollar or something like that. And SourceMap creates a mapping, provides information that enables the browser, the and as a result, you can actually see the original source code. So what happens is that when you launch the development tools, it actually looks inside the minified file. It sees there usually as a comment, a link to a source map file, which tells it also where to get the original file. And then you can, as it were, single step through the original file and look at variables the way that according to the original names. So it all sounds really great, but unfortunately I think we discussed it a while back. It's a really old standard that hasn't been enhanced and perhaps even properly maintained, and it's really limited. So for example, if you try to go into the console tab and use the original variable names, it just doesn't work. Often when you try to single step, you'll find that you're just jumping around all over the place and it's really difficult to debug this way. So obviously having source maps is better than not having source maps, but often it's like not a great solution. And as a result, I really like to work in the original JavaScript or debug in the original JavaScript whenever I really need to use debugging tools. So that's a long-winded explanation about source maps. 

AIMEE_KNIGHT: Yeah, for I was going to chime in to for people who haven't used them and kind of looked at them. Like obviously they kind of vary greatly depending on, you know, what you're writing your code in. But yeah, they're, they're helpful, but they'll give you line numbers that don't really line up and the code looks very different a lot of times. And so it's, it's kind of like, I would best describe it as like PC. There's bits and pieces that are helpful, but it's, it's usually not like one to one.It's frustrating. 

DAN_SHAPPIR: Yeah, it's frustrating. It's like it's almost good enough, but not quite. So going back to Svelte though, we were talking about Svelte components. Maybe it's worthwhile to explain what Svelte components actually are and what they look like. 

MARK_VOLKMANN: Okay. Yeah, so each Svelte component goes in its own source file and it has a file extension of.svelte. And inside the file, you can have three sections, all of which are optional. So you can have a script tag. You can have your HTML and then you can have a style tag with your CSS. And so the simplest Svelte component you could create might only contain a div tag that says, hello world. That's the only thing in the file. And that's a valid Svelte component. If you add a script tag, then you have the ability to import other things. You can define what the props are that your component accepts, and then you can define functions that maybe get invoked when the user triggers an event. Then in your HTML, you might have an HTML form with inputs and buttons and things. And then in the style tag, of course you have all the CSS, but it is automatically scoped to that component. There is a way that you can opt out of that for a bit of CSS to say, I want this piece to be global, but by default, everything is scoped to the component. 

DAN_SHAPPIR: And what does this get compiled into? 

MARK_VOLKMANN: It gets compiled into the bundle. So not separate JavaScript files for each component, but just the bundle that contains all of your code. 

DAN_SHAPPIR: So effectively, you could say that each component becomes its own bit of JavaScript, and then all this JavaScript gets bundled together by the bundler. 

MARK_VOLKMANN: That's correct. 

DAN_SHAPPIR: What are you? Oh, sorry, go for it. 

STEVE_EDWARDS So you can still have outside CSS, global CSS, right? I know we've talked about that before. 

MARK_VOLKMANN: In fact, the default template gives you a file in the public directory called global.css just waiting for you to put your global CSS right there. You can have additional ones, but that's kind of the preferred place to put that global CSS. 

DAN_SHAPPIR: What I really like about this approach is that in React, which is really JavaScript centric, everything goes inside the JavaScript file. So you're at JSX is effectively putting something that kind of looks like HTML inside JavaScript. And then you maybe in order to scope stuff, you put inline CSS inside the JavaScript. So everything goes inside the JavaScript. In Svelte, the components kind of look like their own separate mini HTML files, which means that everything seems as if it's inside HTML, which is kind of the way the web was meant to be, I think. 

MARK_VOLKMANN: That's right. And so of course, inside the HTML bit of it, you need some way to have conditional logic and iteration. And so Svelte uses a mustache-like syntax, and so there's curly brace pound sign if and curly brace pound sign each for iterating over elements of an array. So that's the way that you make the HTML dynamic. 

DAN_SHAPPIR: Cool. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're gonna know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Ray Gun is awesome at this. They just added the performance monitoring, which is really slick and it works like a breeze. I just, I love it. I love it it's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grepping through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They are definitely going to help you out. There are thousands of customer centric customer focused software companies who use RayGun every day to deliver great experiences for their customers. And if you go to RayGun and use our link, you can get a 14 day free trial. So you can go check that out at JavaScriptJabber.com slash RayGun. 

 

DAN_SHAPPIR: So you end up with a lot of files then probably inside your project if every component needs to be its own file. 

MARK_VOLKMANN: That's true, yes. 

DAN_SHAPPIR: Okay, that's not necessarily a bad thing though. And anything else to say about Svelte itself before we move on to Sapper? 

MARK_VOLKMANN: Well, I guess we could kind of summarize the ways that you can pass data between components. And so some of these are just like it is in other frameworks. You can pass props from one component to another. You can use slots, which are a way to insert content that you put as children of an element into that component. You can use events, so a component can trigger an event that the parent component is listening for. There's a thing called context, which is not quite like React context. It's a way of saying, I want to make this data available. I want to give it a name. And now anything that is an ancestor of me can ask to get this bit of data by name. And we've already talked about stores as a way of sharing data. And then one final thing is there's a concept of module context as a way of letting all the instances of a component share some data. So there are those six ways that you share data in Svelte. 

DAN_SHAPPIR: One more thing that I would like to mention about Svelte, which I've heard from people who have used it, is that because the code compiles into native JavaScript and does native DOM manipulation, you can actually start using Svelte alongside other frameworks. So if you want to start gradually migrating to Svelte, maybe even a migration that might never actually finish 100%, you can actually use Svelte alongside other frameworks. Is that correct? 

MARK_VOLKMANN: That is correct. And you can even take it a step farther if you'd like and compile your Svelte components into web components and then use them as web components in another framework. 

DAN_SHAPPIR: That's really cool. Okay then, so let's talk about Sapper. What is Sapper?

MARK_VOLKMANN: So Sapper is a framework that sits on top of Svelte, kind of in the same way that Next sits on React and Nuxt sits on Vue. And so Sapper adds a set of, I would say, nine features. And these are all things that if you wanted to add them directly to a Svelte application, you could. It's just that some of them would be very tedious to add. And so if you choose to use Sapper instead of using Svelte directly, you just get all of these nine things for free. And so the first of those is page routing. Svelte doesn't have page routing out of the box, and there are many ways to add it. Some of them are pretty easy. But if you choose to use Sapper, that's just built in, and it's just a matter of placing files in the right directories, and the paths to those just come from the directory structure. Next one is page layouts. If I've got a bunch of pages within my app that want to have a similar layout, they can share that layout by defining these page layouts. Another one is automatic server-side rendering for the first page that I visit. This one is interesting because you don't do anything to get it. You don't even ask for it. It's just the way that Sapper works. The first page you visit, it's going to be rendered on the server, and then the rest of them will be rendered on the client side. Another cool feature is code splitting. We've talked about how the bundle size in Svelte is really small. You could make it even smaller if you say that you don't want to load the JavaScript for a page until you visit the page. And so in a separate app, you don't have just one JavaScript file for the whole app. You have separate JavaScript files for each page, and you only download the JavaScript for a page when you visit it. So that's code splitting. And then taking that a step further, you can mark a page to say, I want to use prefetching for this page. And that means that if the user is hovering their mouse over a link, and they're getting ready to visit a page, Sapper is gonna say, I think there's a chance they might click that. So I'm gonna go ahead and download the JavaScript for that page. And in addition, that page might need to call some rest services to get some data. So I'll call those too. And maybe all of that will be finished before the user actually clicks the link. But even if it's not finished, at least you got a head start on doing those things. And so the page comes up much faster. Another piece of this is, static site generation. So with a SAPR app, if you're trying to build a static site, you can build it in a different way that says, I want to crawl all of the pages and generate their static HTML ahead of time. And then I'm just going to deploy that static HTML. And two more to talk about, server routes is a way that you can implement node-based REST services directly in your SAPR app. And so it's the same code base as your front-end UI. And all you're doing is writing some pretty straightforward JavaScript functions that are the implementation of your REST services. And so it makes it easy to be a full stack developer working in Sapper. And then finally, offline usage is built into Sapper. So there's a service worker that you get by default. And if you want to customize that to change the way that caching is working, you can just modify the service worker that it has provided for you. So you get all of those nine features just by opting into using Sapper instead of directly using Svelte. 

STEVE_EDWARDS So what is available in terms of different source types, like out of the box versus plugins being written, such as say static contents, just a static text file versus APIs to GraphQL endpoints or REST, what's built in in terms of source capabilities, source reading capabilities?

MARK_VOLKMANN: Are you talking about the ability to easily send an HTTP request to those things? 

STEVE_EDWARDS No, not necessarily. For instance, one of the things that came out of the, I think it was 2.13 version of Nuxt was the capability just to read static content that hadn't always been there. And so I'm just curious to see what sort of sources are available. Is it strictly, you know, an Axios type request to an API endpoint or is there methods built in to read other type of static content. 

MARK_VOLKMANN: Yeah, I would say that there's nothing special built in for that, and I believe that most Svelte developers would use the Fetch API to do that sort of thing. Of course, you also can use Axios. But one additional feature, I talked about pound sign if and pound sign each. There's a third thing like that that you can put in your HTML that is pound sign await, and you give that a promise, and then you can tell it right in your HTML. Here is what I want to render while I'm waiting for the promise to resolve. And then here's what I want to render if it resolves. And then here's what I want to render if it rejects. And so I can give it three chunks of HTML and it will change what it's rendering based on the state of that promise. 

AIMEE_KNIGHT: You put that in your HTML? 

MARK_VOLKMANN: Yes. 

AIMEE_KNIGHT: That makes me sad, but I can see why it would be useful. It just seemed hard to test, but good reason to use something like Cypress.

MARK_VOLKMANN: Yeah, well, I guess that's the place where you want to state those three chunks of HTML, and so it's just bracketing those three pieces. And I suppose your test would be against perhaps a JavaScript function that is going to make the rest call and give you the promise. But, but you mentioned Cypress and that's a good thing to bring up because all the same testing frameworks you might be familiar with, you can use with Svelte. And so you can use Cypress to do end-to-end testing of your app. You can use Jest along with the Svelte testing library, just like there's a React testing library to write unit tests. And yeah, so all of those same testing approaches carry over to Svelte. 

DAN_SHAPPIR: And Amy, don't forget that it's not really HTML at the end of the day, that it actually gets compiled down to a JavaScript function. So, I think it's still okay. 

AIMEE_KNIGHT: Okay, I wasn't, because I haven't used it. I was actually, I was wondering if we meant like, like JSX type HTML. No, it's in like the actual template. 

MARK_VOLKMANN: Yes, yeah, because that HTML is a part of your.svelte file and that await syntax goes right into the HTML along with the pound sign if and the pound sign each. It's just the third of the three special things that you can add to your HTML. 

DAN_SHAPPIR: But it still gets compiled into JavaScript that writes to the DOM, right? 

MARK_VOLKMANN: That's correct. 

AIMEE_KNIGHT: Okay. Okay. That makes me feel a little bit better. 

DAN_SHAPPIR: By the way, the thing that I really like about the various app frameworks, like Next, like Nuxt and apparently like Sapper is that they really took a page from the Ruby on Rails handbook, it seems, of, of using conventions to generate the code that you want. So using directory structures for routing, and maybe even using particular file names. You mentioned that global CSS file, et cetera. So all these things about, if you follow the relevant convention, we will just make it really easy for you to build the backend and even the front end for your web application. 

MARK_VOLKMANN: That's right, yes. 

DAN_SHAPPIR: And you mentioned static site generation. Do you know what it integrates with?

 MARK_VOLKMANN: I'm not sure I understand the question. So it's generating. Go ahead. 

DAN_SHAPPIR: Yeah. Like does it have integration with the stuff, like, you know, with various CDN or CDN automation tools, I don't know, something like a Netlify or something like that. 

MARK_VOLKMANN: So you can certainly deploy with Netlify and Vercell, but I don't believe there's any special integration with those. It's just generating the files that then you can deploy in a kind of a standard way anytime you would just have a set of HTML and JavaScript. 

DAN_SHAPPIR: And you mentioned the SSR, so I guess it's smart enough about doing efficient hydration and not re-rendering stuff on the front end, just hooking up the relevant JavaScript functionality. 

MARK_VOLKMANN: Yes, that's right. Although I can't say I'm familiar with the low-level details of how that's implemented. 

DAN_SHAPPIR: From your experience, how easy is it to install Svelte and Sapper and get it up and running in the context of a project. 

MARK_VOLKMANN: So one of the complaints that some people have about Svelte and Sapper is that they don't have a CLI tool like some of the other frameworks do. Instead, what they have is that they recommend using this utility called DGit. And DGit is basically just a way of cloning a Git repository. And so there's a starter Git repository for both Svelte and Sapper apps. And so you run the command npxdget, you point it at that repository, and you tell it the name of a directory that you want to create. It's the name of your project. And then it gives you those starter files. And then from there, you can just say npm install, npm run dev, and you're running. And you've got live reload and watching of the files. So I think the viewpoint right now is that there isn't really a need for a CLI, that that dget command is enough to get you started. In addition, there's an online REPL that you can use. And so really you don't have to install anything. If you go to svelte.dev and click on the REPL link, it'll open up a place where there's a starter Hello World app, and you can add as many components as you want and try different svelte concepts right in the browser. And so you enter your code on the left side, and on the right side, it shows you the result of that. You can even click on a JavaScript output tab to see what kind of code would it generate for this Svelte syntax that I'm using. So it's a great way to experiment. And you also get a custom URL for each of these REPL sessions that you create. And so you can just send that URL to a person if you're having a problem and they can help you debug it right in the browser. 

DAN_SHAPPIR: That sounds really cool. Indeed, one of the things that I really like about Svelte is that it seems to be really easy to get started with it. And there's a lot of really nice documentation, I assume that's also true of your book, that really helps to get you up and running fairly quickly and get you playing with it and creating actual applications fairly rapidly. 

MARK_VOLKMANN: Yeah, I certainly found that to be the case. And I hope that people do get a lot of value from the book. There are two others felt books out there, but they're really short. Compared to mine, mine is very comprehensive. And so it starts out very basic, but it really goes over pretty much every feature of Svelte and Sapper. 

DAN_SHAPPIR: Cool. Is there anything else before we finish that we should cover in the context of either Svelte or Sapper? 

MARK_VOLKMANN: I guess two other things I should mention. One is that Svelte has really good support for animations built in. And so these are CSS based animations. And so they're very efficient. It's really easy just to say, I would like it to be the case that when this component gets added to the DOM, it fades into view or it slides in from the left side of the screen. For the most part, you just import a function like fade and then say you want to use it. And so it's very easy and you can even add custom animations. And then the other thing I would mention is that for mobile development, there is Svelte native, which builds on top of native script and lets you write a mobile app using Svelte. So that's something that is growing in its maturity. And I have a whole chapter in my book that talks about building mobile apps with Svelte. 

DAN_SHAPPIR: Oh, so I see that not only does Svelte want to compete with React in the web arena, it also wants to compete with React Native. 

MARK_VOLKMANN: That's exactly right. One thing that's interesting about that though, is that it's really not trying to invent a new thing. Instead, it just layers on top of native script. And so it's trying to let you use Svelte syntax to do only the things that you do in native script, which is quite a lot. And so for people that might already be familiar with native script, they can then use what they know, but using this Svelte syntax. 

DAN_SHAPPIR: And what does it do for components or for the UI widgets? I mean, in the case of React Native, you've got the JSX like that creates instead of HTML elements, it creates, it uses or specifies native UI elements. What does Svelte do in that context? 

MARK_VOLKMANN: Right, it's the same thing. There are corresponding low-level primitives in native script, and you're just using those inside your Svelte native app. 

DAN_SHAPPIR: So in the HTML block in the Svelte file, instead of using a div or a form, you'll be using something else. 

MARK_VOLKMANN: That's correct, yeah. There's a whole set of those that are defined by native script, and you're just writing the syntax to utilize those. 

DAN_SHAPPIR: Cool.

 

Leveling up is important. I spend at least an hour every day learning ways I can improve my business or take a break and listen to a good book. If you're looking to level up, I recommend you start out with the 12 week year as a system to plan out where you wanna end up and how to get the results you want. You can get it free by going to audible trial.com slash code. That's audible trial.com slash code. 

 

DAN_SHAPPIR: Well, in that case, I think I'll push us towards picks. Any volunteer who wants to go first? Steve, Amy? 

AIMEE_KNIGHT: No. 

STEVE_EDWARDS Oh, I was on mute. Here, I thought it was on mute. 

AIMEE_KNIGHT: Let's see. Shoot, I messaged it to my friend, and now I lost it. But let's see. I saw this on Hacker News this morning. It's called Low Level Academy, and it goes through building some things that looks like in Rust. So just because I'm getting deeper and deeper into this stuff, I thought that that would be pretty good. And then I'm going to pick, you know, honestly, I've read a lot of different books over the years and technical books, and I tend to kind of be more of a blog post person. But I ordered the Terraform up and running book, and I should have picked this sooner because it's really, really, really good. I don't know. I can't say enough good things. Like some technical books, I feel like they can kind of jump around. And for somebody who's like learning infrastructure without a lot of background. So he gets into like a lot of the details, obviously of Terraform because Terraform up and running. But whenever he touches on like an infrastructure concept that you obviously would use Terraform to manage or, you know, to provision manage whatever you want to call it. He kind of explains what the concept is too. So I just found this book really, really, really good. That'll be it for me. 

DAN_SHAPPIR: Cool. Steve, you go now. 

STEVE_EDWARDS Okay, so I'm going to go outside of tech here and go with actually a movie that I came across the other day. I'm at Two Pecks actually. So sometimes I turn on TV like middle of Saturday afternoon or something that and TCM will have some turn of classic movies have some good ones on it. So one that came on the other day that I got suckered into that I had never seen before, call me uneducated was T Largo, which is a classic movie with Humphrey Bogart and Lauren McCall also has, I think Edward Robinson, T Edward Robinson, Lionel Barrymore in it. So a really classic movie. And of course I've got Gordon Lightfoot's song running through my head about Key Largo, Bogey and McCall. But I really enjoyed it. I've always, for some reason, shied away from some of those classic movies. And I know in the past, I talked about seeing Casablanca again and really watching it. So, but this is a really, really good movie. A little hokey in some of the shooting scenes, you know, as was typical of the movies back then. But a real good movie. Black and white still, but I really enjoyed it. Good movie. Second movie I see you second pick is something regarding the COVID that we all know and love so much it's been going on. And this may or not be controversial, but it's called the Great Barrington Declaration. And it's something that was put together by Professor of Medicine at Harvard, Professor at Oxford University and Professor at Stanford University. And it's just talking about better ways to handle the epidemic as a whole, talking on post focus projection, focus protection, the idea being that as they put it forth. And I tend to agree that we should, instead of living in lockdowns all the time, we should be able to go out and live our lives and focus on those that we know the virus goes after, which tend to be the elderly with the underlying conditions. There's a lot to it. There's a lot been written about it, both pro and con, you know, in the media. So I'm worth checking out and you can find that at gbdeclaration.org. 

DAN_SHAPPIR: Cool. Okay. I'll go with my picks. So my first pick is the so we've been talking to various people who've been through boot camps over the past couple of months. Last episode was with, that we recorded, was with Laura Harvey who's actually in boot camp right now. In the past we've spoken with Matt Crook who I think finished already with his boot camp and we've talked to other people about boot camps. I know that AJ is preparing a course for people who are going through boot camps, a video course. So one pick that I have for today is the fact that my daughter, my youngest daughter, child, enlisted in the Israeli army today. In Israel, we have mandatory military service for men and women. So starting today, she is literally in a real boot camp, not code boot camp, but an actual boot camp. Sorry. 

AIMEE_KNIGHT: I was just going to say that's exciting, scary, exciting, a lot to be proud of, I'm sure as a parent.

DAN_SHAPPIR: Yes, it's not, yeah, a lot of feelings going on. Like you said, on one hand, I'm really proud of her. On the other hand, it's not easy. You know, she's always been our baby and now she won't be home for a while and it's going to be a challenge for her. And especially in times like this, with COVID impacting everything, even this, it makes everything more challenging. So that's my first pick, just wishing her all the best in her quote-unquote military career. We'll see how much of a career it ends up being. And my second pick is I've been enjoying this series a whole lot. I really love the first season, which is The Boys, and I'm now watching season two. It's on Amazon Prime. I know that this is not for everybody. It's pretty raw and rough series. It's mostly about violence, not so much sex and nudity. They actually had a bit of sex and nudity at the beginning of the previous season, but it seems that the further away we're moving from Game of Thrones, perhaps the less they feel the need to include that in the series. But anyway, it's very irreverent. It has social criticisms, and it's lots of fun, and I'm really enjoying it. So that would be my second pick. And now you, Mark, do you have any picks for us? 

MARK_VOLKMANN: I do. This is going to be perhaps a little bit of a throwback pick. Sometimes there's a software technology that seems cool at first, and then for unknown reasons, it sort of slips out of view and other things become more popular. And then you look back at it years later, and you wonder, why did we stop using that thing? So for me, this is something I learned about from Scott to Linsky on the syntax podcast It's a framework that you've probably heard of called meteor and so media I think is about eight years old now at least that old and So Scott to Linsky is a big fan of this framework nd he recently has been blogging about how it can be used in conjunction with svelte and so I thought I would give it a try and see if there's something there and boy is there. I would say there are three main reasons to check out Meteor. The first is if you want to write an app where you have real-time updates between multiple clients, it makes it so easy to do that. It's using web sockets under the covers. And so you can make it so if a user does something in the app, other users can see the effect of that immediately. So one way that you implement these things is through something called Meteor methods which are sort of like REST services, but they don't communicate with HTTP, they communicate with WebSockets. And in the Meteor framework, you're just writing a JavaScript function and you say, I'd like this to be a Meteor method, and then it just communicates with WebSockets. You don't even write the code to make it do that. And then the third thing I would point out is if you need to write an app that has user account management, users need to sign up, they need to have a username and a password, you want to validate their account by sending them an email and seeing if they click on a link in the email, they need to have a way to change their password. All of that is just built into Meteor. You don't have to write that code anymore. I guess the one stipulation there is that it's going to store the user account data in a Mongo database, so if you're okay with that, you can get all that user account management for free. On that note, Meteor just has really good integration with Mongo. If you want to use the Mongo database, that's a really easy path to implementing persistence in a web app. Meteor works with any front-end framework or I should say almost any. React and Vue and Svelte are all in that group that are supported. It's a really easy way to get some neat capabilities into a web app. 

STEVE_EDWARDS So it has its own default backend with Mongo, and then you can use any frontend. You can use other end backends. So if you wanted to do like Laravel for instance, or Node.js or something like that, or how does that work from a backend standpoint? 

MARK_VOLKMANN: Right, so you still can, for example, use the Fetch API to send any HTTP requests you want. And so any REST services implemented with any technology could be invoked from a Meteor app.It's just, they make it especially easy if you want to do it using web sockets, using their Meteor methods, but everything else is still on the table. 

STEVE_EDWARDS Yeah. Sort of sounds similar to some, a guy we talked to on our podcast, Jonathan Rynick does something called inertia JS, which sounds similar in that it's sort of the middle where between your back end and your front end, whatever you want to use, but it sounds like Meteor has a lot of stuff baked in. 

MARK_VOLKMANN: That's right. 

STEVE_EDWARDS I think so. Yeah. I listened to that podcast as well. He's always talking about Meteor. So yeah, definitely a cool tool. So I think I remember what happened. I think he was using Meteor and then it really, the development of Meteor really slowed down for a while and was starting to die off. And then I think, I don't remember who it is and you might know this Mark, but somebody bought Meteor, took over Meteor and so things have sort of ramped up in terms of Meteor development lately. 

MARK_VOLKMANN: Yeah, there's a Canadian technology holding company that purchased them within the last year. And so it's picked up again I have a very detailed blog post about Meteor that is at my blog site. And so we can share that link in the show notes and you can find my article on Meteor along with a lot of other web related topics. 

DAN_SHAPPIR: Speaking of that, Mark, if people do want to get in touch with you and I know that you blog a lot and obviously have the book out, how do they get to you and to all your content? 

MARK_VOLKMANN: So my Twitter is mark underscore Volkman. Bulkman has two ends at the end. So that's probably the easiest way to get in touch with me. 

DAN_SHAPPIR: And we'll share a link to your blog in the show notes. 

MARK_VOLKMANN: That'd be great. 

DAN_SHAPPIR: And also maybe a link to your book. Where is the best place to purchase it? 

MARK_VOLKMANN: Well, you can purchase it directly from Manning. As a lot of people know, Manning frequently has sales on their books. So maybe wait for a good sale and pick it up. But as of today, it's also shipping from Amazon. 

DAN_SHAPPIR: Cool. 

AIMEE_KNIGHT: Subscribe day. 

DAN_SHAPPIR: Yeah. Cool. So with that, I guess we'll wrap up another episode of JavaScript Jabber. It's been a really interesting conversation for me. I certainly learned a lot. So thank you for that. And I hope all our listeners have as well. So goodbye from us. 

STEVE_EDWARDS Adios. 

MARK_VOLKMANN: Thank you. Bye all. 

AIMEE_KNIGHT: Bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y dot com to learn more.