Does anybody else feel like they're relearning web development?
-
Does anybody else feel like they're relearning web development? Once you decide you wanna get off the The Frontend Treadmill, you realize you need to completely reorient your process for building web sites and applications. I think all of the tools and practices that you reach for need to change pretty significantly. It feels like starting over.
https://polotek.net/posts/the-frontend-treadmill/ -
Just as an example, I find that I can't even get started in the same way. For a long time now, setting up a new project meant installing a build chain. Webpack, create-react-app, esbuild, vite. Whatever thing is in fashion at the time. But the first thing you do is make a bunch of assumptions about your development environment.
But what we're realizing is that those assumptions lock us into a particular path. And we're realizing that we may want to have other paths available to us.
-
But once you decide "I'm not gonna install vite", you're left with a pretty big void. What do we do instead? What's the way to start a project after you've made the key decision that you're going to stick close to web standards and low JavaScript solutions? And how do you set things up so that you can thoughtfully expand into js solutions in the future as needed, but without making a mess of things?
-
Also, CSS is completely different than it was even 5 years ago. I feel like I'm relearning it quite literally. All of the syntax and constructs are familiar. So I'm not starting from scratch. But I wouldn't solve anything in CSS the same way we used to solve it 10 years ago. There are way better tools that are less hacky and more performant. But we're gonna have to learn them.
https://social.polotek.net/@polotek/113012077825811153 -
I suspect that getting off the treadmill also means committing to revisiting all of the development practices we've so painstakingly developed over the last 5-10 years. That's going to suck.
If I was putting my manager hat on, I would say that we need to see this as a choice invest in a better future state. Because what I'm realizing is that in the short term, this transition is probably going to feel slower and more costly than the status quo.
-
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.