Tags: script

1186

sparkline

Friday, November 18th, 2022

Remix and the Alternate Timeline of Web Development - Jim Nielsen’s Blog

It sounds like Remix takes a sensible approach to progressive enhancement.

Monday, November 7th, 2022

as days pass by — Don’t Read Off The Screen

Excellent advice from Stuart.

Watch—and more importantly, listen—to this five minute video to get the full effect.

Monday, October 24th, 2022

The transitional web | Go Make Things

I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.

Thursday, October 20th, 2022

Why We’re Breaking Up with CSS-in-JS | Brad Frost

I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.

But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:

So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.

Wednesday, October 19th, 2022

JavaScript

A recurring theme in my writing and talks is “lay off the JavaScript, people!” But I have to make a conscious effort to specify that I mean client-side JavaScript.

I thought it would be obvious from the context that I was talking about the copious amounts of JavaScript being shipped to end users to download, parse, and execute. But nothing’s ever really obvious. If I don’t explicitly say JavaScript in the browser, then someone inevitably thinks I’m having a go at JavaScript, the language.

I have absolutely nothing against JavaScript the language. Just like I have nothing against Python or Ruby or any other language that you might write with on your machine or your web server. But as soon as you deliver bytes over the wire, I start having opinions. It just so happens that JavaScript is the universal language for client-side coding so that’s why I call for restraint with JavaScript specifically.

There was a time when JavaScript only existed in web browsers. That changed with Node. Now it’s possible to write code for your web server and code for web browsers using the same language. Very handy!

But just because it’s the same language doesn’t mean you should treat it the same in both circumstance. As Remy puts it:

There are two JavaScripts.

One for the server - where you can go wild.

One for the client - that should be thoughtful and careful.

I was reading something recently that referred to Eleventy as a JavaScript library. It really brought me up short. I mean, on the one hand, yes, it’s a library of code and it’s written in JavaScript. It is absolutely technically correct to call it a JavaScript library.

But in my mind, a JavaScript library is something you ship to web browsers—jQuery, React, Vue, and so on. Whereas Eleventy executes its code in order to generate HTML and that’s what gets sent to end users. Conceptually, it’s like the opposite of a JavaScript library. Eleventy does its work before any user requests a URL—JavaScript libraries do their work after a user requests a URL.

To me it seems obvious that there should an entirely different mindset for writing code intended for a web browser. But nothing’s ever really obvious.

I remember when Node was getting really popular and npm came along as a way to manage all the bundles of code that people were assembling in their Node programmes. Makes total sense. But then I thought I heard about people using npm to do the same thing for client-side code. “That can’t be right!” I thought. I must’ve misunderstood. So I talked to someone from npm and explained how I must be misunderstanding something.

But it turned out that people really were treating client-side JavaScript no different than server-side JavaScript. People really were pulling in megabytes of other people’s code to ship to end users so that they could, I dunno, left pad numbers or something.

Listen, I don’t care what you get up to in the privacy of your own codebase. But don’t poison the well of the web with profligate client-side JavaScript.

Sunday, October 16th, 2022

How to (not) make a button - Tomas Pustelnik’s personal website

A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.

Thursday, October 13th, 2022

Two JavaScripts

There are two JavaScripts.

One for the server - where you can go wild.

One for the client - that should be thoughtful and careful.

Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.

It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.

I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.

The Web’s Next Transition | Epic Web Dev by Kent C. Dodds

The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.

I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.

Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:

The most popular architecture employed by web developers today is the Single Page App (SPA)

Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.

Progressively enhance for a more resilient web :: jjenzz

I realised, progressive enhancement isn’t only about supporting that 1%. It’s about testing your app without JavaScript to ensure 100% of your users have a more performant, usable, available, and resilient experience.

A really good explanation of progressive enhancement as an approach to building anything on the web:

Progressive enhancement does not mean you need to provide the exact same UI without JavaScript. The enhanced experience should be better and it should do more, otherwise the enhanced experience is not needed at all. It enhances a degraded experience that also allows the user to accomplish their goal. For example, entering a postal code manually into a text box might be the degraded experience, and the progressively enhanced experience would prefill the text box based on Geolocation data.

Sunday, October 9th, 2022

Descriptive engineering: not just for post-mortems – Dan Slimmon

I wrote a while back about descriptive and prescriptive design systems—and a follow-up post—but I didn’t realise there was such a thing as descriptive and prescriptive engineering.

Tuesday, October 4th, 2022

Style with Stateful, Semantic Selectors

I’ve done this quite a bit: using ARIA attributes as “hooks” for styling and behaviour. It’s a way of thinking of accessibility as the baseline to build upon rather than something that can sprinkled on top later.

A Web Component Story

I get it. React feels good and it’s sticky. But all frameworks eventually fizzle out.

Thanks to Web Components, large companies are realizing you don’t need to rebuild buttons and other UI primitives every few years. Teams don’t need to argue about frameworks anymore. You can have your cake and eat it too!

I think this may be the best long-term argument for web components:

Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.

Wednesday, September 21st, 2022

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.

Wednesday, September 14th, 2022

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.

Sunday, September 11th, 2022

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.

Tuesday, September 6th, 2022

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?!

Tuesday, August 30th, 2022

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

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

Wednesday, August 24th, 2022

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).

Thursday, August 18th, 2022

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.

Thursday, August 11th, 2022

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.