Thinking about the modern web

17 May 2020 · web, architecture

There's a lot of discussions happening right now on the interwebs about modern front-end builds and practices, and how this compares to traditional static websites. Underlying this is the question, are making progress for the better?

This all started with Tom MacWright's piece, "Second-guessing the modern web". It's quite a good read, and I'd recommend anyone interested in this topic should have a look. I thought I'd take a moment to write down my thoughts.

Here are some take-aways from his piece:

  • "Using React for static-like sites is bizarre". These sites try but won't be as fast as a static site.
  • Bundle-splitting leaves some holes in it's implementation.
  • Static sites are too simple for React, and not a good use case of the stack.

Read the piece and thought I'd write down a few thoughts that came to mind.

Enjoyment / DX

This was my first feeling on the topic. I don't really mind what people build their website with. Personally I'll choose to build it with something I enjoy building with.

More onto the topic, I agree with a lot of his points around pitfalls modern SPA builds and front-end architecture. I especially agree that for static content websites, a developer might not be leveraging all the power of these SPA frameworks, while taking on the downsides (highlighted quite well in his piece).

Though having worked for years with Rails, Laravel and Django building websites and apps, and then moving to Node, I much prefer it for rendering markup or delivering user experiences. The tooling in the JS world is, in my opinion, better. 😄 And being able to use the same language everywhere is a treat. (Note that I am not talking about API design here, I'm impartial what tech used there).

Edit: Someone raised this point, and MacWright acknowledged that enjoyment is a good reason to choose the stack you want.

Learning

Another point that I think about is that a personal website is a great place to learn things. They're a personal project, so anyone can build it with anything they want, even things that they want to learn. So if people use their personal website as a means to learn [insert weird and wonderful modern tech here], I say go for it! More power to them.

Performance

There's a big focus on the fact that all the optimisations being done on the SPA space won't compete against a static website in terms of performance. And that's probably true at this point in time. However, I can't argue that it's necessarily a bad thing. Being a few milliseconds slower isn't such a bad thing. This is a static website after all.

UX

There's a lot of discussions that these SPA frameworks allow for better user experiences. Client-side rendering between pages means less data travelling over the wire for subsequent page loads. Some frameworks have built in transition engines, which are quite neat too and make it easier for cool page transitions.

On the other side, there is the argument that these can be added on top of static sites too. Years ago, I built a static site which used turbolinks and a fading page transition, to great effect. 😀 And even today, one could use frameworks like AlpineJS to add a lot of these new SPA features easily to their existing static website. So yes, I agree with the argument that SPA frameworks don't necessarily need to be used for static websites.

I always remind myself of @minimalmonkey's website, built in the early days of SPA frameworks.

Stephen Burgess' Website - minimalmonkey.com

I loved this website. Static, simple, fast and had an amazing UX. And he's even shared what libraries he used to build it with: jQuery and underscoreJs.

There are other techniques that I have seen recently like Laravel Livewire, which combine the component level development experience with the server-rendered performance. This also solves the "Double Data" problem which is introduced by SSR (having data in DOM, as well as a JSON blob at the bottom on the page for rehydration).

These techniques are quite cool, and I think are good attempts solving the problems that developers are facing. And that's what I enjoy about the modern web, it's always moving to solve a problem.

Tooling

When talking about building good websites, I can't help but compare it to photography (my other passion).

We know what good photographs are (subjectively), we've been taking them for ages now. However, thanks to modern technology, it's become considerably easier and more accessible for people to take good photos.

So in the same vein:

Good web experiences have been around for a while now, whatever they get built on. And hopefully, with improvements in tooling, it'll get easier for people to build great and performant web experience by default.

This was a big takeaway when I read Rich Harris's response to Tom, "In defense of the modern web".

The future I want — the future I see — is one with tooling that's accessible to the greatest number of people (including designers), that can intelligently move work between server and client as appropriate, that lets us build experiences that compete with native on UX (yes, even for blogs!), and where upgrading part of a site to 'interactive' or from 'static' to 'dynamic' doesn't involve communication across disparate teams using different technologies.

Final thoughts

I think a lot of the downsides Tom raises are valid. The bundle-slitting issues with SPAs, for example, is a real issue which hasn't been solved yet. Also, there's the point that there are developers building projects (especially commercially) with front-end practices which probably are more complex than required. There are other issues he hadn't raised, like the double data downloads of SSR webpages.

At the same time, I'm not worried about the trajectory of the web, but rather excited for it. I agree that there are bumps, and things can be improved, and that's exactly what's happening. Things are being improved, frameworks are getting easier, and better and more efficient every day by default. And there are more of them, catering to whatever flavour of developer a person wants to be. That's a great thing! It means that a lazy someone like me can use cool tooling and enjoy building apps, with performance handled for me out of the box, leaving me to worry about the thing I'm trying to build.

Honestly, I found his piece quite timely. I had just finished building this website, and some of his points were considerations I made. In my case, I didn't feel the need for React or Vue when I was building this website. I knew that for the most part, it was just going to be a static website. However, I did want the DX those frameworks give me when building UIs. I was looking for something like React, but when I'm done and rendered, the framework goes away.

What I wanted was a tool that would give me the component-based development experience I enjoy for building UIs (keeping markup and logic together), the ability to server render that UI, while then removing the framework "runtime".

A huge step in that direction for me was when I saw Svelte, and then Sapper for the first time. Svelte compiles itself away (for the most part), leaving just a small bundle with only the code required to run the website. Taking away a chunk of the 'framework' runtime, leaving just the JavaScript I import and need to handle the minimal interactivity of this website.

I chose Svelte to build this website, rather than "static" website tooling. And I enjoyed creating it, and have enjoyed the result.

And on the client-side, it doesn't seem to be all that bulky or slow. I haven't really made an effort to make it fast or anything.

PageInsight test on this website

I'm genuinely excited for the future of the web. 😁