Remix and the Alternate Timeline of Web Development - Jim Nielsen’s Blog
It sounds like Remix takes a sensible approach to progressive enhancement.
It sounds like Remix takes a sensible approach to progressive enhancement.
I really like the progressive enhancement approach that this little library uses—it’s basically the Hijax approach I was talking about back in the days of Bulletproof Ajax but all wrapped up into a neat package that you can use entirely via HTML attributes.
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.
I like this proposal for a declarative Ajax pattern. It’s relatively straightforward to polyfill, although backward-compatibility is an issue because of existing browser behaviour with the target
attribute.
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.
Chris looks at all the different ways of working around the fact that HTML doesn’t do transclusion. Those ways include (hah!) Scott’s super clever technique and Trys’s little Sergey.
Hui-Jing talks through her process of building a to-do app on Glitch using a progressive enhancement mindset:
I found that HTML out-of-the-box takes care of a lot of things when it comes to collecting user inputs from the front-end, which resulted in much less code required. This is not to say client-side Javascript is bad, because the experience was smoother (and faster) when I used it for updating content.
A terrific explanation of the aria-live
attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.
A thorough explanation of the history and inner workings of Cross-Origin Resource Sharing.
Like tales of a mythical sea beast, every developer has a story to tell about the day CORS seized upon one of their web requests, dragging it down into the inexorable depths, never to be seen again.
This looks like a handy library for managing page transitions on sites that are not single page apps.
I’ve said it before and I’ll say it again, but I really think that this handles 80% of the justification for using a single page app architecture.
This is a really good use-case for cancelling fetch requests: making API calls while autocompleting in search.
This is definitely the best review of any of my books.
Google may or may not decide to run your JavaScript, and you don’t want your business to depend on its particular inclination of the day. Do server-side/universal/isomorphic rendering just to be safe.
I saw Christian speak on this topic at Smashing Conference in Barcelona. Here, he takes a long hard look at some of the little things that sites get wrong when doing validating forms on the fly. It’s all good sensible stuff, although it sounds a bit medical when he takes about “Premature Inline Validation.”
This is a truly fantastic example of progressive enhancement applied to a form.
What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.
Superb!
I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:
Turbolinks intercepts all clicks on
a href
links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page usingXMLHttpRequest
, and then renders the HTML response.During rendering, Turbolinks replaces the current
body
element outright and merges the contents of thehead
element. The JavaScriptwindow
anddocument
objects, and the HTMLhtml
element, persist from one rendering to the next.
Here’s the mustard it’s cutting:
It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.
This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.
It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:
Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
A really nice explanation by Todd Kloots of Twitter’s use of progressive enhancement with Ajax and the HTML5 History API. There’s even a shout for Hijax in there.