Link tags: ep

395

sparkline

10 Years of Meteor

While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.

Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.

Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:

  1. Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.

Verdict: 👎

It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.

SPAs: theory versus practice | Read the Tea Leaves

At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:

  1. The best SPA is better than the best MPA.
  2. The average SPA is worse than the average MPA.

Still the Same — Real Life

Everything old is new again:

In our current “information age,” or so the story goes, we suffer in new and unique ways.

But the idea that modern life, and particularly modern technology, harms as well as helps, is deeply embedded in Western culture: In fact, the Victorians diagnosed very similar problems in their own society.

OutHorse Your Email

I must remember to try this out-of-office email strategy.

The balance has shifted away from SPAs | Read the Tea Leaves

I’ve got the same hunch as Nolan:

There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago.

And I think he’s right to frame the appeal of single page apps in terms of control (even if that control comes at the expense of performance and first-load user experience).

Why I don’t miss React: a story about using the platform - Jack Franklin

This is a great case study of switching from a framework mindset to native browser technologies.

Though this is quite specific to Jack’s own situation, I do feel like there’s something in the air here. The native browser features are now powerful and stable enough to make the framework approach feel outdated.

And if you do want to use third-party dependencies, Jack makes a great case for choosing smaller single-responsibility helpers rather than monolithic frameworks.

Replacing lit-html would be an undertaking but much less so than replacing React: it’s used in our codebase purely for having our components (re)-render HTML. Replacing lit-html would still mean that we can keep our business logic, ultimately maintaining the value they provide to end-users. Lit-Html is one small Lego brick in our system, React (or Angular, or similar) is the entire box.

How to Imagine Climate Futures - Long Now

The best climate fiction can do more than spur us to action to save the world we have — it can help us conceptualize the worlds, both beautiful and dire, that may lie ahead. These stories can be maps to the future, tools for understanding the complex systems that intertwine with the changing climates to come.

Progressively Enhanced Builds - Jim Nielsen’s Blog

Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”

I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).

I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).

Blogging and the heat death of the universe • Robin Rendle

A cautionary tale on why you should keep your dependencies to a minimum and simplify your build process (if you even need one):

If it’s not link rot that gets you then it’s this heat death of the universe problem with entropy setting in slowly over time. And the only way to really defend against it is to build things progressively, to make sure that you’re not tied to one dependency or another. That complex build process? That’s a dependency. Your third party link to some third party font service that depends on their servers running forever? Another dependency.

home sweet homepage

I can’t remember the last time that a website made me smile like this.

🐠 Robin Sloan: describing the emotions of life online

Obviously, no one does this, I recognize this is a very niche endeavor, but the art and craft of maintaining a homepage, with some of your writing and a page that’s about you and whatever else over time, of course always includes addition and deletion, just like a garden — you’re snipping the dead blooms. I do this a lot. I’ll see something really old on my site, and I go, “you know what, I don’t like this anymore,” and I will delete it.

But that’s care. Both adding things and deleting things. Basically the sense of looking at something and saying, “is this good? Is this right? Can I make it better? What does this need right now?” Those are all expressions of care. And I think both the relentless abandonment of stuff that doesn’t have a billion users by tech companies, and the relentless accretion of garbage on the blockchain, I think they’re both kind of the antithesis, honestly, of care.

How to make MPAs that are as fast as SPAs | Go Make Things

The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.

Here’s a quick high-level summary of what I do…

  1. Serve pre-rendered, mostly static HTML.
  2. Inline everything, including CSS and JavaScript.
  3. Use mostly platform-native JavaScript, and as little of it as possible.
  4. Minify and gzip all the things.
  5. Lean heavily on service workers.

That’s an excellent recipe for success right there!

When Women Make Headlines

This is a great combination of rigorous research and great data visualisation.

Interfacecritique — Olia Lialina: From My To Me

Don’t see making your own web page as a nostalgia, don’t participate in creating the netstalgia trend. What you make is a statement, an act of emancipation. You make it to continue a 25-year-old tradition of liberation.

Friendly Indie micro-publishers

From Patrick Tanguay:

A list of small micro-publishers — most of them run by one person — putting out great content through their websites, newsletters, and podcasts.

Metaphors We Web By: Paper and Place

Out of all of these metaphors, the two most enduring are paper and physical space.

Best laid plans by Amy Hupe, content designer.

All of Amy’s writing recently has been absolutely wonderful, some of the best I’ve read in a long while, but I particularly needed this one.

I don’t know where we go from here, with this latest pandemic setback, but I do know that things will keep moving.

And if you feel bad today, feel bad. Feel sad or angry or scared or whatever it is you need to feel. Give yourself to yourself as you are.

Things will keep changing. Life will keep unfolding. We will keep going.

Modern CSS in a Nutshell - Cloud Four

I like this high-level view of the state of CSS today. There are two main takeaways:

  1. Custom properties, flexbox, and grid are game-changers.
  2. Pre- and post-processers are becoming less and less necessary.

This is exactly the direction we should be going in! More and more power from the native web technologies (while still remaining learnable), with less and less reliance on tooling. For CSS, the tools have been like polyfills that we can now start to remove.

Alas, while the same should be true of JavaScript (there’s so much you can do in native JavaScript now), people seem to have tied their entire identities to the tooling they use.

They could learn a thing or two from the trajectory of CSS: treat your frameworks as cattle, not pets.

Meet the Self-Hosters, Taking Back the Internet One Server at a Time

Taking the indie web to the next level—self-hosting on your own hardware.

Tired of Big Tech monopolies, a community of hobbyists is taking their digital lives off the cloud and onto DIY hardware that they control.

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

  • use custom elements (for modular HTML without frameworks)
  • use the in-browser package manager (for JavaScript packages without build tools)
  • match pages with files (to avoid routing and simplify architecture)
  • stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.