Isomorphic rendering on the JAM Stack

Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):

I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.

Now that’s resilient web design!

Isomorphic rendering on the JAM Stack

Tagged with

Related links

It’s a Website | treevis

Apps:

Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.

Websites:

Websites can be viewed by anyone with a web browser.

And that doesn’t mean foregoing modern features:

A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.

This is why progressive enhancement is so powerful.

My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.

Tagged with

The Pastry Box Project, Scott Jehl, Friday, 7 March 2014

Scott writes an absolutely spot-on skewering of the idea that progressive enhancement means you’re going to spend your time catering to older browsers. The opposite is true.

Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.

Tagged with

Being Practical - TimKadlec.com

Yet another timely reminder from Tim, prompted by the naysayers commenting on his previous excellent post on progressive enhancement, universal access, and the nature of the web.

Tagged with

Something went wrong · molily

Debating complexity is pointless because it’s a subjective metric. Every developer has a different gut feeling about simplicity, complexity and the appropriate amount of complexity for a given task. When people try to find an objective definition, they come to wildly different results. And that’s okay.

Instead, we should focus on hard metrics from a user perspective. Performance, efficiency, compatibility, accessibility and fault-tolerance can be measured, tested and evaluated, automatically and manually.

Any amount of complexity is fine as long as these goals are met.

Tagged with

The Neverending Story

Since the early days of the web, large corporations have seemingly always wanted more than the web platform or web standards could offer at any given moment. Whether they were aiming for cross-platform-compatibility, more advanced capabilities, or just to be the one runtime/framework/language to rule them all, there’s always been a company that believes they can “fix” it or “own” it.

Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.

Tagged with

Related posts

Manual ’till it hurts

Try writing your HTML in HTML, your CSS in CSS, and your JavaScript in JavaScript.

Securing client-side JavaScript

Tightening up my content security policy.

Switching costs

The enshittification of React …which was already pretty shitty for users.

event.target.closest

DOM scripting and event handling.

Relative times

Messing around with Intl.RelativeTimeFormat on The Session.