the personal site of drew powers

did we fuck up the internet? part 1

published
updated
tagged
dev

“Learn the fundamentals” is a common piece of advice given to beginners when starting out. And usually for web pages, it’s some form of “learn HTML, CSS, and JS.” Those three will never go away, and will outlast any flavor-of-the-month framework (but full disclosure: I actually do tell beginners to learn a flavor-of-the-month framework because it’s motivating, it’s what gets them hired, and you can still learn the fundamentals at the same time).

But what if the fundamentals… aren’t so fundamental? What were to happen if the fundamentals changed?

I’ve never written a “was the internet a mistake?” blog post (it’s either a cheap laugh—“we’re monkeys that tricked rocks to think; we deserve what we get! ha ha”—or a bit melodramatic). But I guess 2020 is the year I start.

backstory: why I’m questioning the web

When I say I’m questioning the fundamentals of the web, I basically mean the HTML/CSS/JS + browsers combo. Or at least this current version of it. Part 1 (this post) will outline what led to this. The following parts will try and soothsay a little.

the Mozilla layoffs

Our journey begins with Mozilla laying off 25% of its staff in August 2020. Software layoffs suck in general, but they really suck when they carry global impact. An extreme (but possible) take on the outcome is: this is the death of Firefox and MDN as we know it (Rust may be OK).

If Firefox goes, then the burden of the internet rests practically on the shoulders of Chromium (if you’re reading this in the far future, remember that Microsoft recently abandoned their historic browser project in favor of Chromium).

At worst, such monopolistic control over the internet is so dangerous it had to be held in check by a 2001 Supreme Court ruling. At best, the responsibility of stewarding the development of the entire internet is so monumental, it crushes any mere team of mortals tasked with it. Either way, if Chromium is the last browser standing, it’s bad news for all.

Do you think the web has almost ‘priced itself out of the market’ in terms of complexity if only 1-2 organisations are capable of building rendering engines for it?

Microsoft gave up, Mozilla will struggle as you say.

— Mike Healey on Aug 20

I guess there’s WebKit still 🤷‍♂️. Until Apple remembers they’re supposed to maintain it.

maybe JS isn’t the answer

We pause there, and join the developer discussion in another part of the dev sphere, where people (like myself) are having existential career questions. Second-guessing the modern web by Tom MacWright comes to mind as a post at the center of the discussion around whether or not our current JS-heavy trajectory is healthy.

JS has always had nay-sayers. JavaScript fatigue had been questioning this direction since 2015. And there have been no shortage of the “get off my lawn“ old guard complaining about any attempt at replacing jQuery (link). However, MacWright’s post came across as a concerned insider rather than an outside detractor that even got the React folk thinking (and yes, there’s a world of difference between the two).

I’d wager that if React is under question, the larger JS direction (React + webpack, built by Node.js) is under question by extension. Of course they aren’t the same thing, but nothing has come close to React’s popularity and staying power for the web (especially when you factor in React Native and other targets). If React goes, there’s no clear replacement, which means further splintering.

In rough chronological order, here are a few notable discussions/milestones that amount to some key players in tech all rethinking reliance in JS:

our tools are (still) fractured

From time to time we all need to step outside our bubbles (JS, Rails, PHP, etc.) and be reminded that the web development community is (still) fractured. HTML, CSS, and JS are inadequate in their current form, so we turn to ellaborate tools to fill in their shortcomings.

We can’t simply write HTML, so we turn to template languages: Nunjucks, Jinja, Handlebars, Pug, and Liquid, to name only a few (there are dozens and dozens I missed). But to compile these non-standard templates, we need a compiler that’s likely built in Ruby, Node.js, Go, Python, or Rust, depending on our choices (and the language used has sweeping consequences).

Or perhaps you need to generate markup dynamically, in which case you’ll need a server. Again you’ll have to pick a language (Ruby, Node.js, Go, PHP, Python, or Rust) as well as a framework (Rails, Nest.js, Django, Laravel, Rocket, etc.). Your choice here will have further sweeping consequences.

And then there’s writing JS, which may or may not get types (TypeScript), and which will likely be built in a framework (Svelte, React, Vue, Angular, etc.). All of these choices will require setting up tooling (webpack / Rollup / Snowpack), as well as the connection to the server from your earlier choices.

By now, we’ve been divided and subdivided and subdivided again by our choices. I want to be clear: I’m not at all advocating that we need to use one programming language for anything, or that different problems need different solutions. But I am wondering why, if webpages are supposed to be a standardized concept, there are so many splintered ways to assemble them that I fear we’re losing knowledge (and people) in between the gaps.

There shouldn’t be so many ways to do one standard thing.

where do we go from here?

To recap, I’m questioning current webdev practices because:

  • we might be back to a browser monopoly again
  • all of us hate writing HTML/CSS/JS so much we invent new ways every year to avoid it
  • React + Node.js bundlers are cool but didn’t live up to promises
  • our savior, web components, wasn’t received well (also worth mentioning it was championed by our Chromium overlords so we’ll see if they ever do anything nice for us again)

All signs that cast doubt on our current direction. But even though the future is uncertain and there’s no clear answer to how we solve all this, we can still make some intelligent bets. So in part 2, we’ll do exactly that.