Svelte creator: Web development should be more fun
Svelte and its full-stack framework, SvelteKit, have made a splash and won applause, including a recent Best of Open Source Software Award, by thinking outside the box in their approach to JavaScript development.
I recently had a chance to talk with Rich Harris, creator of Svelte, about front-end JavaScript trends and the road ahead for Svelte. We also discussed multi-page apps vs. single-page apps, apps vs. docs, his concept of the “transitional app,” and running an open source software project, among other things.
Matthew Tyson: Thanks so much for taking the time to talk. You work at the New York Times. Do you live in NYC?
Rich Harris: I do indeed live in NYC, in Brooklyn. However, I actually handed in my notice at the New York Times and now I’m scrambling to tie up all my responsibilities before I leave. I am starting a Vercel on November 8.
Tyson: Ah, Vercel is good synergy with SvelteKit. (Vercel is a front-end delivery platform.) I recall that Vercel recently added SvelteKit support.
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 had remarked that Vercel users often weren’t sure what the “blessed” way to build a Svelte app was.
Tyson: It’s interesting to me that Svelte has successfully managed to kind of buck the status quo, that is, going compile-time. How do you and the team cultivate looking at things in new ways?
Harris: In two ways. We maintain a healthy level of skepticism towards front-end trends generally. People outside the JS world tend to look at those of us inside it as if we’re all a bit daft, and our position is that they’re very often right to do so.
We approach the task of designing the framework as an essentially playful one. We do it because it’s fun, and because we want web development to be more fun. That gives us the space to entertain some fairly far-out ideas, which after a long process of bikeshedding and refinement often turn into signature features.
Tyson: The ergonomics of using Svelte are what initially drew me to it as a developer. Do you make a point of cultivating developer experience?
Harris: We do. “Developer experience” is almost a dirty word in certain circles because it’s assumed to be in conflict with end-user experience, which takes priority, but that’s not necessarily true, especially when you have the larger solution space afforded by a compiler-centric mentality. Svelte is largely an experiment in maximizing UX without harming DX and vice versa.
That wasn’t always true. Prior to version 3, DX was a bit of an afterthought. But it turns out that you can have the best UX in the world and it won’t matter at all unless the DX is good enough that people actually want to use the thing. People tolerated Svelte 2, but they love Svelte 3, and that release was when we started making waves.
Harris: There’s a lot of tribal thinking about the “right” way to build apps, and recently that’s manifested as a divide between the traditionalist and modernist camps, who advocate for building MPAs and SPAs, respectively. At least that’s the caricature.
The reality is that most frameworks are converging on a much more nuanced set of norms 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 nuance tends to get drowned out by absolutist rhetoric.
I’ve observed that one way to reorient discussions like these is by introducing new language, rather than trying to add caveats and clarifications to existing terminology, because it lets participants get rid of the baggage that’s already attached to terms like “SPA.” So I coined “transitional apps” to describe those norms I mentioned. The name “transitional” is lifted from the interior design school that combines traditionalist and modernist sensibilities.
SvelteKit is our attempt to build a transitional app framework. It’s designed to be the best possible way to build a Svelte app for the vast majority of people. But the term also covers frameworks like Next and Nuxt.
Tyson: Another area of apparent conflict you identify is apps versus docs. Would you describe how you and SvelteKit look at that division in a more productive way?
Harris: I tear my hair out a bit at the people who treat documents and apps as being totally separate things, with totally different technology requirements. The whole point of interactive media is that documents can be app-like!
The web has the potential to be this radically new tool for cognition and communication. Interactive media let you think previously unthinkable thoughts, and the web is the most accessible manifestation of that idea ever developed. And yet we’re largely still stuck treating web pages as a canvas for text and images.
Documents and apps are merely poles on a spectrum. It’s very often the case that a single site will exhibit characteristics from across that spectrum, so it’s important that the tools we use reflect that.
The platonic ideal of a web authoring framework would allow you to build sites without even really needing to think about what “kind” of site you’re building. One example of how that works in practice is limiting the JavaScript that end users download to just the stuff 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 pick a “docs” framework or an ”app” framework, to the exclusion of the other, just seems terribly shortsighted to me.
Tyson: Let me ask you about Wasm. How big an impact do you foresee it having on front-end development as a whole, and specifically, how big will it be for non-JS languages like Java or C being used on the front end?
Harris: I think people tend to overestimate the impact of Wasm on front-end development. Wasm won’t make you a faster div wrangler. It definitely opens up new possibilities. It’s incredible that we can now run FFmpeg in the browser, for example. But I don’t anticipate that most of us will interact with it on a regular basis.
I’m venturing outside my field of expertise by saying this. (These comments will probably seem hopelessly naive two years from now!) But the majority of non-JS languages are arguably unsuitable for the front end because Wasm binaries tend to be a bit chunky, unless you’re using something low-level without a huge stdlib. In some fields—gaming, video editing, etc.—that’s a worthwhile trade-off, but not in web development more generally.
Tyson: Can you talk a little about SvelteKit’s support of multiple output environments?
Harris: We realized early on that supporting multiple environments—in a way that takes full advantage of their unique capabilities—was essential. It’s no good being tied to a specific platform or technology, like Node servers or Lambda, in this day and age. Because of that we’ve been able to design the framework in such a way that people have been able to add their own support for new environments with very little effort. There are still definitely some details we need to figure out, but on the whole it’s been a great success, and I can’t imagine frameworks working any other way in the future.
Tyson: Do you have any advice for folks interested in creating successful open source projects?
Harris: There are no silver bullets, and what works for one project or maintainer might not work for others. But in my experience, community is completely essential. Surround yourself with as many high-quality contributors as you can find, and make it easy for people to become invested in the thing you’re building. I’ve found that interactive playgrounds are extremely helpful in this regard, as they enable people to try things out with no 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 great believer in Readme Driven Development, which means writing documentation even before you write any code. This way, you’ll realize why your API design sucks before you get invested in it. Too many developers obsess over implementation details while neglecting API design, which is utterly backwards. Implementation details are temporary, but APIs are incredibly hard to change.
Tyson: Great thoughts—thanks, Rich. Very best of luck to you at your new post at Vercel!
Harris: Thanks!
Copyright © 2021 IDG Communications, Inc.