Small companies are addressed indirectly in my second paragraph. Even if you have a small company or a small team, they still need full-stack experience. Documentation for frameworks like React is already very mature, so I don't think it is a problem. The scope might be slightly larger, but getting a React stack going nowadays can be done with a single command, and maintaining it has not been an issue for my team of mostly backend engineers: we are able to manage a few UIs in React for our tools without any problems. I would say the additional complexity introduced by React has been minimal, the team likes it, users like it, and the experience was pleasant enough to win me over.
Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed.
I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming, and by adopting it, I gain the flexibility to handle new use cases like integrations with other APIs, integrations with other frontends, and CLI tools right from the start. A proactive approach means I don’t need to revisit and rework the application later.
Not sure how the entire npm/react/SPA ecosystem can be described as stable when it's so many moving parts that it's almost a running joke. Latest I've seen is going full circle into the server-side again and some kind of a compiler?
> I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming
SPA UI frameworks are not particularly time-consuming? Then we have very different views on productivity.
Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
Because reality is often different from the running joke, the latter usually being an exaggeration for comedic purposes. If you constantly chase the latest and greatest frameworks, then yes, you’ll find yourself frequently rewriting your application over and over again. This applies to any technology, and it's especially common when less experienced engineers focus on the technology instead of the goal. Take PHP, for example - despite the jokes about it being obsolete and a horrible language, many developers find it effective when used correctly. I would agree with them. There are perfectly valid use cases where PHP is an excellent choice.
Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
Sure, but we are not paying a higher price in the name of proactivity, instead we are getting it as a bonus. As I said before, the maintenance cost has been negligible for us. Implementing and maintaining a React stack has not introduced significant overhead, the developers like it, the users like it, and we are happy with it.
