Slender Creator: Web Development Should Be More Fun

Svelte and its full-stack framework, SvelteKit, have caused a stir 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 the chance to speak with Rich Harris, creator of Svelte, about front-end JavaScript trends and the way forward for Svelte. We also discussed multi-page applications vs. single page apps, apps vs. documents, its concept of a “bridging app” and running an open source software project, among others. .

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

Rich Harris: I do live in NYC, Brooklyn. However, I actually handed over my review to the New York Times and now I am struggling to secure all my responsibilities before I leave. I start a Vercel on November 8.

Tyson: Ah, Vercel is in good synergy with SvelteKit. (Vercel is a front-end delivery platform.) I remind you 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 on Next.js (Next.js is maintained by Vercel), and because Guillermo had noticed that users de Vercel were often not sure what the “blessed” way to create a Svelte application was.

Tyson: It’s interesting to me that Svelte has managed to get around the status quo, which is to pass at compile time. How do you and the team cultivate a new outlook on things?

Harris: In two ways. We maintain a healthy level of skepticism towards front-end trends in general. People outside of the JS world tend to look at those of us inside as if we are all a little bit stupid, and our position is that they are very often right to do so.

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

Tyson: The ergonomics of using Svelte is what first attracted me as a developer. Do you make it a point of honor to cultivate the experience of developers?

Harris: We do. “Developer experience” is almost a dirty word in some circles as it is assumed to conflict with the end user experience, which takes priority, but that is not necessarily true, especially when you have the broader solution space offered by a compiler-centric mindset. Svelte is largely an experiment to maximize UX without hurting DX and vice versa.

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

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

Harris: There is a lot of tribal thinking about the “right” way to build apps, and recently this has manifested itself as a rift between the traditionalist and modernist camps, which advocate building AMP and SPA, respectively. At least that’s the caricature.

The reality is that most frameworks converge on 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. ‘be because this nuance tends to be drowned out by absolutist rhetoric.

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

SvelteKit is our attempt to create a transitional application framework. It is designed to be the best possible way to create 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 that you identify is that of applications versus documents. Would you describe how you and SvelteKit envision this division in a more productive way?

Harris: I’m pulling my hair out a bit from the people who treat documents and applications as totally separate things, with totally different technological requirements. The great thing about 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 lets you think of previously unthinkable thoughts, and the web is the most accessible manifestation of this idea ever. And yet, we’re still largely stuck treating web pages as a canvas for text and images.

Documents and applications are just poles on a spectrum. It happens very often that only one site has characteristics of this whole spectrum, so it is important that the tools we use reflect this.

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

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

Tyson: Let me ask you a question about Wasm. What impact do you think this 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 won’t make you a faster div wrangler. This certainly opens up new possibilities. It’s amazing that we can now run FFmpeg in the browser, for example. But I don’t expect most of us to interact with it on a regular basis.

I am venturing outside my area of ​​expertise by saying this. (These comments will probably seem hopelessly naive in two years!) But the majority of non-JS languages ​​are arguably inappropriate for the front-end because Wasm binaries tend to be a bit big, unless you’re using something low level without huge stdlib. In some areas (games, video editing, etc.) this is an interesting compromise, but not in web development in general.

Tyson: Can you tell us a bit about SvelteKit’s support for multiple release 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 is no point in being tied to a specific platform or technology, like Node or Lambda servers, these days. As a result, we were able to design the framework in such a way that people could add their own support for new environments with very little effort. There are still definitely a few details that we need to figure out, but overall it has been a great success, and I can’t imagine 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 are no quick fixes, and what works for one project or one maintainer may not work for others. But in my experience, community is very essential. Surround yourself with as many high quality contributors as you can find and make it easy for people to get involved in the thing you are 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 I even write code. That way, you’ll understand why your API design sucks before you invest in it. Too many developers are obsessed with the details of the implementation while neglecting the API design, which is completely upside down. Implementation details are temporary, but APIs are incredibly difficult to change.

Tyson: Good thoughts – thank you, Rich. Good luck to you in your new position at Vercel!

Harris: Thank you!

Copyright © 2021 IDG Communications, Inc.

James S. Joseph