Baldur Bjarnason

Which type of novelty-seeking web developer are you?

– Baldur Bjarnason

I’m noodling around at home and taking stock after having left a job of four years.

I’m poking around various ideas, trying to figure out which path to take going forward (open to suggestions!), whether to push on with a project idea, that sort of thing. I’m trying to figure out where I stand in my chosen field, where that field is going, and where that could take me.

Which is what you do under these circumstance. Reassessment seems to be the word of the year for a variety of reasons, both obvious and subtle.

The obvious conclusions don’t take much effort:

That last bit is a bit of a concern as ageism is already strong enough in web development for 30 to be considered old. The last thing I want is to be labelled a conservative old fogey in an industry dominated by novelty-seeking. Mostly because it really isn’t accurate. I really do enjoy some of the new developments in the field. So much so that I constantly have to fight the urge to start building projects using the latest bit of shiny.

Small ‘c’ conservatism has a role to play in the field. Not every business or project needs the latest and the greatest and many of them do need people with experience in building projects using tried and true techniques.

Nothing wrong with web dev conservatism but it just isn’t me. But I do have a deep and abiding fondness of the history of the web and web development.

This is the point in an essay, talk, or pub conversation that I always quote Alan Kay. Were I a TextExpander user I’d have this set up to quote at the drop of a hat (or ‘press of a key’, or is that too trite?). But a simple copy-paste will do:

Computing as pop culture #

Binstock: You once referred to computing as pop culture.

Kay: It is. Complete pop culture. I’m not against pop culture. Developed music, for instance, needs a pop culture. There’s a tendency to over-develop. Brahms and Dvorak needed gypsy music badly by the end of the nineteenth century. The big problem with our culture is that it’s being dominated, because the electronic media we have is so much better suited for transmitting pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that’s been worked on and developed and you [can] go to the next couple levels.

Binstock: One thing about jazz aficionados is that they take deep pleasure in knowing the history of jazz.

Kay: Yes! Classical music is like that, too. But pop culture holds a disdain for history. Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future—it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from]—and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.

(From Andrew Binstock’s interview with Alan Kay that was published on Dr. Dobb’s Website, July 10, 2012. It isn’t available on that website anymore but you can easily find a PDF copy of the version published in Springer Nature with a bit of Googling.)

Now, I’m not as down on the web as Alan Kay. Large parts of it are garbage, sure, but I think there are a few core ideas in the web that are straight-up awesome.

Nor am I as completely disdainful of pop culture as he is. The edges of pop culture have a role to play in popularising the avant-garde and breaking up stagnant forms. This doesn’t happen as much when the pop culture is as completely dominant as it is these days—the more all-encompassing and homogenous that pop culture is the less it has of the edges and boundaries that make it useful and interesting.

But Alan’s observation that computing is a pop culture is perennially true. As is the fact that the web is the epitome of that pop culture’s disdain for history and any attempt to develop it, in the cultural sense, towards something more sophisticated.

This is the culture that finds the idea of ten year old essays still being relevant so jarring that instead of just referring to collections of these essays as the field’s ‘canon’ they invent a new phrase that’s based on a misunderstanding of a casual heuristic observation: “Lindy Libraries” or “Lindy Media”. Basically, texts that are likely to last as long as they have lasted so far.

If that seems like a facile observation, you wouldn’t be wrong.

Instead of building on centuries’ worth of discourse on the problems and benefits of a field having dominant canonical texts, they just ditch all of that and start again on square one with a shallow understanding of the interplay between a field’s canon and that field’s practice.

The definition of a “Lindy something” does seem limited to the past decade or so—post 2000, at best. You rarely see people in this crowd link to decades old essays like Programming as theory building or No Silver Bullet. The Dao of Web Design might get in by a hair in terms of age but is usually disqualified by virtue of its message being unpalatable. “Work with the medium as it is without trying to transform it into something it isn’t? What nonsense!”

These are the types of people you hear described when somebody on the edges of the field is asked “what do you mean when you talk about ‘novelty-seeking web developers?” Even without ever having read any of Alan Kay they go straight to the pop culture definition:

There is no history in web development and everybody walks on the shoulders of giants thinking—or pretending—that they’re just following a dirt path conveniently laid out by nature.

This is the first kind of novelty-seeking web developer. The type that sees history only as a litany of mistakes and that new things must be good because they are new. Why would anybody make a new thing unless it was an improvement on the status quo? Ergo, it must be an improvement on the status quo.

If I sound disdainful of this type of developer then my defense is a childish “they were disdainful of me and my experience first!”

Immature and unhelpful, I know. I’m only human.

But I’m not too disdainful. Just a bit. Fields need people who have the pop culture perspective. They are essential for preventing stagnation and driving practice forward. Broad appeal in at least some aspects is necessary for any given field to survive. But this perspective absolutely shouldn’t be as dominant in the field’s discourse as it is today.

Or, more accurately, as it has been up until now. I do think this is changing.

Not everybody in the field fits the pop culture stereotype. Many are naturally growing out of it as they gain experience. Others, many of whom have come into the field through non-traditional paths, have always resisted the pop culture siren song and instead seen something fascinating at the heart of the web that they want to coax out, or ‘develop’ in the sense that Alan Kay used the word in the quote above.

This is the other kind of novelty-seeking web developer, one who seeks to build on the history and nature of the web instead of trying to transform it.

I came into the web from the perspective of interactive media, hypertext, and new media narratives. I see the web as having several unique capabilities that tend to be disregarded by both pop culture devs and Alan Kay.

Every shiny new piece of tech that is fascinating me these days could be characterised as attempts to ‘develop’ these capabilities, evolve these aspects, or use this core of the web in more sophisticated ways.

The specific aspects that fascinate are likely to vary from person to person but for me these are the constant threads I follow:

Many of these are incredibly unpopular among the dominant voices in web development (“hypertext? Bleh”) but are, in my personal opinion, being revitalised by a variety of new ideas, projects, and technologies today.

Encapsulation #

I mention this first as it’s the aspect of the web that modern web developers hate the most without even giving it a label. Single-Page-Apps and GraphQL are both efforts to eradicate the encapsulation that’s baked into the foundation of every layer of the web.

Most modern devs are trying to get rid of it but it’s one of the web’s most strategic advantages.

By default, if you don’t go against the grain of the web, each HTTP endpoint is encapsulated from each other. From the requester’s perspective the logic of each endpoint could be served by an app or script that’s completely isolated from the others. Fetching from that endpoint gets you an HTML file whose state is encapsulated within itself, fetches its visual information from a CSS endpoint and interactivity from a JS resource. Navigating to a new endpoint resets state, styles, and interactivity.

Moreover, all of this can happen really fast if you aren’t going overboard with your CSS and JS.

This encapsulation can dramatically simplify development times and costs if you let it. Once you get into Lambdas/Cloud functions, for example, the platform’s built-in encapsulation means that integration tests and unit tests start to look very, very similar.

Encapsulation can put an upper limit to the complexity and richness of the service you are making, but a lot of very clever people are figuring out ways to raise that limit _without losing the benefits.

That’s something to be excited about.

Hypertext #

The web’s built-in encapsulation would limit it to trivial toy-like projects if we didn’t have a way to build larger interconnected projects. But, instead of the complex shared state that defines most native apps and SPAs, the web represents state as resources that are connected to and transferred via links.

It creates the effect of complex state, without actually resorting to that kind of complexity through a mechanism that you could call REpresentational State Transfer, if you will.

Anchor links: hypertext.

Form elements: hypertext.

RESTful APIs: hypertext.

Style links: hypertext.

JS script elements: hypertext.

It doesn’t matter if you are building a simple form with no JavaScript or if you are building an interconnected API with Hypertext As The Engine Of State: it’s all hypertext.

There are a bunch of really interesting projects popping up lately that are taking the web’s hypertextual leanings in interesting directions and that’s exciting as well.

The Dao of the Web #

So named because, for me, the essay Dao of Web Design that I mentioned earlier is the defining text of this aspect of web development. It predates most of the terms and practices but they are all building on this same idea:

It’s in the nature of the web as a medium to be fluid, adaptable, responsive, and changing.

A lot of practices and ideas fall into this bucket:

It’s the idea that the web isn’t a single fixed thing but a fluid multitude whose shape is dictated by its surroundings.

This approach has been out of vogue in web dev pop culture over the past few years but I think it’s making a comeback through the popularity of static site generators and improvements in many of the popular server-rendered component frameworks.

Which is also exciting.

Distribution #

Finally, what makes the web so amazing and transformative is the sheer bloody reach of it. Of course, this is also why its predominantly a pop culture but the massive distribution that the web makes possible is still something everybody can reach for and benefit from.

Anybody can plonk up an HTML page, maybe with a bit of JS, to a single URL and then start sharing the link to it. It can be a one-note joke like https://istheboatstillstuck.com or a more creative commentary on the news like Ever Given Everywhere. Or, it can be a blog, single essay, useful tool, SaaS, sales page, web book.

The web doesn’t care; it shares.

Which is always exciting (as long as it lasts, world politics being what they are).

What are these new and shiny things you are obsessing about? #

This is the part of this essay that, due to the nature of the thing, is much less likely to age gracefully than the rest. So, if you are stumbling onto this essay in ten year’s time, please be forgiving and bear in mind that these all looked cool in the year of our Lord 2021.

These projects are all taking one or more of these core aspects of the web in interesting or more sophisticated directions.

(“Sophisticated” and “interesting” both being words that, usefully, have the semantic consistency of yoghurt and take whatever form you want them to take in whichever context you decide to place them.)

Deno and Deno Deploy #

I’ve mentioned Deno before on this blog but it genuinely seems to be taking a more ‘webby’ approach to server-side JavaScript than Node.

It’s take on dependencies is fundamentally hypertextual in that it is URL-based. Which means that it’s inevitably going to be a bit messy, as hypertext systems tend to be, but it makes up for it by benefiting from going with the grain of the web.

It tries to replicate existing browser-based APIs where it makes sense: fetch, addEventListener, window, URL, CustomEvent, and more.

It takes popular conventions in the JS world and makes them standard with a built in test runner, linter, formatter, bundler, documentation generator, coverage tooling, etc.

I think we’re likely to be nearing a point in time where new developers will find Deno much easier and simpler to learn, adopt, use, and deploy than Node.

Deno deploy (and services like begin.com that are working on first class deno support) are likely to be a big part of that.

It’s never going to replace Node but it’s likely to stunt its growth at some point.

The good thing about server side programming is that it supports a much greater diversity of languages and platforms so it doesn’t need to replace Node, just be sustainable and growing.

“Deploy this bunch of stuff from a git repository as a bundle” #

We’re seeing so so many of these kinds of services because they make so much sense.

Deploying a bunch of AWS Lambda endpoints (or equivalent) and static assets from a single repository to a single domain gives you top notch encapsulation without sacrificing the benefits of monolithic development. All of the benefits of microservices without any of the drawbacks. The ergonomics of a monolith but with easier testing and greater pricing transparency. And lower costs.

There’s a reason why we have a tonne of these services: they are really, really useful and cost effective.

These service vary in their maturity and target audience. Netlify caters to the front end dev who wants a bit of server side logic. Begin caters a bit more to the server-side developer who is all in on Amazon Web Services. Deno Deploy and CloudFlare Pages prioritise execution speed and easy transferal of front end skills to back. Azure, Firebase, and AWS cater to the “we already have your card details so if our service isn’t complete garbage you’ll probably just settle for this” crowd. Vercel focuses on developer ergonomics surrounding a few select frameworks (mostly next.js).

Normally a cluster of similar services like this would be a sign of a bubble. Which it probably is in part. But there is also a lot of demand. There’s going to be consolidation, most likely among the services that are just convenience layers on top of existing AWS services or the ones that look mismanaged to an outside observer (cough_glitch_cough).

None of that changes the fact that they are all huge improvements in how we make and deploy web sites and services. Which is exciting.

SvelteKit and Turbo/Hotwire #

It may seem strange to bundle these two but they are both trying to implement the experiences that everybody seems to like from Single-Page-Apps in ways that better use the platform and without the common SPA pitfalls.

Hotwire and Turbo use HTML and HTTP to transfer and represent state. It strongly leans on URLs in the form of turbo-frame as a way to compose and coordinate the various parts of the app. By cleverly marrying HTML and WebSockets it makes otherwise 1990s-style websites live and dynamic. Because it leans so strongly on HTML it can be used as libraries with pretty much any framework or server that can send HTML over HTTP.

SvelteKit seemingly could not be more different but it has a similarly strong ‘use the platform’ vibe as Hotwire. Svelte components themselves are a superset of HTML and Svelte tries to avoid reimplementing or reimagining DOM APIs when it can. It’s basically an excellent template language that compiles down to fairly lightweight but reactive client-side components that have first class support for observables. Svelte has been around for a while now and is great. I’ve used it for a few things both a complex web app and for prototyping and it’s the only framework I’ve seen in years that I’m genuinely enthusiastic about.

SvelteKit itself is an even newer addition. It uses JavaScript’s new(ish) hypertextual module system during development but compiles down to bundles (as needed) during deployment. Great developer ergonomics without paying a high price in production.

Which isn’t innovative in and of itself. That’s basically where every other project is heading these days. Thankfully, that isn’t all that it does.

SvelteKit’s default approach to state is an evolution of the standard encapsulated ‘each URL represents state via a resource’ idea that’s baked into HTTP. Each view has a load function that is called to fetch the state for that URL. Which is pretty standard server-rendering fair. It’s the default provided you aren’t engaging in SPA shenanigans. But SvelteKit transparently reuses this logic on the client side. This default behaviour means that you get the state encapsulation benefits of isolated server-rendered endpoints without giving up an SPA-like navigation experience.

Another way to put it: this lets you create SPA-like web apps without having to worry about SPA-like state management (which is a pain in the ass).

(This is an idea SvelteKit carries over from its predecessor Sapper, which is almost great. Occasionally very useful but with too many limitations.)

Moreover, SvelteKit lets you configure prerendering, hydration, and routing on a per URL basis. This means that you can turn off all JS for an endpoint. Or turn off routing and get additional state encapsulation if you want. Or turn off routing and hydration and switch to Turbo/Hotwire or GitHub’s Catalyst for a subsection of your app. Or turn off hydration and switch to vanilla JS for the parts of the service that need to really load fast. You can pre-render the support or help pages while managing them as a part of the same site. This opens SvelteKit up to easy compatibility with pretty much every other web development library or toolkit available in ways that most other server-rendering component frameworks can’t.

Hotwire and SvelteKit lend themselves to different kinds of projects, which is why I’m glad we’re getting both and why I’m excited about both.

(I’m also certain that other projects are implementing similar ideas. These approaches feel like an emerging trend.)

And More #

That’s just a few of the projects I’m excited about these days.

There are so many interesting projects around:

What most of these projects have in common is that they are building on the medium and its history. They aren’t bolting an application platform onto it or trying to compete head-on with native apps. They are helping the web become better at being its own thing.

That’s something to be excited about.