Link tags: script

996

sparkline

Will Serving Real HTML Content Make A Website Faster? Let’s Experiment! - WebPageTest Blog

Spoiler: the answer to the question in the title is a resounding “hell yeah!”

Scott brings receipts.

The self-fulfilling prophecy of React - Josh Collinsworth blog

Matcalfe’s Law in action:

Companies keep choosing React because they know there’s a massive pool of candidates who know it; candidates keep learning React because they know companies are hiring for it. It’s a self-sustaining cycle.

But the problem is:

React isn’t great at anything except being popular.

Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development

We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.

A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:

We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.

Why your website should work without Javascript. | endtimes.dev

The obvious answer to why you should build a website that doesn’t need js is… because some people don’t use js. But how many?!

Bring Focus to the First Form Field with an Error :: Aaron Gustafson

A handy little script from Aaron to improve the form validation experience.

Lean Web Club

New from Mr. Vanilla JS himself, Chris Ferdinandi:

A learning space for people who hate the complexity of modern web development.

It’ll be $29 a month or $299 a year (giving you two months worth for free).

The impact of removing jQuery on our web performance - Inside GOV.UK

Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.

It may sound like 32 kb of JavaScript is nothing on today’s modern web with quick devices and fast broadband connections. But for a certain cohort of users, it makes a big difference to how they experience GOV.UK.

How and why we removed jQuery from GOV.UK - Inside GOV.UK

This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!

Removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance.

Open Lecture at CIID: “Keeping up with the Kardashevians” – Petafloptimism

A terrfic presentation from Matt Jones (with the best talk title ever). Pace layers, seamful design, solarpunk, and more.

Stop supporting Internet Explorer!

The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.

When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.

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.

How we think about browsers | The GitHub Blog

JavaScript doesn’t get executed on very old browsers when native syntax for new language features is encountered. However, thanks to GitHub being built following the principle of progressive enhancement, users of older browsers still get to interact with basic features of GitHub, while users with more capable browsers get a faster experience.

That’s the way to do it!

Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.

Read on for the nitty-gritty details…

In and Out of Style · Matthias Ott – User Experience Designer

Some thoughts—and kind words—prompted by my recent talk, In And Out Of Style.

Introducing Opportunities & Experiments: Taking the Guesswork out of Performance - WebPageTest Blog

WebPageTest just got even better! Now you can mimic the results of what would’ve previously required actually shipping, like adding third-party scripts, switching from a client-rendered to a server-rendered architecture and other changes that could potentially have a big effect on performance. Now you can run an experiment to get the results before actual implementation.

What the Vai Script Reveals About the Evolution of Writing - SAPIENS

How a writing system went from being a dream (literally) to a reality, codified in unicode.

The Demise of the Mildly Dynamic Website

It me:

Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.

This rings sadly true to me:

Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

Also, I never thought about “serverless” like this:

Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.

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.

Trust • Robin Rendle

Robin adds a long-zoom perspective on my recent post:

I am extremely confident that pretty much any HTML I write today will render the same way in 50 years’ time. How confident am I that my CSS will work correctly? Mmmm…70%. Hand-written JavaScript? Way less, maybe 50%. A third-party service I install on a website or link to? 0% confident. Heck, I’m doubtful that any third-party service will survive until next year, let alone 50 years from now.

Trust and suspicion | Keenan Payne

Another thoughtful reponse to my recent post.

Reflections on native browser features and third-party library adoption.