While I’ve been building web applications for over two decades now, with a wide variety of languages, frameworks, and architectural approaches (“Client to Server and Back Again” is like a subtitle for my life), I still feel that I pretty much don’t know what I’m doing when it comes to web application technologies.
So take this article with a grain of salt. Web application development is a bit like keeping a house in working order. No matter how long you’ve been doing it, and how handy you are, there’s always something going wrong you have no idea how to fix.
That said, let’s talk about Svelte!
Svelte is really more like a compiler (a 4GL to use a very old term) than a framework. It compiles your application into JavaScript (even though part of that application is written in JS to begin with), and there is no runtime library that co-exists with your application in the browser when users are interacting with it.
Lots of web frameworks and libraries in the past have allowed you to write in a non-JS syntax, but compiled your application into JavaScript to run in the browser. That’s about as new an idea as the wheel at this point. Many of these tools took this approach so you wouldn’t have to learn JavaScript in the first place (looking at you GWT and Dart – why does Google hate JavaScript?) or there were programming approaches some prefer that JavaScript doesn’t itself include (looking at you TypeScript).
Svelte compiles your application into JS code that modifies the DOM directly. There is no virtual DOM, which has been a popular internal architectural approach for web frameworks in recent years. Virtual DOMs provide a layer of abstraction, which is always handy and helps the framework writers provide nice features, but sometimes at a bit of a performance cost despite claims to the contrary. There have been arguments about whether or not a virtual DOM helps or harms performance in the past (see Svelte’s take here), but I’m not going to address the performance of Svelte vs. React or Angular or Vue or Ember or NakedHercules (if it’s not a real framework, it should be) here.
I’m just going to address my first impressions in terms of the developer experience getting an application functional and running at least in Dev mode from scratch.
Immediately, Svelte reminded me of Vue.js in terms of programming. There is a custom file type (.svelte) for Svelte components, which seemed a direct analog for a .vue file. There are three blocks in a Svelte component: template, script, and style, which again corresponds directly to how Vue handles things.
<script>
export let attribute
</script>
<div class="attribute-component">
<div class="attribute-name">{attribute.name}</div>
<div class="attribute-box">{attribute.valueForDisplay}
<img src="images/{attribute.value}.png" height="60" width="60" alt="{attribute.value}"/>
</div>
<div class="attribute-max">Max: {attribute.maxValueForDisplay}</div>
</div>
<style>
.attribute-component {
margin-top: 12px;
display: flex;
flex-direction: column;
justify-content: center;
align-items: center;
}
. . .
</style>My first litmus test for new web frameworks is how quickly I can get my own component (not one from their tutorial) written and running. I alternate around between web frameworks a lot, so I’ve done this often, and Svelte did very well from this perspective – probably one of the easiest to get something custom of my own up and running that I’ve tried.
My second consideration is how clean the code (including any framework-specific HTML template syntax) looks. Svelte killed this one. Angular involves a lot of looking at the reference guides the first time you try to do anything on your own. Even with an IDE-plugin helping, there’s just a lot of non-obvious syntax. Aurelia and Vue are both better in this regard.
But with Svelte, I can pretty much just write normal JavaScript in the script part of a Svelte component. I can declare variables and constants in a normal way, and Svelte-specific special functions and syntax in the JS is kept to a minimum.
The Svelte syntax in the HTML template portion is also easy to remember, except for the conditionals and for-eaches. These were hard for me to remember the first special character of, to trigger my IDE to help me.
My third consideration is how easy it is to look something up in the documentation when I can’t figure out how to accomplish something on my own. Again, Svelte rocks this measure. Their docs are somehow organized simultaneously well for both quick reference and learning the framework from scratch.
On top of that, Svelte’s interactive tutorial is a thing of beauty. Words cannot describe how perfect that thing is. Try it here. No seriously, like, right now.
Svelte does not come with a router. A router is what you use when you find out you really don’t want your Single Page Application to be a Single Page. Which is like, almost all the time. There are some simple routers out there for it, though, and I was able to add one with minimal fuss. I expect they will build one into Svelte soon, because again, the SPA acronym should really just be replaced at this point with RPAs (Reactive (multi) Page Applications). You heard it here first.
So my first impressions are very favorable. But:
I’m happy using Svelte for my own personal projects, but at this point I probably would not recommend it for a large corporate web application. Reason being simply that it is too fluid at the point I’m writing this. There are major changes coming to Svelte and Sapper (Sapper I believe is roughly to Svelte what Nuxt is to Vue – try to make SPA apps not suck so much for SEO). If I were choosing a framework for a company right now, I think I’d wait for some of that to settle down first.
That said, it’s a very nice looking little framework, and I’m looking forward to spending more time with it!
Code Weaver 