I've been taking Svelte for a joyride lately after a few years of using React exclusively. There are a couple reasons I'm trying it out, but mostly I think it's healthy to break out of your usual thought patterns. It's true that React is "just JavaScript" to some extent, but there's definitely a React Way of Doing Things® - I want to get feel for the other options out there and the tradeoffs.
I say joyride because so far it really is a joy to use, a breath of fresh air coming from React. Sifting through CSS options to find the right one? How about just write CSS and have it scoped to the component by default. Accessibility is a first-class citizen. It's a little more batteries-included than React (i.e. some extra features are part of the core library), but it keeps itself lightweight by removing the extras during compilation. Built-in transitions/animations are a fun touch.
It's a joyride, but I'm still trying to see how it would fare on a cross-country road trip (AKA large-scale project)... I'm not sure I'd trust it in the middle of Nevada when it's sagebrush to the horizon and I'm still hours from Las Vegas.
Fundamentally different
The real revelation with Svelte isn't the developer experience. The big frameworks/libraries these days (React, Angular, Vue) are all based around the idea that you write your code to interact with the framework and then send the framework to the browser along with your code. They each detect the changes you make and then update the DOM as a separate step. In contrast, what you write in Svelte compiles to vanilla JS/HTML/CSS and interacts with the DOM directly.
It might seem like tomato tomato (not a super great expression when you can't say it out loud), but I can't shake this feeling that this is fundamentally different, with the potential to affect the future of web development. Even if Svelte doesn't become the next React, I wouldn't be surprised if the big frameworks took cues from Svelte in future releases.
During this learning process I've been exposed to some new ideas (my favorite
side effect!) - here's my favorite example: The
Svelte and the Great Space Elevator
talk from Sean Wang AKA swyx.
Svelte's creator Rich Harris doesn't mince words: not only does he see Svelte as a tool to write apps with less code and better performance, he extrapolates this out into the idea that the web wasn't designed for apps at the scale we're building, and that we might be on the verge of a new web... or rather two webs: one for documents and one for apps.
I started with an article by Sean Wang, and ended up down a rabbit hole where I realized this is something people are putting a lot of thought into. I won't be able to put it as well as Tom MacWright in this article, so go read that link for a high-level view.
It's complicated
The complication that comes with building modern web apps is bananas. I'm not talking about the complexity that comes with large apps, this is complication that arises from trying to orchestrate clients and servers in a way that almost seems to fight against the web itself.
You start out with HTML, CSS, and JavaScript. If you're building something
beyond a toy app, you'll very quickly reach for a framework like React. Of
course your app should be progressive for slower connections or JS-disabled
browsers... you could use HTML templates, but that means keeping two codebases
in sync, so you add server-side rendering (SSR) to ship a static HTML version of
your React app. You have a single codebase, but now you're managing code that
needs to work on both the client and server, and gets stitched together
("hydrated") client-side. I hope you like if (typeof window !== 'undefined')
checks, because they're sprinkled around like glitter (and we all know how much
fun it is to clean up glitter). Forget about global state now that we're on the
server, although I'm sure you weren't using global state in the first place...
were you? Are you sure?
Tom MacWright has a hot take on this too.
I think I can pinpoint the moment I thought "this is getting out of control..." it was when I heard Dan Abramov in this talk from JSConf Iceland in 2018 mention "time slicing" as a way to manage slow performance. Slow performance that seems like it was introduced by React in the first place. "Time slicing" sounds like like a Ridley Scott dystopian future I'd like to avoid.
It sounds like trying to solve complexity by adding complexity. What would it take to simlplify?
Think locally, act globally (when it comes to maxima)
Here's the larger point: Standing where we stand, how do we solve the problems we're facing? Is there a clear path to keep improving from here, or will it be hard to get even marginal improvements? Should we persevere, or are we perseverating? Would our efforts be better spent starting from an earlier point?
This is not just a question about software, this applies to much of our lives. We're standing on a hill and we can only see so far. Sometimes it feels like we're near the top, the pinnacle of achievement... but the local maximum always feels like the pinnacle. Maybe you can't see the big picture enough to realize there are higher places to climb. Maybe you have to climb down a bit to get there.
It might feel like taking steps back or even starting over is a waste. This is hardly ever true, because we're almost never truly starting over. We might be moving backwards, but we're doing it intentionally, drawing from our current experience. We've felt the joy of the pros and the pain of the cons, and we can use that firsthand knowledge as a compass. What can't we see from here? How much higher can we go?
