That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.
I always see this as a communication/management failure.
Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.
A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.
The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
> The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with technical (e.g. tech bloat) limitations in mind feels important only to technical people and not to actual computing.
If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.
> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute?
> Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I mean, according to which metrics? Again this is really popular on HN and other nerd forums but from what I can tell it's just a nerd forum indicator. I think you can make a decent case for involving tech and product together, and I can think of many, but it's a case-by-case basis and has nothing to do with degrading customer experience. This view is popular on HN because we don't actually care here much about actual customers and care more about things like "site payload" and "how much JS is running in my browser". If the argument is that people with older devices won't be able to run the JS like this, I'd argue that your networks have more latency than any bloat you get from JS. Which is why a holistic experience matters more than what your personal tech-experience gets hung up on.
From my experience I don't think product and management folks care much about the user experience either; it seems to be mostly ego and dick-measuring.
My target user is someone running 3G on their phone on the commute home in a crowded train. The designer's sexy animations and carefully coordinated state changes are not worth the extra 100Kb of 3rd-party dependency JS required to get them to work, because the user is not going to see them; they're going to switch away from the app after 10s of staring at a blank page waiting for the JS to download.
Seen too many "perfect" designs on a laptop monitor right next to the router in the dev studio fail completely in the wild. Every Kb matters.
Unless you have anything more than anecdotes and feelings to contribute to this discussion, I don't think there's anything more to discuss. Data makes a more convincing argument for such bold claims, especially when a minority of practitioners claims that their way of doing things is more correct than a much larger majority. I will say, from your maligning of "product and management folks" to your anecdotally-driven interest in page weight, its like every dev stereotype ever.
