Comment by austin-cheney 3 hours ago
Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser.
I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.
React made reactivity popular. Web components don’t give you reactivity. You still tell the UI how to update based on state changes imperatively and that is annoying as hell.
If you want reactivity in web components, you need a wrapper or another framework/small library.
I disagree. It’s actually the same effort either way, but one of those costs substantially more to maintain and performs far slower.
We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.
> I promise writing applications for the browsers is not challenging.
Yeah it is. I don’t like React but I’ve been doing this since the days of MooTools all the way through Backbone to the libraries we have today. Once your app reaches a certain size and/or reaches a critical mass of contributors it does get challenging and modern frameworks reduce that challenge.
That can be taken way too far. Almost every time I’ve worked with Redux I’ve found it infuriatingly unnecessary. And React is far from the best framework out there. But it is a huge benefit all the same.
You don’t need big frameworks or component madness that’s more of the same.
You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard.
If there are more than a couple of developers on the project it'll be something no one really likes after a year or two.
If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join.
Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.)
This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.