Svelte and Sapper So Far

NOTE: I started this blog post as a stub ages ago, but then I had to go down a rabbit hole of making my own Continuous Integration system just for kicks. Now that this is over, you are reading the first blog post deployed with my fresh new sort of working CI code. Enjoy!

I have been more or less out of full time web development for close to 10 years. I tried to come up with a serious project in the last 10 years and it's mostly just been my creaky old junk Django website I wrote in 3 months to sell my books. That's an incredibly long time to be away from technology, and I needed to completely retool my development to match modern practices.

This doesn't mean I completely lost all of my skills. I kept up with most of the recent developments in the web world, and nothing actually changed. From about 2000-2016 I'd say web development stayed fairly static and the tools didn't change much. You'd see an explosion of web frameworks that were simply copying the old Model-View-Controller design, still tied to a mountain of files running on an HTTP server, and still full of tedious development processes.

I think at about maybe 2016 things in web development started improving, but I was too busy with other things to invest the time in learning them. In about 2018 I finally sat down to relearn all of the modern web technologies and managed to come to several realizations regarding JavaScript (more on that in another post), but most importantly, I found that I love making front end applications in modern JavaScript.

In this post I'm going to talk about exactly what the Svelte and Sapper are doing for me and why I feel they're the real future of web development.

The Tyranny of HTTP

Before I get into Svelte I have to very quickly explain where modern web browser development is going by explaining why it was so terrible in the past. I like to call the period of web development before about 2016 the "HTTP Tyranny Era" (HTE) where every single time you wanted something to show up in a web browser you had to pass it through a web server. It didn't matter if all you did was load a file, or some JS, or an image. If it didn't pass through a magic HTTP protocol server then the browser considered it unsafe and even you as a web developer were not allowed to work with it.

When you ask web developers exactly why a set of HTML, CSS, and JS files must go through a web server--even on your local machine--they'll usually claim for security. Yet, they can't exactly explain why--if a file filtered through an HTTP server is so secure--the browser can't just load the files and run them through a little internal HTTP server? Why does it have to pass through a network over to another process to be magically blessed?

There really isn't a reason, other than that's how everyone thinks it should be, and that's why I call it Tyrannical. In the early days of Greek Tyranny everyone just accepted that's how it should be, and when you asked them, but, why should one person have a say in all of this, they'd shrug and go "... for security?". An authoritarian controlling everything doesn't make everyone secure, and neither does passing everything through HTTP. It's just done that way and there's really no reason.

Why does this matter? Because, when you make a website usually you don't want to worry about some grand HTTP server Model-View-Controller giant stack of processes and files that exist only to bless your index.html. You want to just take a design you've made or a vision in your head and make that page appear in a browser. The old web insisted that to create an interactive moving real web page you must pass it through a web server, and that meant a ton of knowledge and processes to get started.

But, all I need is a directory of some files and a way to tell the browser "Look, when I click links just, like, pretend I'm using HTTP. OK?"

The Promise of The Modern Web Application

I see the invention and direction of the Single Page Application (SPA) as a way for someone to completely develop their front end with almost zero HTTP. In many ways frameworks like React, Vue, and Svelte use the HTTP server as just enough file serving to make the browser happy and off you go. The appeal of this is you can start an application with Svelte in a few minutes and get a development environment that feels like a full web server, but have everything totally faked out.

To me the idea that I can protype an entire web UI and how it interacts with a real web framework without every installing single backend component is the real reason I like the modern web. The speed increases from a SPA do manifest but only if you work to control the size of the application. If you're still cramming 2GB of content into a single page application then you won't see any improvement in visible performance.

Another way to put this is I believe everyone who talks up an SPA is talking about the wrong benefits. Browsers are so terrible at rendering content smoothly that we can't realistically say an SPA is going to magically help.

What we can start to say is that starting your web application as an SPA is easier and speeds development because you can completely fake out the entire backend and work with just the browser. No Rails, Django, Elixir, or anything adding friction to your ideas. By removing the friction between idea and start the SPA helps you get your idea off the ground and make sure the user interface works well enough to continue.

First Attempt, An Art Website

My initial hacking on this and other sites was all done with plain old Svelte and mostly fake, but at some point I have to eventually get down to where I really do something on a server to store things in a database. We haven't progressed to the era where something like GUN is simply available in every browser, and then I can store data, and I have the ServiceWork...wait actually...nah that's crazy.

Anyway, my first Svelte project was a learning project for my art website at zedshaw.art. In that case I prototyped most everything in Svelte, go it working and looking how I wanted, then I created an Express API to handle all the requests for JSON. This works surprisingly well and I had the whole thing up in few weeks then spent more time wrangling with WebTorrent to figure that out for video serving.

This is a very reasonable development process, and one I'm dubbing "GUI First Development" since nobody else decided to call this totally reasonable and natural way to create a website anything. How does GFD work:

1. Design your UI on paper or in your head. I like paper.
2. Fire up a Svelte app (or React or Vue.js if you like).
3. Start building the UI, and in every place you need some kind of data, fake it out. You could use Faker to do a lot of that.
4. Work on getting the design, UI, interactions, and everything working, including all the fake backend data. In fact, you can put a lot of that into a simple api.js and just load it to work with until you're ready to make that a real API.
5. Once you've got the site mostly working, you take your api.js and start converting it into a JSON web server using anything you like. Doesn't even need to be JavaScript.

If you were really fancy you might use something like Swagger to help build out your API and make it easy to work with, but you don't have to do that at first. Just work the Svelte files until it's nice looking and working so well that nobody realizes it's fake.

Then Came The Googlebot

This revolutionary process (cough, cough) of doing the GUI first and making it as real as possible hits one gigantic snag in an SPA:

Googlebot Hates JavaScript

At least, it used to? Or, still does if they hate you? Actually, it's not clear because you read some things they say online and they claim they render every page the Googlebot crawls, but then some people say that switching to an SPA killed their traffic.

Either way, nobody trusts google to render all your JavaScript and then pretend to click around. Remember that we still operate of the system of oppression that is HTTP, and Googlebot LOOOVVVVVEESS plain old flat HTML. I have a secret conspiracy theory that it's Google paying all those web developers to hate on SPAs so that we'll stop using them and save them money.

Anyway, it doesn't matter because JavaScript web framework folks have been solving this for a while by doing something called "progressive enhancement" where you give the browser the exact content it asked for, but also serve up the SPA code so you get the nice navigation and front end interactivity of a dynamically rendered JavaScript application.

NOTE: There's some talk about accessibility regarding SPAs but I make a point to code blind once a month and the screen reader I use seems to not care how a web page was rendered. It's just reading text in the window. So if anyone has a real demonstration of an SPA causing a blind screen reader problems please update me so I can test it again.

This isn't a big problem for my zedshaw.art website since that's just a quick hack to try out some technology, and it's mostly art and media so google can't crawl it anyway. For this website it is a big deal because it will be mostly text that I want to be indexed, and that means I have to do this whole "progressive enhancement" thing.

Enter Sapper

Right when I was about to hunker down and figure out how to implement progressive enhancment the fine folks at Svelte came out with Sapper. Sapper is almost everything you need to create a web application in the GUI First style as it gives you Svelte, but also helps create a fairly seamless integration with the web server.

In many ways you don't know the web server is there , and you don't really need to care about it for a while. You just code your application assuming the GUI is first, then gradually add in simple files to implement the API in the webserver, and Sapper figures out how to bundle it all together for you. You still can get in and alter how the API works despite Sapper handling most of this for you, so if it doesn't go how you like you can just change it. But, for the most part Sapper has been a dream.

As I've mentioned before, my biggest complaint with web frameworks until now has been the Yet Another File problem. To get even just a basic HTML page working in the browser you must edit as many as 6 or 7 files. In Sapper you just edit 1 file, maybe 2 when you're ready. Everything is mostly just plain old JavaScript code, so no need to do special state management tricks to work around weird ideas of immutability. Just code it naturally and go.

Current Issues with Svelte and Sapper

I believe in being completely transparent about my experience with the technologies I use. I know many open source developers will try to pitch a particular weakness as a strength (events over threads anyone?) but I find that if people don't know about the potential problems when they follow my recommendations then I'm potentially cheating them out of hours of wasted effort later.

Svelte and Sapper are nearly perfect in what I want with a web development tool. They aren't quite a framework like Rails or Django, and the design philosophy of "disappearing" is exactly what I and many people want. Too often I find that web frameworks are trying to impress me with the author's brilliance by forcing me to see everything they made (Rails), or trying to tell me clunky junk is somehow "good for me" (Rails, Django). Svelte just isn't...there. It just works....

Except when it doesn't. My biggest top #1 all time complaint about Svelte and Sapper is their handling of errors and debugging. They could easily fix this, and so far it's only been annoying rather than a complete show stopper, but I've found this one thing to be a total time waster they definitely need to fix:

When you get a syntax error in your Svelte page it prints to the console, and refuses to run the app...but keeps the web server going so your reloads keep working. This makes you think the app is just fine, but it's not changing, so then you waste time until you realize that you probably have an error in the console. I find this irritating because they can easily use their port 10000 connection to show me the error and help me debug it, or at least shut down the web server so I know it's broken.

Instead everything in the browser keeps working, but you have to catch the error in the console to know what's going on. A lot of the error reporting goes like this, so you have to constantly have a console running and watch it all the time, and you can't do too much logging or you might miss those errors. I eventually solved it by switching to Pino and will log to a separate file or recorder while keeping the Svelte errors in the console.

However, even though I make this complaint I have to say the other places that Svelte helps me find errors is commendable. For example, it identifies unused CSS selectors, malformed HTML structures, unused variables, accurate syntax errors, and even accessibility problems. This alone makes up for the lazy error reporting for me.

Conclusion

I'm finding Svelte and Sapper to be briliantly done and solving all of my current web development needs. Other than problems with error reporting I find that it gets rid of my main complaint with previous web development systems that required me to edit a ton of files to just make a basic UI. Now with Sapper and Svelte I can get a basic website up and working in no time, and don't have to focus so much on the web framework so I can focus more on what my app should do.