Stuart Langridge

(if you don't know the author, he's a web evangelist, working previously for Mozilla, now for Microsoft; now you can understand his frustration, in the times of recent Chrome monoculture in the web)

I wholeheartedly agree with the author and wanted to post another long rant here, but I resisted the temptation :)

In this particular example of a WebGL demo, I think it was not exactly malicious, the issue was IMO most probably due to writing non-future-proof code, and then abandoning it (there was a related post last week about writing non-future-proof Python code that will break in python4, same applies here). Lots of early "HTML5" demos do not work anymore because they used some not-yet-standardized and/or prefixed syntaxes that have changed since etc.

Anyway, the link to [1] is very interesting. Many people underestimate the risk of third-party JS server going down (or being slow), adblockers preventing some JS from executing etc.

Edit: to clarify, I don't mean you should not use JS (heck I'm a JS developer, and IMHO the times of "progressive enhancement" are long gone, unless you serve almost only text content). I don't mean you should have 3 redundant servers to serve your JS from; just detecting that the thing didn't load, and not making assumption that it will be reliably delivered to the user in 0.1 s, would be good enough. There are pages out there that will totally break or fail to load if some non-important JS file is not loaded due to a network issue or whatever…

> makes sense to do

Do you use the pointer that fopen(3) returns without checking for NULL? Progressive enhancement is mainly error checking and handing failures gracefully.

> not willing to turn it off when the site doesn't work without JS

Why are you willing to make your business look shoddy and unprofessional? Running without javascript has always been an option, and always will be. Anyone that doesn't run the javascript obviously isn't expecting fancy features, but you should still show any text/images (or a basic form if that is relevant), probably along a suggestion that turning on javascript will probably improve their experience.

> changes necessary to have this progressive enhancement

That's the point - this shouldn't cost a lot, unless your tools are unusually braindead. Rails made progressive enhancement almost entirely transparent a long time ago. I believe there are several prerender-the-first-load plugins for several popular frameworks. If your tools aren't doing this for you (either automagically or otherwise), then those tools are missing important features.

> work culture changes

It is probably a good idea to pay any technical debt sooner, instead of tying even more projects to bad tools.

> users who use NoScript

NoScript users are NOT[1] the only group that will see your pages without Javascript. You don't control the client, which will always be unreliable.

Also, progressive enhancement isn't a boolean value; you should be checking for the…

I have to admit I get very disappointed when I see new form abstractions that don't take this seriously — especially if they make bold claims like 'the new paradigm'!. The whole point of forms is that they're part of HTML. You should not need JavaScript to submit a form, period.

I think about the woman in this story — https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/ — as an industry, we've lost our way if we don't care enough about people like her to make our apps work reliably. Not everyone has JavaScript: https://www.kryogenix.org/code/browser/everyonehasjs.html

Moreover, validation is something that belongs on the server. Client-first approaches to form validation are at best duplicative (because you need to repeat the validation on the server) and at worst dangerous (because it tricks you into thinking that's unnecessary).

I also notice that one of the first forms on your website doesn't adhere to common accessibility guidelines — the email field is marked invalid as soon as you start typing. Ordinarily, you shouldn't validate a field until it has been blurred.

So what I'd like to see from people building form abstractions is a) a full stack approach, b) progressive enhancement, and c) adherence to accessibility guidelines.

FWIW this is how we think about forms in the Svelte project: https://svelte.dev/docs/kit/remote-functions#form

This seems like a well done talk, but part of me is tired of the same information repeated again and again in different forms. I feel like I’ve already seen [0] [1] [2] this talk about 15min in. Details tag, input validation attributes, the dialog element etc.

It’s a good message (look at these platform features!) but rarely am I seeing people that are surprised by the existence of the details accordion tag any more.

Comically I guess the <details> tag they’re (and myself is) familiar with is usually wrapped in an Accordion react component with the open close state saved in a hook, so maybe we haven’t learned.

[0] http://youmightnotneedjs.com/

[1] https://www.kryogenix.org/code/dont-need-that-js/

[2] https://javascript.plainenglish.io/sometimes-you-dont-need-javascript-at-all-73a6a226a1c3

Earlier this year I got a ReSpeaker mic for video conferencing, and it's been working great! I did have to upload the latest firmware once I got it. I then combined it with NoiseTorch for a basically perfect video chatting experience.

NoiseTorch detects speech and mutes the mic when you aren't speaking. I had tried Hushboard, which mutes the mic when you are typing, but sometimes I talk when I type. ReSpeaker is a microphone array, and it has a speaker output and can do noise cancelling on the mic from what is sent to the speaker. It was about $60.

https://www.seeedstudio.com/ReSpeaker-USB-Mic-Array-p-4247.html
https://github.com/lawl/NoiseTorch
https://www.kryogenix.org/code/hushboard/

I literally paused reading when I read this simply put exact statement. I try to focus on minimal, simple apis and preach it to developers and clients for quick integration and maintenance. Now I have this powerful statement to save hours of explaining mainly to non technical people. I have always thought this but never so crisp and to the point. We need t-shirts. Doing a quick search of Google, it appears a few others have recently stated this as much but it is an idea that should take hold: http://www.kryogenix.org/code/apis-like/