the new old web

Day 4 of 30. Getting back into the rhythm of writing every day brings me back 14 years to when I wrote In Silico as part of National Novel Writing Month, or NaNoWriMo as it's commonly shortened.

Back then, I wrote In Silico using Google Docs. Google Docs itself launched 3 years prior in 2006, at which time I did a couple of semester-long internships at Idée (now Tineye), Toronto-based pioneers in visual (or "reverse") image search. I vaguely recall a lot of jQuery and Django, and I think there was a copy of Higher-Order Perl on the shelf at work. We didn't use Perl, mind you, but the days of cgi-bin scripts weren't far behind.

Not long before that, I recall setting up my first real website, writing raw HTML in Notepad++ on my Windows 98 desktop in my dorm room at the University of Waterloo. I don't miss moving its massive CRT monitor every 4 months as I alternated between study and work terms, but I do sometimes miss the simple, naïve times of early web development.

You had wacky HTML tags like <blink>, which Firefox supported right up until version 23 launched in mid-2013. Terms like server-side rendering and islands architecture didn't exist yet, because they didn't need to; they were the default. View Source was tutor and teacher. Sites like CSS Zen Garden helped you navigate the quirks of CSS.

Change had been coming for a while, though. In 2009, Geocities shut down in the US. Shortly after university I joined Facebook (now Meta), a huge PHP shop that was just about to release React into the wild. AWS was growing rapidly enough that by 2012 it had its own conference. Entire toolchains that people take for granted now were being born, largely to serve the demands of the new web: a web of highly dynamic applications at global scale.

In some ways, React and AWS and other new web tools weren't just about scaling applications. They were about scaling teams. Similar to how video games stopped being the work of solo virtuoso creators and started being the work of whole teams and studios, web applications now required larger coordinated efforts to build. When I joined Facebook, they had 300 engineers, building everything from user-facing features to backend systems for detecting spam and fraud to just-in-time PHP compilers to MySQL mainline patches.

React offered a way to manage this chaos: package your application's interactivity, and the state required to manage it, up into smaller components that self-update as state changes. Now you could turn this:

<input type="text" id="foo" name="foo" value=""></input>
<span id="foo_output"></span>

<script>
var foo = '';
var $input = $('#foo');
var $output = $('#foo_output');

$input.on('keyup', function () {
  foo = $input.val();
  $output.text(foo);
});
</script>

into this:

const Foo = () => {
  const [foo, setFoo] = useState('');
  const handleInput = (e) => setFoo(e.target.value);

  return (
    <input type="text" name="foo" defaultValue={ foo } onInput={ handleInput } />
    <span>{ foo }</span>
  );
}

And the big thing about this change wasn't the code itself. You'd be forgiven for looking at this (admittedly very basic) example and thinking "so what?" No short example can show the value of reactive component frameworks; that value happens at scale.

That's the real big thing here: now you could restructure and scale the development process.

Frontend devs could build components with designers, while backend devs could build backend API endpoints. UI engineering teams could build components designed for use across your whole company - and now you had design systems. DevOps engineers could help you provision and manage infrastructure - and now you had infrastructure-as-code and CI / CD pipelines. Engineering leaders looked for ways to keep focus on specific deliverables at scale - and now you had agile development.

If you joined the industry building web applications in the last 10 years, this is just How It Works.

More recently, there's been a counter-movement, a renaissance of old web techniques. htmx brings long-missing functionality to HTML. Remix focuses on "progressively-enhanced single page applications", or PESPAs: a blend of old web multi-page application architecture with new web single-page application techniques. Next.js 14 joins the PESPA party. React, long the poster child for SPAs, recommends Next.js and Remix for use in new React-based applications.

The world turns, and us with it. One testimonial from the htmx website reads:

After the port to htmx, the entire team became “full stack” developers. This means that each team member is more effective and able to contribute more value. It also makes development more fun, since developers can own an entire feature. Finally, it can lead to better optimized software, since the developer can make optimizations anywhere in the stack without needing to coordinate with other developers.

Fair enough. Other cited benefits of PESPA and islands and similar new old web approaches: accessibility, better UX on degraded networks, fewer data-syncing bugs between client and server, faster First Contentful Paint, and so on.

But the fun thing about this transition is that it's not like the previous transition. Roughly no one uses jQuery today; the transition to the new web largely meant throwing out old web tools. With PESPA frameworks, however, you can keep your team's knowledge of React and Backend-for-Frontend patterns and cloud infrastructure, and just tweak it a bit. Dust off that knowledge of old web HTML and combine it with new web browser APIs like FormData and fetch.

Take advantage of the fact that, while 2009 HTML / CSS / JS was a tire fire of browser wars incompatibilities and clearfixes and <blink> tags, 2023 HTML / CSS / JS is a lot better as a platform to build on. The new old web ain't so bad.