Drew Powers10 things I’ve changed my mind about regarding #WebDev over the years. May change my mind again, who knows.
1/ JavaScript isn’t *that* bad. Yes, yes, I know. Addy Osmani. Alex Russell. Progressive enhancement. Islands architecture. But collectively we’ve gotten it wrong multiple times what the internet is *for* and how people *want* to use it. People want interactivity. Sure, static documents will always be a part of the web, but it’s not so bad having simple LLM interfaces that *actually understand you* and answer your question 100x faster than a gamified, ad-ridden website with horrible IA.
Alex Russell@drwpow Why do you imagine that the point of my advocacy isn't to make space for the truly valuable things, at the expense of the stuff that isn't pulling it's weight?
I'm never going to tell you "don't make a rich experience", I'll only ever challenge if the juice is worth the squeeze.
@slightlyoff ha sorry—too few characters to express nuance. Was more written to people who take some of your words out of context and flatten it into a DELETE ALL THE JAVASCRIPT!!!!1! over-simplification (and I myself have swung too far in the “you don’t need JS” direction to where I actually think I degraded the experience for people in a negative way)
very normal person@drwpow @slightlyoff
I look forward to your other tips Drew as an amatuer webdev... and not to derail your thread further, just want to say yes, being dogmatically anti JS is a mistake. I was very much on the NOJS train, yes i think javascript has valuable use cases but often it's overused etc. i like VanJS for example. P
To my understanding Progressive enhancement just means the site should have basic functionality without javascript -- and there isn't a technical reason why you can't Post, Search etc. without js. There are also many cool things you can do with HTM5/CSS3 instead of Javascript in terms of basic interactivity ( hiding and opening divs, theming etc. ) and then you can use JS for more pressing concerns like smooth real time updates.
I look forward to your other tips Drew as an amatuer webdev... and not to derail your thread further, just want to say yes, being dogmatically anti JS is a mistake. I was very much on the NOJS train, yes i think javascript has valuable use cases but often it's overused etc. i like VanJS for example. P
To my understanding Progressive enhancement just means the site should have basic functionality without javascript -- and there isn't a technical reason why you can't Post, Search etc. without js. There are also many cool things you can do with HTM5/CSS3 instead of Javascript in terms of basic interactivity ( hiding and opening divs, theming etc. ) and then you can use JS for more pressing concerns like smooth real time updates.
@mook I mentioned progressive enhancement just as a nod to the argument that you can ship a JS-free version and a JS-enhanced version of a website (at least in its original form). I don’t see having JS-required sites as a bad thing anymore, since many things need JS to work (like comboboxes! and calendars! and context menus). If you’re mindful of budget and get creative, it’s possible to do one JS version better than two half-finished versions (not always of course, but often)
@drwpow right, i see what you mean
JS isn't inherently evil, it's a good language that has been mistreated, i am on sharkey because of the webUI which is basically pure javascript ( i think the backend too) javascript is a solid language it's build for webdesign and can do anything in a javascript webapp like a client for matrix or a terminal emulator etc. how could that be bad?
But there's also lot of times like with a wiki or blog, plain html4 is more appropriate, less bandwidth, more accessible etc., and i think there is a trend in corporate webdev to throw React on everything and load an absurd number of libraries, ( and trackers) you can do a lot with a little in javascript and ad driven web design abuses this
i'm actually working on doing a pure html5 calendar, basically have php print out an xcal file with xslt, so there are ways to do thinks that don't involve javascript that i don't think have been tried extensively, but with things like dynamic css3 using "hacks" with psuedo classes can be inconsistant across browsers, not accessible etc. and a lot of this is uncharted from what i can tell
JS isn't inherently evil, it's a good language that has been mistreated, i am on sharkey because of the webUI which is basically pure javascript ( i think the backend too) javascript is a solid language it's build for webdesign and can do anything in a javascript webapp like a client for matrix or a terminal emulator etc. how could that be bad?
But there's also lot of times like with a wiki or blog, plain html4 is more appropriate, less bandwidth, more accessible etc., and i think there is a trend in corporate webdev to throw React on everything and load an absurd number of libraries, ( and trackers) you can do a lot with a little in javascript and ad driven web design abuses this
i'm actually working on doing a pure html5 calendar, basically have php print out an xcal file with xslt, so there are ways to do thinks that don't involve javascript that i don't think have been tried extensively, but with things like dynamic css3 using "hacks" with psuedo classes can be inconsistant across browsers, not accessible etc. and a lot of this is uncharted from what i can tell
Giorgio Maone 🚫✊🧅@drwpow @mook ironically you mentioned 3 things (combo boxes, calendars, context menus) that can degrade gracefully and still look gorgeous with just some CSS cleverness. Then if your web APP (not site) offers me a killer feature which really require JavaScript (e.g. it's some 3d or VR game) and you can convince me that you (and your 3rd party dependencies, which should still be avoided/self-hosted as much as possible) are trustworthy enough, I will set your domain to (temporarily) TRUSTED in @noscript (yes, extremely biased POV😅).
@ma1 They actually DON’T degrade gracefully when you factor in a11y! The native datepickers built into browsers aren’t accessible. Comboboxes need HTML attributes adjusted on what’s actively open and highlighted. Filtering must be done in JS. You actually NEED JS to pass WCAG 2 with these controls. It only degrades to a semi-working state for non-disabled users.
@drwpow I'm no accessibility expert, but that really sounds like either a web standards or browser vendor implementation bug, to be reported and fixed.
Anyway, here's someone seemingly better equipped than me arguing for the a11 superiority of HTML-only <input type=date> over custom JavaScript date pickers: https://www.digitala11y.com/input-type-date-the-accessibility-of-html-date-picker/
@ma1 I do work with accessibility on a regular basis, and this is a well-known issue. It already has been reported, but as you know browsers aren’t always the fastest to fix things.
Also that article says “<input type="date"> is usually better than custom widgets” and I don’t disagree! But they *don’t* pass all requirements yet, and my original comment still stands.
@drwpow I agree that browser vendors are not the most responsive bunch, but those tests are really ancient (Firefox 80 and Chrome 92, really? https://a11ysupport.io/tests/tech__html__input__input-date#versions)
Have you got any more up to date information?
Any FOSS progressive widget enhancing JavaScript shim which passes all the a11 tests?
If that exists, I might volunteer to statically include it in @noscript and in the @torproject Browser as a fallback for users who disable scripting.