When I’ve spoken in the past about evaluating technology, I’ve mentioned two categories of tools for web development. I still don’t know quite what to call these categories. Internal and external? Developer-facing and user-facing?

The first category covers things like build tools, version control, transpilers, pre-processers, and linters. These are tools that live on your machine—or on the server—taking what you’ve written and transforming it into the raw materials of the web: HTML, CSS, and JavaScript.

The second category of tools are those that are made of the raw materials of the web: CSS frameworks and JavaScript libraries.

I think the criteria for evaluating these different kinds of tools should be very different.

For the first category, developer-facing tools, use whatever you want. Use whatever makes sense to you and your team. Use whatever’s effective for you.

But for the second category, user-facing tools, that attitude is harmful. If you make users download a CSS or JavaScript framework in order to benefit your workflow, then you’re making users pay a tax for your developer convenience. Instead, I firmly believe that user-facing tools should provide some direct benefit to end users.

When I’ve asked developers in the past why they’ve chosen to use a particular JavaScript framework, they’ve been able to give me plenty of good answers. But all of those answers involved the benefit to their developer workflow—efficiency, consistency, and so on. That would be absolutely fine if we were talking about the first category of tools, developer-facing tools. But those answers don’t hold up for the second category of tools, user-facing tools.

If a user-facing tool is only providing a developer benefit, is there any way to turn it into a developer-facing tool?

That’s very much the philosophy of Svelte. You can compare Svelte to other JavaScript frameworks like React and Vue but you’d be missing the most important aspect of Svelte: it is, by design, in that first category of tools—developer-facing tools:

Svelte takes a different approach from other frontend frameworks by doing as much as it can at the build step—when the code is initially compiled—rather than running client-side. In fact, if you want to get technical, Svelte isn’t really a JavaScript framework at all, as much as it is a compiler.

You install it on your machine, you write your code in Svelte, but what it spits out at the other end is HTML, CSS, and JavaScript. Unlike Vue or React, you don’t ship the library to end users.

In my opinion, this is an excellent design decision.

I know there are ways of getting React to behave more like a category one tool, but it is most definitely not the default behaviour. And default behaviour really, really matters. For React, the default behaviour is to assume all the code you write—and the tool you use to write it—will be sent over the wire to end users. For Svelte, the default behaviour is the exact opposite.

I’m sure you can find a way to get Svelte to send too much JavaScript to end users, but you’d be fighting against the grain of the tool. With React, you have to fight against the grain of the tool in order to not send too much JavaScript to end users.

But much as I love Svelte’s approach, I think it’s got its work cut out for it. It faces a formidable foe: inertia.

If you’re starting a greenfield project and you’re choosing a JavaScript framework, then Svelte is very appealing indeed. But how often do you get to start a greenfield project?

React has become so ubiquitous in the front-end development community that it’s often an unquestioned default choice for every project. It feels like enterprise software at this point. No one ever got fired for choosing React. Whether it’s appropriate or not becomes almost irrelevant. In much the same way that everyone is on Facebook because everyone is on Facebook, everyone uses React because everyone uses React.

That’s one of its biggest selling points to managers. If you’ve settled on React as your framework of choice, then hiring gets a lot easier: “If you want to work here, you need to know React.”

The same logic applies from the other side. If you’re starting out in web development, and you see that so many companies have settled on using React as their framework of choice, then it’s an absolute no-brainer: “if I want to work anywhere, I need to know React.”

This then creates a positive feedback loop. Everyone knows React because everyone is hiring React developers because everyone knows React because everyone is hiring React developers because…

At no point is there time to stop and consider if there’s a tool—like Svelte, for example—that would be less harmful for end users.

This is where I think Astro might have the edge over Svelte.

Astro has the same philosophy as Svelte. It’s a developer-facing tool by default. Have a listen to Drew’s interview with Matthew Phillips:

Astro does not add any JavaScript by default. You can add your own script tags obviously and you can do anything you can do in HTML, but by default, unlike a lot of the other component-based frameworks, we don’t actually add any JavaScript for you unless you specifically tell us to. And I think that’s one thing that we really got right early.

But crucially, unlike Svelte, Astro allows you to use the same syntax as the incumbent, React. So if you’ve learned React—because that’s what you needed to learn to get a job—you don’t have to learn a new syntax in order to use Astro.

I know you probably can’t take an existing React site and convert it to Astro with the flip of a switch, but at least there’s a clear upgrade path.

Astro reminds me of Sass. Specifically, it reminds me of the .scss syntax. You could take any CSS file, rename its file extension from .css to .scss and it was automatically a valid Sass file. You could start using Sass features incrementally. You didn’t have to rewrite all your style sheets.

Sass also has a .sass syntax. If you take a CSS file and rename it with a .sass file extension, it is not going to work. You need to rewrite all your CSS to use the .sass syntax. Some people used the .sass syntax but the overwhelming majority of people used .scss

I remember talking with Hampton about this and he confirmed the proportions. It was also the reason why one of his creations, Sass, was so popular, but another of his creations, Haml, was not, comparitively speaking—Sass is a superset of CSS but Haml is not a superset of HTML; it’s a completely different syntax.

I’m not saying that Svelte is like Haml and Astro is like Sass. But I do think that Astro has inertia on its side.

Have you published a response to this? :


“Adactio: Journal—Inertia”

Been thinking a lot about evaluating tech because I have a new project starting and Jeremy touches on a lot of the same thoughts I had (tho, obv. a diff conclusion as I can choose what I want 😎)

# Tuesday, November 9th, 2021 at 10:37am

Baldur Bjarnason

“Adactio: Journal—Inertia” Been thinking a lot about evaluating tech because I have a new project starting and Jeremy touches on a lot of the same thoughts I had (tho, obv. a diff conclusion as I can choose what I want 😎)

Aaron T. Grogg

A recent installment of a newsletter that I subscribe to started off talking about how the author still loved Sublime Text, but felt like an outsider for having not switched to VS Code, as it seems the rest of the developer world has. S/he suggests a video that “might be just what you need to consider a switch”. I have VS Code, have tried switching multiple times, once for more than a week, but just find myself coming back to Sublime Text… And I watched that video weeks ago. I agree that VS Code is awesome, but maybe it is too much? I know having it open for more than 2-3 minutes makes my MacBook sound a 767 warming up for a flight to Rio… But, maybe some day…

Speaking of “converting”, I have yet to buy into any one particular app framework… Angular, React, Vue, they all individually came into their own while I was sort of… ignoring… modern web development for a li’l bit… And I have seen nothing to make me buy into any specific one, so I have just been sitting in limbo. Until yesterday. Yesterday I had the pleasure of watching a video with Rich Harris talking about Svelte, and I have to say, I am sold. What I have always hated about such frameworks is their “everything relies on JS” nature and how heavy the initial page load is. Svelte turns both of those on their heads, delivering fully built HTML pages with only the CSS/JS that page needs. Additionally, and even more importantly, Svelte changes how it “reacts” to changes within the app: rather than bubbling through the entire DOM Object to affect state changes, Svelte maintains state much closer, allowing for much more performant UI updates! Yes, it requires a build process, but to me, that is a worthwhile trade-off! Now I just need to learn it…

While collecting notes for this post, I stumbled upon a Jeremy Keith article that talks about the benefits Svelte from a completely different angle, and I couldn’t agree more! But now he’s got me thinking I really want to look into Astro… :-/

And speaking of Jeremy Keith, the good folks at Clearleft worked with some of the good folks at Google to put together this course on Responsive Design. Recommend it to anyone that might need it, or have a look yourself, never know when you find a new trick or are reminded of something you forgot!

Okay, but back to performance for a sec, how many times, while initially coding or refactoring something, have you wondered which way of implementing something is more performant? I do it all the time, and find myself hacking quick time tests in my DevTools. Well, no more, as Hasty allows you define any variables your tests might need, then paste multiple code options, and click Run to see how many iterations per second each code option can complete. Note, the higher the number, the better… ;-)

Staying with performance for another sec, here are several methods for improving performance of third-party embeds. I have used the “facade” method for Google Maps before. Not only does it speed the page load, but it also saves a fair bit of cash on dynamic API calls with every page load!

Scroll-Linked Animations With the Web Animations API (WAAPI) and ScrollTimeline. I think that about covers it! Some cool UI stuff once this comes of age!

I don’t think I have ever done this before, but… this Smashing Magazine Newsletter is just chock-full of fantastic articles! A few highlights are:

Seriously? I should have just said “Never mind, just click that link and read everything…”

And finally, pretty blown away with StackBlitz… VS Code in your browser, hot reloading, sync across multiple devices, share via live URLs (including the hot syncing refresh), GitHub integration, interact with individual live users… Blown away. Bravo.

Happy reading, Atg


Previously on this day

9 years ago I wrote Iconic imagery

Responsive images, compressive images, and icon fonts. Take your pick.

14 years ago I wrote Berlin, day 3

My speaking duties are fulfilled.