Tags: spa



Thursday, April 1st, 2021

Meet Utopia: Designing And Building With Fluid Type And Space Scales — Smashing Magazine

An excellent explainer from Trys and James of their supersmart Utopia approach:

Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.

Thursday, March 18th, 2021

Now THAT’S What I Call Service Worker! – A List Apart

This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.

Wednesday, March 17th, 2021

Fluid Space Calculator | Utopia

Type and space are linked, so if you’re going to have a fluid type calculator, it makes sense to have a fluid space calculator too. More great work from Trys and James!

Wednesday, March 10th, 2021

So your grandmother is a starship now: a quick guide for the bewildered

Useful FAQs.

Your grandmother is not just a starship, she’s a highly individual starship with her own goals and needs!

Friday, February 26th, 2021

The Future of Web Software Is HTML-over-WebSockets – A List Apart

One of the other arguments we hear in support of the SPA is the reduction in cost of cyber infrastructure. As if pushing that hosting burden onto the client (without their consent, for the most part, but that’s another topic) is somehow saving us on our cloud bills. But that’s ridiculous.

Tuesday, February 9th, 2021

Interplanetary Lobbing

League tables for the game of probe-throwing currently underway in our solar system.

The league covers expensive hardware lob matches held between planets in the Solar System. Two dwarf planets have recently been admitted to the league and lost their first matches against league champions Team Earth.

Sunday, January 17th, 2021

Eleanor Lutz - An Orbit Map of the Solar System

A lovely visualisation of asteroids in our solar system.

Wednesday, December 23rd, 2020

HTML Over The Wire | Hotwire

This is great! The folks at Basecamp are releasing the front-end frameworks they use to build Hey. There’s Turbo—the successor to Turbolinks:

It offers a simpler alternative to the prevailing client-side frameworks which put all the logic in the front-end and confine the server side of your app to being little more than a JSON API.

With Turbo, you let the server deliver HTML directly, which means all the logic for checking permissions, interacting directly with your domain model, and everything else that goes into programming an application can happen more or less exclusively within your favorite programming language. You’re no longer mirroring logic on both sides of a JSON divide. All the logic lives on the server, and the browser deals just with the final HTML.

Yes, this is basically Hijax (which is itself simply a name for progressive enhancement applied to Ajax) and I’m totally fine with that. I don’t care what it’s called when the end result is faster, more resilient websites.

Compare and contrast the simplicity of the Hotwire/Turbo approach to the knots that React is tying itself up in to try to get the same performance benefits.

Saturday, November 14th, 2020

The Correct Material

I’ve been watching The Right Stuff on Disney Plus. It’s a modern remake of the ’80s film of the ’70s Tom Wolfe book of ’60s events.

It’s okay. The main challenge, as a viewer, is keeping track of which of the seven homogenous white guys is which. It’s like Merry, Pippin, Ant, Dec, and then some.

It’s kind of fun watching it after watching For All Mankind which has some of the same characters following a different counterfactual history.

The story being told is interesting enough (although Tom has pointed out that removing the Chuck Yeager angle really diminishes the narrative). But ultimately the tension is manufactured around a single event—the launch of Freedom 7—that was very much in the shadow of Gargarin’s historic Vostok 1 flight.

There are juicier stories to be told, but those stories come from Russia.

Some of these stories have been told in film. The Spacewalker told the amazing story of Alexei Leonov’s mission, though it messes with the truth about what happened with the landing and recovery—a real shame, considering that the true story is remarkable enough.

Imagine an alternative to The Right Stuff that relayed the drama of Soyuz 1—it’s got everything: friendship, rivalries, politics, tragedy…

I’d watch the heck out of that.

Wednesday, October 28th, 2020

Portals and giant carousels

I posted something recently that I think might be categorised as a “shitpost”:

Most single page apps are just giant carousels.

Extreme, yes, but perhaps there’s a nugget of truth to it. And it seemed to resonate:

I’ve never actually seen anybody justify SPA transitions with actual business data. They generally don’t seem to increase sales, conversion, or retention.

For some reason, for SPAs, managers are all of a sudden allowed to make purely emotional arguments: “it feels snappier”

If businesses were run rationally, when somebody asks for an order of magnitude increase in project complexity, the onus would be on them to prove that it proportionally improves business results.

But I’ve never actually seen that happen in a software business.

A single page app architecture makes a lot of sense for interaction-heavy sites with lots of state to maintain, like twitter.com. But I’ve seen plenty of sites built as single page apps even though there’s little to no interactivity or state management. For some people, it’s the default way of building anything on the web, even a brochureware site.

It seems like there’s a consensus that single page apps may have long initial loading times, but then they have quick transitions between “pages” …just like a carousel really. But I don’t know if that consensus is based on reality. Whether you’re loading a page of HTML or loading a chunk of JSON, you’re still making a network request that will take time to resolve.

The argument for loading a chunk of JSON is that you don’t have to make any requests for the associated CSS and JavaScript—they’re already loaded. Whereas if you request a page of HTML, that HTML will also request CSS and JavaScript.

Leaving aside the fact that is literally what the browser cache takes of, I’ve seen some circular reasoning around this:

  1. We need to create a single page app because our assets, like our JavaScript dependencies, are so large.
  2. Why are the JavaScript dependencies so large?
  3. We need all that JavaScript to create the single page app functionlity.

To be fair, in the past, the experience of going from page to page used to feel a little herky-jerky, even if the response times were quick. You’d get a flash of a white blank page between navigations. But that’s no longer the case. Browsers now perform something called “paint holding” which elimates the herky-jerkiness.

So now if your pages are a reasonable size, there’s no practical difference in user experience between full page refreshes and single page app updates. Navigate around The Session if you want to see paint holding in action. Switching to a single page app architecture wouldn’t improve the user experience one jot.


If I were controlling everything with JavaScript, then I’d also have control over how to transition between the “pages” (or carousel items, if you prefer). There’s currently no way to do that with full page changes.

This is the problem that Jake set out to address in his proposal for navigation transitions a few years back:

Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.

I love this proposal. It focuses on user needs. It also asks why people reach for JavaScript frameworks instead of using what browsers provide. People reach for JavaScript frameworks because browsers don’t yet provide some functionality: components like tabs or accordions; DOM diffing; control over styling complex form elements; navigation transitions. The problems that JavaScript frameworks are solving today should be seen as the R&D departments for web standards of tomorrow. (And conversely, I strongly believe that the aim of any good JavaScript framework should be to make itself redundant.)

I linked to Jake’s excellent proposal in my shitpost saying:

bucketloads of JavaScript wouldn’t be needed if navigation transitions were available in browsers

But then I added—and I almost didn’t—this:

(not portals)

Now you might be asking yourself what Paul said out loud:

Excuse my ignorance but… WTF are portals!?

I replied with a link to the portals proposal and what I thought was an example use case:

Portals are a proposal from Google that would help their AMP use case (it would allow a web page to be pre-rendered, kind of like an iframe).

That was based on my reading of the proposal:

…show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.

It sounded like Google’s top stories carousel. And the proposal goes into a lot of detail around managing cross-origin requests. Again, that strikes me as something that would be more useful for a search engine than a single page app.

But Jake was not happy with my description. I didn’t intend to besmirch portals by mentioning Google AMP in the same sentence, but I can see how the transitive property of ickiness would apply. Because Google AMP is a nasty monopolistic project that harms the web and is an embarrassment to many open web advocates within Google, drawing any kind of comparison to AMP is kind of like Godwin’s Law for web stuff. I know that makes it sounds like I’m comparing Google AMP to Hitler, and just to be clear, I’m not (though I have myself been called a fascist by one of the lead engineers on AMP).

Clearly, emotions run high when Google AMP is involved. I regret summoning its demonic presence.

After chatting with Jake some more, I tried to find a better use case to describe portals. Reading the proposal, portals sound a lot like “spicy iframes”. So here’s a different use case that I ran past Jake: say you’re on a website that has an iframe embedded in it—like a YouTube video, for example. With portals, you’d have the ability to transition the iframe to a fully-fledged page smoothly.

But Jake told me that even though the proposal talks a lot about iframes and cross-origin security, portals are conceptually more like using rel="prerender" …but then having scripting control over how the pre-rendered page becomes the current page.

Put like that, portals sound more like Jake’s original navigation transitions proposal. But I have to say, I never would’ve understood that use case just from reading the portals proposal. I get that the proposal is aimed more at implementators than authors, but in its current form, it doesn’t seem to address the use case of single page apps.

Kenji said:

we haven’t seen interest from SPA folks in portals so far.

I’m not surprised! He goes on:

Maybe, they are happy / benefits aren’t clear yet.

From my own reading of the portals proposal, I think the benefits are definitely not clear. It’s almost like the opposite of Jake’s original proposal for navigation transitions. Whereas as that was grounded in user needs and real-world examples, the portals proposal seems to have jumped to the intricacies of implementation without covering the user needs.

Don’t get me wrong: if portals somehow end up leading to a solution more like Jake’s navigation transitions proposals, then I’m all for that. That’s the end result I care about. I’d love it if people had a lightweight option for getting the perceived benefits of single page apps without the costly overhead in performance that comes with JavaScripting all the things.

I guess the web I want includes giant carousels.

Monday, October 5th, 2020

The 2020 Design Systems Survey by Sparkbox

These survey results show that creating and maintaining an impactful design system comes with challenges such as planning a clear strategy, managing changes to the system, and fostering design system adoption across the organization. Yet the long-lasting value of a mature design system—like collaboration and better communication—awaits after the hard work of overcoming these challenges is done.

Wednesday, August 12th, 2020

Project Orbital Ring

An Orbital Ring System as an alternative to a space elevator.

Representing nothing short of the most ambitious project in the history of space exploration and exploitation, the Orbital Ring System is more or less what you would imagine it to be, a gargantuan metal ring high above the Earth, spanning the length of its 40,000 kilometer-long diameter.

Friday, August 7th, 2020

Rainbow spacecraft and how humanity might end (Interconnected)

I too am a member of The British Interplanetary Society and I too recommend it.

(Hey Matt, if you really want to go down the rabbit hole of solar sails, be sure to subscribe to the RSS feed of Centauri Dreams—Paul Gilster is big into solar sails!)

Monday, August 3rd, 2020

The People’s Space Odyssey: 2010: The Year We Make Contact

This is an epic deep dive into the 1984 sequel to 2001: A Space Odyssey.

For all its flaws, I have a soft spot for this film (and book).

Tuesday, July 7th, 2020

Monday, July 6th, 2020

Spatial Awareness

Robin Hawkes has made a lovely website to go with his newsletter all about maps and spatial goodies.

Wednesday, June 17th, 2020

Pandemic Time: A Distributed Doomsday Clock - NOEMA

A meditative essay on the nature of time.

The simultaneous dimming of Betelgeuse and the global emergence of COVID-19 were curiously rhyming phenomena: disruptions of familiar, reassuring rhythms, both with latent apocalyptic potential.

Time and distance are out of place here.

We will have left a world governed by Chronos, the Greek god of linear, global, objective time measured by clocks, and arrived into a world governed by Kairos, the Greek god of nonlinear, local, subjective time, measured by the ebb and flow of local patterns of risk and opportunity. The Virus Quadrille is not just the concluding act of pandemic time but the opening act of an entire extended future.

Sunday, June 14th, 2020

NASA Collection

Back in 1985, Ian wrote to NASA to get some info for a shool project (that’s how it worked before the World Wide Web). NASA sent him a treaure trove in response. Here they are, scanned as PDFs. Mercury, Gemini, Apollo, the Space Shuttle, and more.

Tuesday, May 12th, 2020

as days pass by — Hammer and nails

We don’t give people a website any more: something that already works, just HTML and CSS and JavaScript ready to show them what they want. Instead, we give them the bits from which a website is made and then have them compile it.

Spot-on description of “modern” web development. When did this become tolerable, much less normal?

Web developers: maybe stop insisting that your users compile your apps for you? Or admit that you’ll put them through an experience that you certainly don’t tolerate on your own desktops, where you expect to download an app, not to be forced to compile it every time you run it?

Monday, May 11th, 2020

Second-guessing the modern web - macwright.org

I’m at the point where you look at where the field is and what the alternatives are – taking a second look at unloved, unpopular, uncool things like Django, Rails, Laravel – and think what the heck is happening. We’re layering optimizations upon optimizations in order to get the SPA-like pattern to fit every use case, and I’m not sure that it is, well, worth it.

Spot-on analysis of what React is and isn’t good for. And lest you think this is blasphemy, Dan Abramov agrees.