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.
2/ Frontenders *should* learn design. CSS only gets better and better in my eyes, and has aged like a fine wine. But to understand it, you have to think like a UI designer. Not tryna gatekeep here—anyone can learn design! Anyone. But put the time in if you want to really understand CSS.
3/ Design is actually kinda bad at solving problems outside the domain of design. Designers trying to put themselves at the head of the table, and be the bottleneck of the entire org by being the central problem-solvers just didn’t work out well. By the numbers, it hasn’t gone well. By most sociology experiments of how people collaborate, it’s not designers that have solved the world’s problems. Many ugly things never blessed by a designer work incredibly well.
4/ Accessibility is core to the internet. If you’re not making experiences accessible, don’t even bother. The internet is better without your content black box.
5/ Just load 1 image size everywhere. On desktop, you load the big image. But mobile is physically really tiny and PEOPLE NEED TO ZOOM. And they end up needing the big res anyway. 99% of you are too lazy to upscale images on a zoom gesture. So just load the 1 big image. Let Lighthouse complain. And before you @ me, USE BETTER IMAGE COMPRESSION LIBRARIES. sharp is NOT image compression; I’m talkin bout the real shit (sqoosh, ImageOptim).
6/ Open source everything you make. Everything you’re allowed to. We need this. The world needs this. If you’re unhappy about the direction some part of webdev is developing in, open source your way out of it. No, you won’t “open source it later.” Start open or it’ll never happen.
7/ Stress over speed. Speed is time. Time is the most valuable resource we have. Choose tools based on speed. Software can be bad just because it’s slower than it needs to be. Throw it away. Rewrite it in Rust (jk don’t rewrite it in Rust lol). Future you will thank you.
8/ Fragmented ecosystems are patterns to encourage, not fret over. It’s in everyone’s best interest if we have too many frameworks and too many languages. It just means we’re exploring more potential paths together. You ever see slow motion of lightning—how it traces out thousands upon thousands of branching paths till it finds the path of least resistance? It’s kinda like that.
9/ Don’t finish everything you start. Life’s too short and if you’re not getting paid, do what makes you happy.
10/ TODO
Ricardo Tavares
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.
@drwpow Also, counterpoint:
Reckoning: Part 2 — Object Lesson
SNAP benefits sites for more than 20% of Americans are unusably slow. All of them would be significantly faster if states abandoned client-side-rendering, and along with it, the legacy JavaScript frameworks (React, Angular, etc.) built to enable the SPA model.
@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)
@drwpow Well, if there's an argument about which instinct is *directionally* correct in the context of 2024 webdev dogma and practice, I know which oversimplified version I'd pick.
But with you to the extent that what you're actually preaching is "moderation in everything". That's also my message.
@drwpow Like, you literally can't square me leading Project Fugu or the design of Service Workers or a decade on TC39 with "never JS", unless the argument is that I've had an undiagnosed aneurysm 😅
There's a budget. It's closer in than folks realize, and that means we need to spend it better. That's not "delete all the JS", not by a long shot.
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.
Benny Powers 🇮🇱🦁@slightlyoff reminds me of the "you can't use web components 👉 you can't use shadow dom 👉 you can't use dsd 👉 you need to use my framework" treadmill
Bèr Kessels 🐝 🚐 🏄 🌱@drwpow I presume you mean "interactivity through software on a webpage" and not "JavaScript, the language"?
Because I'd strongly argue that JavaScript is one of the worst languages out there. It's an abomination. With modern improvements at most plastering over some of the worst parts of that language. Hardly making it better, but rather making it less bad.
@berkes Eh I meant both. Modern TS is pretty good. It ships, it can be performant enough for the widest range of general programming, and the tooling is fast and mature now. To each their own, to point 8.
@drwpow for sure! modern TS solves some issues - it plasters over some ugly parts of JS.
But it still carries all the legacy/bad parts of JS.
It fixes type coercion and the dynamic typing fu. But it doesn't -cannot- hide the horrors of Numbers, the insane API of e.g. date and errors. The identity crisis of not being FP, nor OOP, but all of it and none at the same time.
I've been bitten far too often by issues stemming from the (lack of) design in JS/TS (and ofc also, by me being a moron)