Slender Creator: Web Development Should Be More Fun


Svelte and its full-stack framework, SvelteKit, have caused a stir and won plaudits, including a recent Best of Open Source Software Award, for thinking outside the box in their approach to JavaScript development.

I recently had the opportunity to speak with Rich Harris, creator of Svelte, about front-end JavaScript trends and the way forward for Svelte. We also discussed multi-page apps vs. single-page apps, apps vs. documents, his concept of a “transition app,” and running an open source software project, among other things. .

Matthew Tyson: Thank you very much for taking the time to speak. You work at the New York Times. Do you live in New York?

Rich Harris: I actually live in NYC, in Brooklyn. However, I actually tendered my resignation to The New York Times and now I’m scrambling to tie up all my responsibilities before I leave. I start a Vercel on November 8.

Tyson: Ah, Vercel is a good synergy with SvelteKit. (Vercel is a front-end delivery platform.) I remind you that Vercel recently added support for SvelteKit.

Harris: SvelteKit was partly inspired by Guillermo (Guillermo Rauch, CEO of Vercel), both in the sense that it is modeled after Next.js (Next.js is maintained by Vercel), and because Guillermo noticed that users de Vercel were often not sure what was the “blessed” way to create a Svelte app.

Tyson: It’s interesting to me that Svelte was able to circumvent the status quo, i.e. pass at compile time. How do you and the team cultivate new ways of seeing things?

Harris: In two ways. We maintain a healthy level of skepticism towards frontal tendencies in general. People outside of the JS world tend to look at those of us inside like we’re all a bit dumb, and our position is that they’re very often right to do so.

We approach the task of designing the frame as an essentially playful task. We do it because it’s fun and because we want web development to be more fun. This gives us the space to nurture quite distant ideas, which after a long process of shedding and refinement often turn into signature features.

Tyson: Svelte’s user-friendliness is what initially attracted me as a developer. Do you make a point of cultivating the developer experience?

Harris: We do. “Developer experience” is almost a dirty word in some circles because it’s supposed to conflict with the end-user experience, which takes precedence, but that’s not necessarily true, especially when you have of the larger solution space offered by a compiler-centric mentality. . Svelte is largely an experience about maximizing UX without hurting DX and vice versa.

It wasn’t always true. Prior to version 3, DX was a bit of an afterthought. But it turns out you can have the best UX in the world and it won’t matter unless the DX is good enough that people actually want to use it. People tolerated Svelte 2, but they love Svelte 3, and that’s when we started making waves.

Tyson: In your recent talk at Jamstack Conf 2021, you describe the apparent conflict between multi-page applications (MPAs) and single-page applications (SPAs) and how that’s not a very nuanced way to look at it. You propose the idea of ​​the “transition application” as a resolution. Could you briefly talk about what you mean by a transition app and how SvelteKit fits into that picture?

Harris: There is a lot of tribal thinking about the “right” way to build apps, and recently this has manifested itself in a divide between the traditionalist and modernist camps, who advocate building AMPs and SPAs respectively. At least that’s the cartoon.

The reality is that most frameworks are converging to a much more nuanced set of standards around things like where your rendering logic should live, but the discussion around this stuff isn’t as productive as it could be because that this nuance tends to be drowned out by absolutist rhetoric.

I have observed that one way to redirect discussions such as these is to introduce new language, rather than trying to add caveats and clarifications to existing terminology, as this allows participants to get rid of the baggage already attached to terms like “SPA”. So I invented “transition apps” to describe the standards I mentioned. The name “transitional” is taken from the school of interior design that combines traditionalist and modernist sensibilities.

SvelteKit is our attempt to create a transitional application framework. It’s designed to be the best way to create a Svelte app for the vast majority of people. But the term also covers frameworks like Next and Nuxt.

Tyson: Another apparent area of ​​conflict you identify is applications versus documents. Would you describe how you and SvelteKit view this division more productively?

Harris: I tear my hair out a bit at people who treat documents and applications as totally separate things, with totally different technology requirements. The whole point of interactive media is that documents can look like applications!

The Web has the potential to be this radically new tool for cognition and communication. Interactive media allows you to think previously unthinkable thoughts, and the web is the most accessible manifestation of this idea ever developed. And yet, we’re still largely stuck treating web pages as a canvas for text and images.

Documents and apps are just poles on a spectrum. Quite often a single site will exhibit characteristics from across this spectrum, so it is important that the tools we use reflect this.

The platonic ideal of a web authoring framework would allow you to create sites without even really having to think about what “type” of site you are creating. An example of how this works in practice is to limit the JavaScript that end users download to what they need for the “appy” parts.

SvelteKit lets you disable client-side JavaScript at the page level, and some frameworks are even more granular than that. The idea that you should choose a “docs” framework or an “app” framework, to the exclusion of the other, seems terribly myopic to me.

Tyson: Let me ask you about Wasm. What impact do you think it will have on front-end development as a whole, and more specifically, what will it be for non-JS languages ​​like Java or C used on the front-end?

Harris: I think people tend to overestimate the impact of Wasm on front-end development. Wasm will not make you a faster div wrestler. This definitely opens up new possibilities. It’s amazing that we can now run FFmpeg in the browser, for example. But I don’t foresee most of us interacting with him on a regular basis.

I venture outside my area of ​​expertise in saying this. (These comments will probably sound hopelessly naive two years from now!) But the majority of non-JS languages ​​are probably unsuitable for the front-end because Wasm binaries tend to be a bit large unless you’re using something low level without a huge stdlib. In some areas (gaming, video editing, etc.) it’s an attractive compromise, but not in web development in general.

Tyson: Can you talk a bit about SvelteKit’s support for multiple output environments?

Harris: We realized early on that it was essential to support multiple environments, in a way that takes full advantage of their unique capabilities. There’s no point in being tied to a specific platform or technology, like Node or Lambda servers, these days. Thanks to this, we were able to design the framework in such a way that people could add their own support new environments with very little effort. There are definitely still a few loose ends to iron out, but overall it’s been a great success, and I can’t imagine the frameworks working any other way in the future.

Tyson: Do you have any advice for people interested in building successful open source projects?

Harris: There is no silver bullet, and what works for one project or maintainer may not work for others. But in my experience, community is absolutely essential. Surround yourself with as many high-quality contributors as you can find, and make it easy for people to get invested in what you’re building. I’ve found interactive playgrounds to be extremely helpful in this regard, as they allow people to try things out without friction and can dramatically increase the frequency and quality of bug reports.

Finally, invest in documentation. It sounds obvious, but it’s often an afterthought, and good documentation will pay huge dividends. In fact, I’m a big believer in Readme Driven Development, which means writing documentation before you even write code. That way, you’ll understand why your API design sucks before you invest in it. Too many developers obsess over implementation details while neglecting API design, which is completely backwards. Implementation details are temporary, but APIs are incredibly difficult to change.

Tyson: Great thoughts—thanks, Rich. Good luck to you in your new position at Vercel!

Harris: Thank you!

Copyright © 2021 IDG Communications, Inc.


Comments are closed.