DEV Community

Svelte Radio

Svelte and Sapper in Action with Mark Volkmann

Mark Volkmann has written a great book on Svelte and Sapper. We sit down with him to talk about his background, what's in the book and some more philosophical developer stuff! Keep your out on Svelte Society twitter account. We'll be giving away two copies of the book!

Sponsors:


Show notes:Transcription:
[00:00:00] KAK: Hey, everyone. Welcome to another Svelte Radio Podcast. Today, we have another guest with us. Before we get to that, let’s do introductions. I’m Kevin. I run Svelte School and I’m heavily involved in the Svelte Society community stuff for Svelte. Yeah, that's me.
[00:00:18] SW: I’m Shawn I work at AWS on developer experience. Most recently, I’ve also been working on finally shipping my own site in Elderjs, which is the new Svelte static site generator. It's very fast, because it basically ships almost nothing. Yeah, I really like it.
[00:00:38] AJ: Hi. I’m Antony. I’m a CTO at Beyonk, which is a platform for experienced booking. I’m also a Svelte core maintainer. I’m involve with Svelte Radio, Svelte green tea, apparently a lot of stuff that I don't know how I got involved in, but there you go. Yeah, thanks.
[00:00:55] KAK: All right. The guest for today is Mark. Mark Volkmann, is that how you say it?
[00:01:01] MV: That's correct.
[00:01:02] KAK: Yeah. What's your deal?
[00:01:05] MV: Yeah. I’m a software consultant in the St. Louis area in Missouri. I work at object computing. We provide training and consulting and all kinds of software development. These days I mostly focus on web development, but I really work in the full stack.
[00:01:22] KAK: Awesome. You've written a book on Svelte, right? It's probably why you’re here.
[00:01:26] MV: That’s right. Exactly.
[00:01:29] KAK: How was that experience?
[00:01:31] MV: It was quite challenging. I have a long history of writing. I write a lot of articles for my company that get published on our website and sent out to subscribers to those articles. I’ve been speaking at conferences and user groups for a long time and teaching classes. I had a long history of writing. This is the first time my writing has been examined this closely by a large number of reviewers. It was quite an experience trying to deal with all the feedback that I was getting.
[00:02:01] KAK: Nice. Why Svelte?
[00:02:03] MV: For me, it's all about developer experience. There's so many reasons to choose Svelte, but I really focus heavily on at least my own productivity. I find that I’m just way more productive in Svelte. A lot of that has to do with the features that are built in that make things so simple and result in you writing less code to get things done. For me, some of the top features are the way that you deal with state inside a component and the way that you share state across component using stores. Both of those are just so much simpler than what I see in any of the other web frameworks.
[00:02:41] AJ: Yeah. I like this part that actually – I liked it so much that I took a screenshot of it. In chapter five, you have this table on component communication options and you've got props, slots, events, context, module context and stores and I think that's a really good recap of how these things go. I don't know. I never had it put so clearly to me. but I do have a special preference for stores. They were the first Svelte talk that I did at the New York City Svelte Society meetup.
[00:03:08] MV: Right. When you compare it to what you have in other frameworks, like Redux and React, or Vuex and Vue, or NGRX and Angular, it's just a night and day difference in the complexity level.
[00:03:19] KAK: Yeah. Your book is pretty comprehensive. I’ve skimmed through it, read parts of it. It seems like the tutorial, but on steroids. It covers pretty much everything. It feels like a good next step after doing the tutorial.
[00:03:37] MV: Yeah, I think that's right. I would recommend that people go through the tutorial, because that's excellent. I did really aim to show almost every feature of Svelte and Sapper and have a simple code example of everything. Then show it in a wider context in a sample app that we build throughout the book.
I think, even for myself it will be a reference going forward to look up how to do various things. That's really the style of my writing on other topics is to be a reference that I can go back to when I forget how to do something, which is quite often because as developers, we have so many things to remember that we just can't – we have to have a resource to look things up from time to time.
[00:04:18] SW: Yeah. Absolutely. I noticed when I was – I was actually reading the book from when it was in more early stages, so there were obviously chunks missing, the stuff I was reading it online. I noticed that there were URLs and things like that that were probably due to go out of date pretty quickly, I just wondered as a person writing a book for something that is quite fast-moving technologically, how do you keep track of what's changed and what you need to update and what hasn't?
[00:04:41] MV: Yeah. That's a tough challenge when it comes to URLs. The editor from the publisher encouraged me to not include very many of those things. I push back on that. I understand things go out of date. I would rather have good material out initially that will go out of date than just skip it all together. My tendency was to include as much as possible, even if there was a danger of it going out of date.
An example of this is that in the chapter where I talk about different ways that you can deploy a Svelte app and I get into some details about services like Netlify, so I was listing a lot of details about the plans, including the prices. They didn't want me to include the prices, so I ended up scaling it back to just describe the different tiers that are available. I think that was a good compromise. I didn't just want to say, go to the site and see what the current plans are, without trying to give some idea of what the current offerings are.
[00:05:45] SW: On what you can and what you can't do with each tier. I think that's really good. It’s also nice.
[00:05:49] MV: That's right. On that topic, that's an example where the things I’m discussing in that chapter are not very specific to Svelte. They're just something that you would want to know as a web developer. There are a lot of chapters in the book that are like that. For example, when I dive into details of kinds of testing you can do. At the unit test level, there are some things that are specific to Svelte. Then when you get into end-to-end testing, or accessibility testing, that has nothing to do with Svelte. I wanted to include it anyway, because it's part of the workflow that you'll go through when you write a Svelte application.
[00:06:23] SW: On that note, would you say that the desired audience of your book is a developer getting into web development? Or, would you say it's more of a Svelte user, or would you say it's more like an advanced post-tutorial Svelte user, or does it cover all three?
[00:06:36] MV: I want to believe that it covers all three. It's certainly good if coming into it, you have some idea of the process of web development. Maybe you've used some other framework before. Then what I’m showing are the specifics of how to do those things in Svelte, but also the things that don't have to do with Svelte; as I said, things like end-to-end testing. If you're aware that end-to-end testing is a thing that exists, the book will help you get into implementing that.
[00:07:07] AJ: Cool. I wanted to call out some of the things – I think, just reading through some parts of the early chapters, I want to call the things I really liked. I thought it was very approachably written, but you weren't really talking down to people. It's always a nice balance as to how much you want to explain, versus how much you assume that people bring their context. I really like the await example uses dog CEO, which is exactly what I use.
[00:07:33] MV: Oh, nice.
[00:07:35] AJ: That endpoint. I was trying to count how many examples you worked out, but it's got to be dozens. Every single chapter, every single sub-chapter has a different example. Yeah, I really appreciate that. Actually, would be a good to have a list of REPLs at the end of here's everything that we walked through. Those are really good.
[00:07:57] MV: Interesting that you bring up the REPLs, because as I just found out yesterday, I was invited to speak at Svelte Summit coming up. I’m going to be giving a talk on animations. That's straight out of chapter 10 in the book. It has a number of examples. and I have REPLs for all of those. In that talk, I’ll be giving URLs to all of those REPLs and we'll walk through all of that good.
[00:08:20] KAK: That's awesome.
[00:08:22] SW: Yeah. That's something I haven't really figured out. Are you talking about the flip animation?
[00:08:28] MV: Yes, that's one of them. Yes. That's right.
[00:08:30] SW: I still don't know how it works, so I have to look into that.
[00:08:34] KAK: That would be a good talk for you then, Shawn.
[00:08:36] MV: The crossfade animation can be complicated to grasp what's going on. I’ll definitely cover that. Then a really interesting custom one that I build in the book is one that takes a chunk of text and it makes it appear that it's spinning down a drain. It rotates a couple of times. As it's rotating, it shrinks until it gets to zero size and just disappears from the screen. That was a fun one to implement. What's really surprising about it is how little code it takes to do something like that and it really emphasizes how Svelte animations are built on CSS, which of course gives excellent performance and doesn't block the main thread, all of those benefits.
[00:09:19] SW: Yeah, you can pause and reverse it midway. That's always like a “Oh.” Like, “I haven’t really thought about that.”
[00:09:27] KAK: Right. I had a question on the chapter just before that, so the chapter just before that, chapter 9 is on routing. That's notably a sore point in Svelte. Did you have any struggles writing that chapter?
[00:09:38] MV: I didn't have any struggles, because I’ve done so much of that in other frameworks. I think my opinions on that don't line up with a lot of other people's. It seems that there's a sentiment now that people want there to be an official router that ships with Svelte. For a lot of applications I write that are smaller, they don't need for the URL to change when I go to what you think of as a different page in the app, because I don't need the users to be able to bookmark a page inside it.
I understand there's a lot of apps that do need that. If you don't need it, you can just have a hash map of this name goes to this component and I have a store that tells me which one is the current name. It's really easy to write the code that just displays the correct one. That's what I refer to as the manual routing approach in the book. Then going beyond that, if you need the URL to change, it's so simple just to use hash routing. The only negative I know of is that some people don't like seeing a hash symbol as part of the URL.
[00:10:42] KAK: Now a word from our sponsor. Are you looking to get better at building websites in Svelte? Well. you're in luck. Level Up Tutorials has tutorials on how to get started. Scott is an excellent teacher and has courses on a broad range of web development topics. If you want to support the show and learn Svelte at the same time, check out the Svelte for beginners and Sapper for beginner courses at svelteradio.com/levelup.
Svelte Radio is currently looking for another sponsor. If you're interested in seeing this show continuing and want to support it, you can reach out to me. I’ll drop a link in the show notes as well.
[00:11:24] SW: Right. I think you mentioned before we had a small break that you have a pretty simple approach to hash routing, mainly because it fits your requirements and some people just don't like the optics of having a hash in the route. If you don't mind that, then the solution for that can be pretty simple and it's pretty easy to integrate with Svelte.
[00:11:45] MV: That's right. If you decide you don't want to use hash routing, the next thing I talk about in the book is using a library called page.js, which is not specific to Svelte. That's also a very easy option and it's more capable than rolling your own. I think some people are looking for a more Svelte-specific solution. I know that there are some out there. I mentioned a few in the book. One in particular, Routify, seems to be getting pretty popular now. Then the other thing I would mention is that if you really want a nice routing solution, maybe you should just use Sapper, because it's all built in and Sapper’s routing is also very, very good.
[00:12:23] AJ: It's funny that you mentioned people want to Svelte specific solution, because that seems to be quite the thing. If you look at anything like React or Vue, you'll find that people like to have these REPL libraries that wrap existing vanilla components, such as page.as. What I found, obviously one of the things I like about Svelte is that you don't have to have these REPL libraries. It's very easy to integrate vanilla JavaScript libraries with Svelte without any intermediary, or wrapping thing around it. Yeah, it's interesting that people want a Svelte specific solution to routing, although obviously, it's quite nice to have that.
[00:12:54] MV: Right. It reminds me of the way that a lot of Angular developers will say, “How could you use a framework that doesn't give you a solution for creating HTTP requests? Don't you have to have that?” Why they think that fetch API isn’t sufficient is not clear to me.
[00:13:13] KAK: That always gets me when people ask about Axios, that's another one of those libraries, right? I get that it supports probably some obscure Internet Explorer version, but just seems like a lot of work to when you have fetch.
[00:13:30] AJ: Right. I mean, so the fetch polyfill supports that as well, right?
[00:13:34] KAK: Right.
[00:13:35] AJ: In about three lines.
[00:13:37] SW: I come from mainly React experience. I would say, for React it's actually needed, mainly because it's so strongly opinionated in the functional programming sense that you have to adapt it, use the data with component life cycle methods. Now you have to use effect and it's always dark magic, so much so that they don't they recommend that you don't write your own and then you use other people's REPLs.
That definitely grates me a lot, like I don't want to look at my package JSON and have React-Redux- and then a billion other things that I also import. I definitely appreciate that about Svelte. I think the phrasing that I adopt from Rich Harris is that, let's stay as close to the metal in terms of the native language of the web, which is HTML. Then when you write components, let's stay close to that. Surprisingly, it's a lot easier to integrate everything else.
[00:14:25] MV: A thing related to this in the book is that in chapter one, when I’m describing the features of Svelte, I’m comparing it to other frameworks, like Angular and React and Vue. Early versions of the book were a bit more negative about the other frameworks. I was encouraged to tone that down as to not offend people. At the same time, if you don't draw comparisons then people don't have a reason to Svelte over the other options.
I’ve done a lot of React development myself. I’ve also worked in Angular and Vue, but I have the most experience in React. I’ve been away from it for a bit doing mainly Svelte, but I’ve had to help some other developers in my company with React applications. It's interesting going back to it after being away for a month or two, seeing it with fresh eyes. I think there's a boiled frog thing that is happening, where if you're in any of these ecosystems, you gradually learned how they work over time. When one more feature gets added, that doesn't seem so bad. It's just one new thing and you already know the previous 20 things, so it's all good.
It's the boiled frog scenario, where you don't realize the water is getting hotter and it's getting hotter. If you can break away for a month and do Svelte and then go back to some other framework, I think you'll be shocked at how complicated the code seems and you just didn't realize it before, because you were in it every day.
[00:15:53] KAK: Yeah. That's my experience as well.
[00:15:55] AJ: Yeah. I think that's reasonable. I think obviously, criticism can come in many forms. I think, criticizing to draw comparisons maybe is warranted, but it's got to be done in a way that doesn't rile people up, because there's no point, I guess, warring over frameworks. You use the one that's best for the thing you're trying to achieve. Obviously, I’m quite heavily biased here. I think that in my opinion, my experience even, it's almost always been Svelte has been the ideal framework for that task and it really is quite adaptable to stuff.
[00:16:25] KAK: Yeah. Really is.
[00:16:27] SW: I’ll go even further. Most people don't pick frameworks because of the quality of the framework. They just pick it because of the jobs available. I mean, that's how I got to React. The only thing you look for is okay, how do I become a React expert? How do I get advanced React? Things that are complicated actually give you value, because then you can turn around and say like, “Hey, you can hire me because I know all these things.” You don’t really question like, do we actually need all this stuff? That's a similar journey. I call it Stockholm Syndrome. I wonder, Kev, living in Stockholm if you've – Swedish people call it Stockholm Syndrome or not.
[00:17:04] KAK: We do call it Stockholm Syndrome. Maybe not the reaction, but – You do know where it comes from, right? The –
[00:17:16] AJ: – Kidnapping.
[00:17:18] KAK: Yeah. Or was it a bank robbery? You guys know better. I have no idea. All right. Getting back to the book, one of the downsides that I think you mentioned – We mentioned Sapper, so I thought it was a natural transition point. One of the downsides that you mentioned is that Sapper is not 1.0. You seem pretty in favor of Sapper. Obviously, it's a big part of your book. What are your thoughts on Sapper and production readiness and versioning and all that stuff?
[00:17:44] MV: Well. I hear a lot of talk among the core contributors that there could be changes coming in regards to modularizing parts of Sapper breaking it up. Maybe some things that are built into Sapper now won't be built in later, but will be an optional thing that you can use if you want to. I just feel there's so much benefit you get from Sapper, that even if in the future I would have to make some changes to an app to work with the new version of Sapper. I think it's worthwhile.
There's just too many good things in Sapper right now, amazing things like how code splitting works and how pre-fetching works. I think with every feature of Sapper, you could conceivably just use Svelte and hand-add those things yourself, but that's just too much work. You might as well start with those things out of the gate. I would not shy away from using Sapper now, even though it's not 1.0. I would just be ready to make some changes in the future. I’m guessing that it won't be hard to make those changes.
[00:18:49] KAK: Yeah. Do you have any inside information for us?
[00:18:53] MV: About how it's going to be split up?
[00:18:55] KAK: No. I’m asking Antony if he has any –
[00:18:58] MV: Oh, okay.
[00:18:59] KAK: - any inside –
[00:19:00] AJ: Inside information. I mean, I don't think there's a concept of inside information. I think that would be against the open source framework of mentality. There are definitely discussions about breaking Sapper up, either becoming a series of plug-ins, or it becoming some a thing that pumps out against units of application that are not one big monolithic application, in order that you can deploy them more cleverly, or to gain speed, or performance optimizations.
It's all really up in the air. The best place to find out about it is the RFCs. There are a lot of RFCs open right now and a lot of them overlap, or depend on each other, which is obviously a bit confusing. I think it's a matter of yeah, having this wider discussion to determine really what people want and what is optimal, what is doable. Hopefully, checking things like HMR and stuff in there, which has been requested for quite a long time.
Yeah, there's lots going on. I think Mark is absolutely right. Modularization is one of the main things. I think that the crux of that is because maintaining obviously, Sapper is quite unique in that it supports any bundler. It's not opinionated about what bundlers it uses. When I say any bundler, I mean, any of two bundlers; webpack or roller.
The reason that it can do that and the reason that it is also a problem is because that means it's got to be quite heavily baked into the core of Sapper. I think that one of the main goals is to get – just to pull it out and extract that, so that either it becomes completely bundled agnostic, or it becomes completely bundler specific. One or the other will definitely be an improvement on where it is now. Yeah, there's a lot going on. A lot going on.
[00:20:38] KAK: Oh, exciting. I saw one issue about 0.29 that Ben opened, I think.
[00:20:45] AJ: Yeah, Ben’s working on 0.29. Well, so working on it. He writes most of the PR. To be honest, he's a machine. I don't know how he does it. He also manages to triage all the things together into releasable units of code. Yeah, it's really good. 0.29 should be again, a quite a minor change. Nothing breaking, but quite a nice change. Then meanwhile, Li Han Tao is – I can't say his name. Tan Li Hao.
[00:21:12] KAK: Li Hao. Li Hao.
[00:21:12] AJ: Li Hao Tan. I got it right, fourth, sixth time. Showing it right. I always get the names mixed up. Essentially, he's busy working on all the PRs to Svelte itself, so a lot of the commits there right now, which are quite hard to review, because they're quite intrinsic, but some pretty exciting stuff going on there that's been in in-demand with quite a while, like slots and stuff.
[00:21:32] KAK: Exciting. All right, so let's get back to the book. I have some questions in general about writing about Svelte. Because for me, some parts of Svelte are a bit harder than others and I’m just curious which ones do you find the hardest to explain so far.
[00:21:49] MV: Yeah. I would say, one of the most difficult parts to write for me was when I was trying to explain how service workers are supported by Sapper. I only had minimal experience with service workers myself, so I really had to dig in and describe all the different caching patterns that you can implement, which is another example of a thing in the book that's good for web developers to know, but maybe isn't so specific to Svelte.
That was probably one of the most challenging parts of the book. All the rest, I could generally learn from looking at the tutorial and looking at the API and writing some sample code. Before I even got involved in writing the book, I had already written a fairly long article about Svelte. I think it's around 45 pages. That's linked in the link that Shawn shared to my other articles. I had that as a starting point before I even began on the book.
Interestingly, Manning was a little hesitant to have me start on it, because I had written that article. They have a feeling that if you've done a lot of the writing before you contact them, they won't be able to get you to change it to fit their writing style. That was a challenge, because I have a habit of really focusing on seeing how few words I can use to describe a thing. That's not what book publishers are looking for. They want more flowery kinds of sentences. I’m not used to writing in that way. I’m used to trying to be very concise in my explanations. There are more words in the book than there would have been if there were no editors. Maybe it results in something that's easier for people to read, but not all of it is exactly my normal writing style.
[00:23:36] KAK: That's interesting.
[00:23:37] SW: Was it a stretch, like yeah. I have a question about the book writing process itself, because I’ve never written – I’ve never worked with a publisher like Manning. Was it a hard sell to even pitch Svelte as a market that they might be interested in? Or how is that?
[00:23:50] MV: It was very hard. Without naming the publishers, I’ll say that I was approached by a lesser known publisher before I got started, asking me to write a book on Svelte, because they saw that article. I didn't want to do it because I thought that it wouldn't get marketed very well, because this was a smaller publisher and then I wouldn't sell very many copies.
Then I thought, well, if there's some interest in this, I ought to approach some bigger name publishers and see if they would let me write for them. I was rejected by two big ones who thought that there wasn't enough market yet. Then finally, Manning accepted. That was discouraging that I couldn't get some of the other publishers to be onboard. Yeah, that was tough to get going.
[00:24:35] AJ: Sounds like their loss there, Mark.
[00:24:38] KAK: It's really the chicken and the egg problem, right?
[00:24:41] MV: Right. Yes.
[00:24:43] KAK: Yeah. I mean, I think that's a lot of what the work is left to do with Svelte, which is the code is great and then we need to create a lot of noise around it, create a healthy community that looks like there's a lot of stuff going on. That's where publishers are looks to those kinds of secondary indicators to evaluate these things. We all have to do our part.
Then we can show someone's written a book on it and then that will be the basis point for other people also writing it as proof points for other pitches, like adopting it at work, or writing their own books.
[00:25:14] MV: Right. You're asking about the process of writing the book. One thing that I didn't know before getting into this was the number of different kinds of people that would be reviewing the book for me. Maybe the process is a little different based on the publisher, but at Manning, you are assigned a development editor that helps you get started with the book. This person is responsible for knowing the pattern of Manning books and making sure that your book fits the pattern.
They're not necessarily a technical person. They're just good at English and grammar and they know Manning books. Then you're assigned a technical editor and then many other technical reviewers that are looking at everything. Then there's a person that's responsible for executing all the code in your book to make sure that they can get it to work on their machine. Then finally, there's a copy editor that is extremely picky about everything that you've said.
One interesting part is that when you're getting started and you're working with that development editor that is not so technical, a very frequent piece of feedback that you'll get is do you think readers will know what this term means? Most of the time, the answer is, “I sure hope so, or they shouldn't be reading this book.” They don't know, because they're not a technical person.
Just to give you an example. Of course, when you first start talking about Svelte, one of the things you have to say is Svelte is a compiler. I get the feedback, will the readers know what the word compiler means? I ended up having to add a note in the book to explain what a compiler was. I would hope that most people that want to learn Svelte already know that word.
[00:26:59] AJ: Can I interject with an interesting story here that’s related? A few years ago, I used to work for J.K. Rowling, the Harry Potter lady.
[00:27:06] SW: Oh, no way.
[00:27:08] AJ: Yeah. Obviously, she’s got a whole publishing company that's built into her main office where I worked. They have a girl they employ there who works for the publishing side, who is actually – she's the Harry Potter bible. Everything that J. K. writes, she then reviews to make sure it's factually correct, which I think is so – it's almost back to front, so I found it really amusing. Yeah, she fact checks for consistency and chronology, because there's multiple chronologies in Harry Potter as well, because there's the real time and then there's a wizarding time and then there's the time when you discover things in the books and it's crazy. Her responsibility is to do all that stuff, which I thought was quite fascinating.[00:27:50] KAK: That’s so interesting to hear how it actually works in publishing. Never really known a whole lot about it.
[00:27:59] SW: Yeah. There's a lot of references to the appendixes. If you need to know what fetch is, go to appendix B, because there's a lot to cover. I appreciate that. There's a lot in there. There's even stuff on MongoDB.
[00:28:12] MV: Yes. Right.
[00:28:13] KAK: Did you guys see that there was an infographic floating around a couple of months, or years ago about the shape of the front? This is what you should know as a front-end developer?
[00:28:25] AJ: Oh, really?
[00:28:26] KAK: It was this huge map of things. It's impossible to have everything in a book. Every year there's one. I think that's a nice point to transition to a little bit more broadly about Mark, your history as a developer. I recommend everyone go to his site. We're going to put this in the show notes. There's two sites; one, object computing, where it has his publication history going back to 2000. That's the earliest one with ant. I don't even know what that is.
[00:28:58] SW: Yeah. Probably for the best.
[00:29:01] KAK: Then there's Mark's own blog on GitHub and that's more recent writing it, looks like. Yeah, how do you think about what you've seen over the past 20 years in terms of your development experience and how your interests have moved? Where you think what development's going, that stuff?
[00:29:16] MV: Yeah. I dropped one more link in the chat, which is just my home page, which has even more links to some technical resources. If you restrict things to web development, then when I started, it was just raw DOM manipulation. Then I got into using jQuery. Then after that, I started using Angular 1. I did that for a few years. Then as happened with most people when there was the debacle of waiting for Angular 2 and it was announced but it wasn't coming and it wasn't coming and then a lot of people jumped on React, I was part of the group that did that. Then Angular 2 came out and I ended up doing some of that all the way through Angular 7.
I have to say, I’m really not a fan at all of Angular. It's my least favorite of the frameworks, because it just seems so verbose, and so much more complicated than the others. Then I got into Vue for a while, enough that I was able to do a half day workshop on Vue at the Midwest JS conference. I wrote a couple of apps in Vue. I like Vue just fine, but I don't like that when you define components, you're defining this big object literal with properties that describe your component. Obviously, I like the Svelte approach much better. That's pretty much my history on front-end web development.
Before that, I was working in a lot of other languages. I’ve done quite a bit with Ruby. Before that, I was a Java developer for about 15 years. Yeah, but these days it's almost all JavaScript. Although lately, I’ve been starting to dip my toes into some Python, just because it seems to be getting so popular and I felt like I should know something about it.
One of the interesting pages you'll see on my blog site, if you go under the Python category, there's a link that says Python compared to JavaScript. That's something that I’ve done very recently. It's a very long blog post, showing side-by-side comparisons of almost every feature of the language. You could see, here's how I would do it in JavaScript, here's how I would do the same thing in Python.
[00:31:30] KAK: Wow. Is that style of blogging a way for you to learn about new stuff as well?
[00:31:36] MV: It is, definitely. It's certainly a pattern that I’ve fallen into is that if I decide a thing is worth learning, then I’ll really dive into it. I have this innate fear that I’ll forget what I’ve learned, and so I have to write it down. Then after I’ve written it down, I feel like, “Boy, it's such a waste if I’m the only one that benefits from this.” I have to polish it up and put it out in some form, so that other people can benefit from it as well. That makes it so I never can say I’m interested in this thing. Let me look at it for a few days.
For me, it's if I’m interested, I’m going to spend two or three months on it and document it well and maybe end up giving a talk on it. I force myself to do that before I’ll allow myself to go on to the next thing, because of that fear that if I don't do it, I’m going to forget it.
[00:32:30] AJ: I mean, it's great, because the output of that is fantastic. Yeah, I think I feel like I dip my toes to things too quickly, and so that move between things a lot. I often feel that should be more – that approach you've got there of doing two months and three months is something and really understanding it before you draw your own comparisons is really valuable.
[00:32:49] KAK: Yeah. It's interesting, because even for Svelte, I think that's the case. At first, you know the basics. Then I’m going to do an action marketing bit here. Because after a couple of months, you learn about actions and then you get really excited about Svelte. I imagine it's the same for most other things, where there are some features you don't really get as a beginner, but then it clicks and you understand it and you get really excited.
[00:33:19] SW: I mean, this blog, I’m still diving into it, but there's so much other very current stuff, like GitHub actions. The way that you use extensions for GitHub, like your GitHub looks totally different from any GitHub I’ve seen. I think there's a lot of serendipity here. The only criticism I have is that you don't seem to have an e-mail sign up, where I can keep informed.
[00:33:41] MV: Oh, yeah. I suppose I need to add that. I haven't looked into how to do that. I’ve never been into RSS feeds, or anything like that. Yeah, I should look into that.
[00:33:51] KAK: Tiny letter. It's free. It goes out to 5,000 subscribers.[00:33:55] MV: Okay. Tiny letter?
[00:33:57] KAK: Yup. It was a startup acquired by MailChimp, but it's free forever. If you get beyond 5,000 subscribers, they'll let you export to MailChimp.
[00:34:06] MV: Okay. I’ll look into that.
[00:34:08] KAK: Yeah. You even have JavaScript temporal, which is the new API coming to JavaScript. You have a whole thing on this and I was like, I would read this as a blog post if anyone existed.
[00:34:20] MV: That's a very recent one that I added the JavaScript temporal part. It was hard for me to figure out what was going on. After I spent enough time with it, a pattern emerged. That's what I’ve documented here. Now it's much more clear to me and I can't wait for this to be finalized.
[00:34:38] KAK: What is that?
[00:34:39] MV: It's the replacement for things like moment.js and date FNS that will be built into JavaScript. Finally, really good date and time support built in.
[00:34:49] KAK: That's awesome.
[00:34:50] MV: Another page here I should point out is the Meteor page. I know you're familiar with Scott Tolinski and Level Up Tutorials and the Syntax FM Podcast.
[00:35:01] KAK: Yes. He's a sponsor.
[00:35:03] MV: He's a big fan of both Svelte and Meteor and combining the two. That got me to take a look at it and see what was really there. Boy, I’m just blown away by that combination. If you go to that page, there's a key benefits link near the beginning that lists some of the most important things about it, the biggest benefits. The use of WebSockets in Meteor is really fascinating as a replacement for what you would otherwise use a rest API for using HTTP requests.
It makes it so easy to write apps where you need to push changes out to multiple clients and keep them in sync. Then another really big thing is if you're writing an app that needs user account management where people need to sign up for an account, they need to be able to change their password, all those things. That's just a built-in feature of Meteor. If you combine Meteor with Svelte, you mostly just get that for free.
This blog page on Meteor walks through an example of building a to-do list app, of course, because that's what you have to do, but it goes beyond that. It's a to-do list app, where you can sign up for an account and you'll get an e-mail back to verify your account. It's storing all the to-do's in a Mongo database, because Meteor has really great integration with Mongo. It keeps the to-do's separated by user within that same Mongo database. It's just amazing how little code you have to write to get all of that. This blog post goes through all of that using Svelte in conjunction with Meteor.
[00:36:40] KAK: We'll drop a link to that in the show notes as well. I really wonder why Meteor never took off, or why –
[00:36:46] SW: Yeah, and I’m looking at it. This is Rails for JavaScript. Everyone wants Rails for JavaScript. Meteor is it. I feel the main issue that they had was sticking to their own hand-rolled UI framework for so long, they had one of these.
[00:36:59] MV: Exactly. That’s right.
[00:37:00] SW: Then also, they have this whole separate other ecosystem, like the Meteor package ecosystem, because they predated NPM, which is something I didn't know when I was trying out Meteor for the first time.
[00:37:08] KAK: That’s crazy.
[00:37:10] SW: I don't know. What do you think, Mark?
[00:37:13] MV: Yeah. I think that's exactly right, that they stuck with blaze for a long time and other frameworks came out, people were interested in those, and so they jumped ship. Then Rest became really popular using HTTP and people forgot about the option of using WebSockets. Now I look back at this and I have to ask myself, “Wait, why are we assuming that it's better to use HTTP?” They just make it so easy. They call them Meteor methods. It's just a JavaScript function you write. You don't write any code to do anything with WebSockets. It just happens under the covers, because you're using Meteor. Yeah, it's great.
[00:37:50] KAK: It seems like some of these concepts are coming back in a way. For example, Phoenix for Elixir works the same way, I think. WebSockets and just sending diffs over the –rather than the whole document between pages. It's pretty interesting.
[00:38:08] SW: React is also looking into it with React Flight. Probably, there will be a new generation of combat between frameworks when I guess, sockets are back in vogue and when we send diffs.
[00:38:21] AJ: Yeah. No, I think I built a real-time trading system for a large oil company, I wouldn't mention the name of. It used WebSockets, rather than Rest for everything. Logging in was about WebSockets as well. It was an interesting experience, because I think that there's just not that level of support for WebSockets. I couldn't just whip out my Rest client and make a connection and see what the payload was and the response. There was no automatic validation, or payload passing. I think that a lot of Meteor methods sound like they built this whole communication protocol by themselves that wraps WebSockets. I think that when there's a mainstream, one of those available off the shelf that might bolster the WebSockets becoming a omnipresent is Rest.
I think, I don't know of one. Maybe there is one I haven't looked very hard into it, but I think that would be a massive factor in WebSockets becoming more mass adopted than they used to be, something that's not socket AI, which obviously is quite large, quite unwieldy.
[00:39:16] SW: I don't know anything about how it's handled on the server side, but don't you have to keep the socket open, which means that it's hard to scale?
[00:39:22] AJ: Yeah, you do. It's a one-to-one thing, isn't it? Several sockets are quite rare still.
[00:39:28] SW: That would be why.
[00:39:32] KAK: All right. Any last few questions?
[00:39:35] SW: Yeah. I have a topic to end things, if no one else has any questions.
[00:39:39] AJ: Sounds good.
[00:39:40] SW: Yeah. Mark’s quotes seem pretty important to you. They're plastered all over your blog. Could you talk a little bit about why quotes are that important to you and do you have a favorite one and what that means to you?
[00:39:51] MV: I think it's just providing some motivation for me. I see a lot of people that run their lives in a way that doesn't match up with the quotes that you're referring to that are on my blog post. If you click on the quotes link, you'll see them. Most of these are quotes from other people. There are a few that are just my own quotes. Like the very last one, “Respect the distance. Do the work.” That one is related to the fact that I’m a marathon runner and I see people sometimes thinking that a thing maybe is easier than it really is and not willing to put in the work to get it done. Obviously, doing something like running a marathon, there's so much training that comes before the actual race that you need to respect how hard it's going to be the distance and putting the work ahead of time to get the result that you're wanting.
The same thing is true of software development. I know that people don't want to have their entire lives be studying software development, but I find that if all you're willing to do is put in eight hours a day, it's going to be really tough to progress and learn some new things. Certainly, you don't want to run your life by just always studying software development. There's a distance to learning things and you need to do the work to get the results that you want.
Another quote that's in there, “Don't be a dabbler. If you're going to do something, do it well.” That relates to what I was saying about how I try not to allow myself to just look at something briefly. I don't want to dabble in something. If it's worth doing, I want to do it well. Then I’ll move on to something else after I’ve done it well.
Yeah, so those are quotes that I put in from myself. There are a bunch from Michelangelo that are in here and one from Theodore Roosevelt. My daughter gave me a birthday card one year that had that Theodore Roosevelt quote which says, “Far better is it to dare mighty things to win glorious triumphs even through checkered failure, than to rank with those poor spirits who neither enjoy much, nor suffer much, because they live in the gray twilight that knows not victory, nor defeat/”
A summary of that is you need to work on some hard things and you might fail. That's better than not trying. It's better to dare to do some mighty things. Try even though you might fail. That's also true of software development. Some things are really hard to learn, but doesn't mean you shouldn't try.
[00:42:25] AJ: It's interesting. I noticed, sorry, on your blog, well you're on your homepage rather, you've got a link to English buried in the middle there and how you change the English language. I think that's interesting, because it goes along with what you're saying about you write very concisely and very tersely. It's because you just leave off words that aren't redundant. Then if you've read the book, I think it's called Troublesome Words by Bill Bryson. He's written an entire book on this exact subject that people say lots of redundant fluff that doesn't need to be said, because it's obvious. It's implied in the sentence.
This is very similar writing to that. It's very interesting. Yeah, tell me whether or not you like cheese. Well, don't bother with or not, because it's possible that you might not. It's implied if you like it, if you don't then you don't like it. It's interesting.
[00:43:14] MV: Right. Exactly.
[00:43:16] KAK: I need to read that book.
[00:43:17] AJ: Yes, good book.
[00:43:20] KAK: All right. I guess, that's it. Do you guys have picks? Can be anything?
[00:43:26] AJ: I do.
[00:43:28] SW: I didn't think about picks. Oh, so Mark, we end the episode by just talking about things that we've enjoyed, or things that we recommend. Then we always look around our desk for – 
[00:43:41] KAK: Because we always forget it. Yeah.
[00:43:44] AJ: I have three picks on my desk. This is great, actually.[00:43:47] SW: Go for it. Go for it. Go for it.
[00:43:50] KAK: Let’s hear.
[00:43:51] AJ: My pick from last week, did I talk about the Garmin GPS unit?
[00:43:54] KAK: Yes.
[00:43:55] AJ: I did. Right. Good, because that's on my desk and I wouldn't have covered that. I’ve got to pick this instead. Then this is my pick. This is and people listening to the audio have to see it, but this this is a tiny little computer on a stick that can run things, like Windows, because it's a proper Intel processor. It's not a Raspberry Pi that has an ARM processor. Obviously, you would never use it over Raspberry Pi, because it's slower, it's more expensive and fundamentally, only if you want to run windows or something.
I think it's actually, it's some low-end Intel processor. It's got 2 gigs of RAM. It's got some on-board SSD storage, but it's got – it runs off a 5-volt USB, single USB and it plugs into any HDMI port, so you've basically got a monitoring keyboard, plug the USB in there, done. It's got a tiny little fan in it, because it gets quite warm, because it's got a non-efficient processor in it. It is perfect for browser testing. I can actually keep it running in my house all day long with almost no power usage at all. It's relatively silent, because the fan's tiny, only spins up now and then. I just think it's dead useful, if you need to do anything Windows locally. I don't use Windows locally, so I don't have a Windows machine apart from this. It's perfect for that thing. I think that my pick is just the handiness of having a pocket-sized windows machine on hand when those rare occasions, I won’t have to boot into Windows to do something.
[00:45:17] KAK: Nice. I didn't know there were stick computers. That's pretty amazing.
[00:45:23] AJ: I just googled it one day, because I thought this is what I want and it exists.
[00:45:29] KAK: Yeah. All right, Mark you have a pick here.
[00:45:32] MV: Yes. I was planning to make my pick be Meteor, but I’ve already talked about that a lot. I could have also picked the JavaScript temporal library, but we've already talked about that.
[00:45:44] SW: I’m sorry.
[00:45:46] MV: I will pick Jupyter Notebooks. As I’ve been diving into Python, that leads you into looking at Jupyter Notebooks. It's just fascinating. In general, the idea behind a Jupyter Notebook is that you've got this vertical series of cells and each cell usually either holds markdown, or it holds a snippet of code. You use this for experimenting with different things in a programming language and the markdown is there to document what you're doing.
In the case of Python, you might have a markdown block, then a Python block, then another markdown block, then a Python block, but all the code blocks are really part of the same bit of code. If you declare a variable in one block and then you can use it in a subsequent block. Then later, you can export that as one Python file and run it as one program.
Well, it turns out that you can also use JavaScript with this, so there's a node.js kernel that you add to Jupyter. Then those code blocks can be JavaScript, instead of Python. Also, recently VS code added support for Jupyter Notebooks. A Jupyter Notebook is just a JSON file. If you open it inside VS code, you can do the same things right inside VS code. Those code blocks when you execute them, it shows the output of that bit of code right below that block. It's a great way for experimenting with code, like a REPL, but even better because of your ability to split up the code into separate blocks and insert those markdown blocks. I highly recommend taking a look at Jupyter Notebooks.
[00:47:24] AJ: Sounds good.
[00:47:24] MV: I dropped a link in the chat of my documentation of what I’ve learned about Jupyter.
[00:47:31] AJ: Cool.
[00:47:32] KAK: All right. Shawn, what is this? I don't like this. No, I’m just joking.
[00:47:37] SW: I was going to say, I love how you write down your learnings for everything that you come across. It's something that I really like learning in public, but I think you are a master at this. I’m just very impressed by your blog. I would also recommend, have you checked out observable, since you are a fan of D3, Mike Bostock who created D3 also created observable, which is Jupyter, but for the JavaScript ecosystem?
[00:48:00] MV: Yeah, I have seen that, but I haven't learned how to use it yet.
[00:48:03] SW: I mean, from what I could tell, it's exactly the same as a Jupyter. Just that itself hosts the JavaScript so you can just interact with it while it's running. Yeah, cool. I’ll go next. Tailwind is a CSS library, which it seems like Kevin is not a huge fan of. Rich is also not a huge fan. I don't know why it's so hard. I should probably write a blog post about why Tailwind and Svelte go together. It might seem like an odd choice, because Svelte obviously has scoped CSS next to it. Even with those benefits, I think Tailwind comes with it.
They've recently been picking up in terms of their commercial efforts and they hired a new developer, Simon, who got me started on this whole journey. He just put out a YouTube series detailing what's new in Tailwind. It really gives you the taste of what it's about, like what the benefits are. For example, imagine adding animations just by adding a single class name. If you need something to bounce when someone's hovering over it, or for example with Svelte, when you do it like a class binding to that class name and it's an animation, typically in CSS, you'd have to do a bunch of keyframes here and then put the animation on the thing. Then with Tailwind, it’s just a single class name. I think those are really good examples. He launched a series of 12 YouTube videos. Very short. Takes half an hour to go through them to see what's up in Tailwind. That's my pick.
[00:49:26] MV: Yeah. I should watch those videos, because I haven't quite come onboard with Tailwind yet. Maybe I can if I watch the videos. For now, my hang-ups are that I feel like if I’m going to add a bunch of Tailwind classes to an element, right away I’m making the statement that there's nothing else in my app that wants that combination of things. I’m opting out of sharing that, because I’ve said, “No, this is specific to this one element.” I need to figure out how to get over that if I can.
Then the other is that when I’m looking at a Svelte component, I feel like if it's just HTML, I can clearly see the structure of this thing that I’m building and it's not clouded by a bunch of CSS classes being added to it. I feel like, if I move everything out of the style block onto the HTML elements, now the structure of my HTML isn't going to be as clear to me. Those are my current hang-ups.
[00:50:21] KAK: Yeah. I think the one thing I have against Tailwind isn't so much how it works. It's more the support overhead that seems to come with it. A lot of people seem to have troubles integrating Tailwind into different projects, because you have to use the purge thing, the auto, what's it called? Post CSS –
[00:50:41] SW: Which is built-in to Tailwind now, so it comes by default. No config.
[00:50:45] KAK: Yeah. Some people, or at least from my point of view seem to have a problem getting this to work correctly and then they show up oftentimes in the Svelte discord to ask Tailwind-specific questions. It's like a negative feedback loop for me. Sure. Gets to my irritating –
[00:51:03] SW: I don't want to make this a Tailwind discussion. I’ll write a blog post. I have responses to all of these.
[00:51:08] KAK: Yeah, cool.
[00:51:08] MV: That'd be great.
[00:51:10] KAK: Yeah. All right, so my pick. It's Svelte Summit. It's just a couple of weeks to Svelte Summit, I think three weeks or so? Yeah, it's really exciting. We have some super interesting talks coming up. Three of them announced so far and when this airs, a couple of more, yours among them, Mark.
So far, we have Elderjs and Penguin’s REPL talk. Then also, the one that I’m super excited about, the Cloudflare worker talk by Luke seems super interesting. Yeah. That's it.All right. Thanks for coming on, Mark.
[00:51:47] MV: Yeah, thank you so much for having me.
[00:51:49] SW: Hang on. I got to do one of these. The audience has been very kind, very quiet throughout the whole recording, so they came in. [Inaudible 00:52:04].
[00:52:06] AJ: It's become to sound very strange that now, because actually showed on my screen, you're frozen completely and you have been for a while. It sounded almost like water pouring off a roof. It was very odd.
[00:52:17] SW: I think I picked the wrong sound. This one's better. This one’s look more clapping.
[00:52:22] AJ: Yeah.
[00:52:22] SW: More true.
[00:52:24] AJ: It’s more recognizable.
[00:52:27] KAK: On that note, that's it for this week. We'll talk to you in a couple of weeks again. Take care, guys.
[00:52:33] SW: Bye.
[00:52:33] AJ: Thank you.

Episode source