Does anybody else feel like they're relearning web development?
-
@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.
-
@shiftingedges I think you have the burden of pricing that we need this meny solutions. We don't really see other UI platforms with this much "choice". Yes I know there are some key differences with the web. But that doesn't mean we should accept it at a given that it has to look this way. Especially when we can also talk concretely about what it's costing us.
-
@sherlock_holmes it's not the same mistake. History doesn't repeat itself. It just tends to rhyme.
-
@polotek @konnorrogers JavaScript has one valid module system. We can go back and forth all we want about the history, but the spec has one module system, and large players in the ecosystem refusing to focus on that module system is damaging to the language. Nobody outside of the JS bubble cares about the history, they will all just be confused why they can't use the standard module system consistently.
-
@bcdavid @konnorrogers cool. Then since you have it all figured out, feel free to leave me the fuck out going forward. Cheers.
-
@polotek @redcrew once upon a time, css was my favorite thing, even though I did mostly php. Then I looked away for a few months and when I looked back it was gone. Instead were scss, sass, grunt, gulp, and a myriad of other things that didn’t make any sense at all. I haven’t written serious css since.
-
@topher1kenobe @redcrew what's interesting is that we did get pretty far down a bad path with css. But the good lessons we learned there have made it back into the language proper. And we've successfully enabled a path out of that. It was worth the detour, but we didn't stay there like we have with js.