Does anybody else feel like they're relearning web development?
-
This is not a small thing. It's actually huge. Because even as we convince people that the current path is the wrong one, we have to contend with what it costs to change course. It means real, hard business conversations about when and how to pay that cost.
-
For the record, I believe bundle and minify are still best practices in my mind. But I do think there are significant details that can shift. I think we're talking more about what JavaScript we're delivering in the bundles.
I don't have strong recommendations yet. This thread is me realizing that I don't. But I will say that @b0rk convinced me that esbuild is simple and has nice defaults.
https://social.polotek.net/@polotek/113023708030620405 -
That's accurate. But it turns out that's what 20 years of experience has always been.
Just as an analogy, the years learning and building flash weren't wasted. We built cool stuff and we learned a lot about what experiences people wanted. But moving away from it was also the right thing.
After 20 years, what we develop is good judgment about which solutions are actually delivering *the value we need* and which are not.
https://follow.ethanmarcotte.com/@beep/113023744809114470 -
What did we learn from Flash? So many important things!
Security is paramount. We realized that we just could not keep up with the attack surface area that Flash created.
Accessibility matters. Flash created incredible experiences that a large portion of our users just could not access.
Maintainability matters. Handing off a complex Flash app to another dev team was next to impossible. Everything was so bespoke, there was no version control.
-
Modern frontend frameworks look and feel very different from Flash. But I would argue that when we step back and evaluate our needs using our judgment, we can see a lot of the same challenges. Security, accessibility, and maintenance are all a nightmare in this current ecosystem.
-
Anyway, the reason I'm thoughtful about this today is that people keep asking me what we should do. And I have to be honest with myself that I haven't done enough work to have strong recommendations yet. So I need to do that. We all need to do that. Then we need to share what we're learning and collaborate until it takes shape.
-
@polotek @b0rk I still think that with ESM now being universal, and data getting sent with gzip/brotli compression already, neither of those make sense anymore. They were crutches from a pre-module era, and both broke browser caching. Let the server deal with compression, and the browser with caching individual files.
-
@TheRealPomax @b0rk I think this is a reasonable stance. But we can't just say "I think". If you want to do the work of studying and proving this out, I'm sure people would appreciate it. More importantly, giving people more guidance about caveats and pitfalls. We see what happens when we give people incomplete advice and then leave them to figure out the rest of it on their own.
-
Heather Migliorisireplied to Marco Rogers last edited by
-
Marco Rogersreplied to Heather Migliorisi last edited by
-
@polotek Personally, I attribute a lot of this to a lack of build systems. Web developers are used to a single CLI tool that "does all the things" (build, serve, test, scaffold, etc.). So moving away from one piece moves away from all of it.
If developers were comfortable using a build system to orchestrate these tools independently, you'd be able to much more easily pick and choose the tools which matter for you.
This would allow workflows like TypeScript -> bundler -> devserver / test runner without having to pull in an entire framework or buy into a plugin ecosystem where everything is coupled together.
Just pick the tool you want and stick it in your build system where you want to use it. No weird setups, plugins, or integrations.
-
@develwithoutacause sounds great. You should get started.
-
@polotek What does it say about us that we made the same mistake again? Perhaps, what we really need to rethink is the way we systematically approach development as a whole. No?
-
@polotek a lot of this work is happening, but we need to be honest about the fact that there’s no silver bullet for web UI. Sometimes HTMX is the best fit, sometimes React or Vue might be. Or Svelte or Lit. We don’t need a single “winner.” We do need to stop cargo culting UI tools, hiring based on narrow framework experience, and start talking more about trade-offs.
-
@polotek I had a strange interaction at work where I asked that an internal package that was being published as uncompiled TypeScript instead be published as a real JS module. And I got heated pushback on this! The response was, "all apps have a build system, so why not?". We're at a point where not only are build steps assumed (which is fine) but *specific* build steps are assumed, and few people care if the output can run as-is in any JS runtime.
Web dev is in a real bad place.
-
-
@polotek something I struggle with is "finding modern documentation for the non-expert". The search space is so polluted with history and dead ends that I'm at a loss for how to start learning modern css and web application development.
-
@konnorrogers @polotek I feel like we can specifically blame Node for this for refusing to admit that CJS is not a valid JS module system.
Anyone suggesting that CJS isn't ruining JS at this point should be tasked with explaining JS modules to somebody who has only ever worked in another language. See what they think when you have to explain there are two module systems, one of which is in the spec, but everybody writes in a non-standard pseudo module system for "compatibility".
-
@bcdavid @konnorrogers commonjs was a very valid and successful module system. But it was designed specifically for node. I remember several people suggesting that it may be a bad idea to adapt it for browsers. But you can't stop people from trying every idea to find out for sure if it's bad. So here we are.
-
@offby1 I would look at books or courses before just doing searches on the internet.