React Is the New IBM (2023)
21–30 of 49 posts
Re: React Is the New IBM (2023)
#22I see the point but I think the article is overplaying its hand. Sacrificing performance for a cleaner programming model is a reasonable tradeoff, it's weird that it's being criticized as though it were a matter of principle. I'm very much a backend person and I don't like React either -- as far as I'm concerned raw HTML on a webpage as God intended peak UI -- but if you're writing full webapps you're going to need s…
It's just a fairly lengthy fall into a trap that many, many programmers fall into: detaching their craft from the business purpose it serves. A webpage rendering Xms faster has negative value if it e.g. took 3 months longer to hire the programmer responsible for writing it, or if that programmer costs $100,000/yr more, or if training them to proficiency took 6 months, etc etc. The advantages of well-known frameworks…
Amen. This is the classical principal/agent problem and affects everyone all the time, not just programmers. But the amount of disregard for the overall business goal can be astounding.
Re: React Is the New IBM (2023)
#23Dismissing a compiler improvement is weird. Facebook has presumably millions of lines of React everywhere. Legacy tech is a thing, and most tech is legacy. Usability and familiarity matter. The tech is a collateral of the business, and it doesn't matter as long as it works. Compiler "hack" or not, the business doesn't care, the business is about revenue and maintenance burden.
Re: React Is the New IBM (2023)
#24Re: React Is the New IBM (2023)
#25IMO, React repeatedly nerfing external stores and encouraging users more and more to shove their application state into React components has exposed what a poor model of reactivity React actually offers.
Re: React Is the New IBM (2023)
#26Also, I doubt too many front-end apps will have the long lives of the COBOL code that runs on IBM mainframes.
Re: React Is the New IBM (2023)
#27For such an article, I would expect the author to spend some time talking about their real-world experience with React at scale.
> Much of the innovation in the UI space is now happening around the edges of the React ecosystem: Solid.js, Preact.js, Svelte.js, Vue.js, Astro.js, Qwik.js, Marko.js
Similar problem, the author suggests a bunch of libraries based on features rather than problems and solutions.
Re: React Is the New IBM (2023)
#28Earlier quoted context omitted.
It's just a fairly lengthy fall into a trap that many, many programmers fall into: detaching their craft from the business purpose it serves. A webpage rendering Xms faster has negative value if it e.g. took 3 months longer to hire the programmer responsible for writing it, or if that programmer costs $100,000/yr more, or if training them to proficiency took 6 months, etc etc. The advantages of well-known frameworks…
> detaching their craft from the business purpose it serves Amen. This is the classical principal/agent problem and affects everyone all the time, not just programmers. But the amount of disregard for the overall business goal can be astounding.
Re: React Is the New IBM (2023)
#29What's much more difficult at scale is doing this without React.
In the old days when building a complex front-end web app, your app would slowly devolve into complex web of event handlers changing the DOM, and you'd eventually arrive at the conclusion that you'd eventually arrive at the conclusion that centralizing state and triggering UI updates based on those changes was the only sane thing to do. And then you'd end up either: 1) re-rendering the whole DOM on ALL state changes -- which came without its own set of problems of which performance was just one, or 2) manually hooking up callbacks to change pieces of the DOM as the relevant pieces of state changed -- which was only slightly less of a nightmare to maintain then the event handler spaghetti you were coming from. Also another dev your team would always just hook up and event another event handler to change the DOM somewhere, and ignore your state entirely.
React actually made this both much more performant and much easier to maintain.
If you aren't building a complex web app with a lot interconnected interactions and state changes, you don't have to use React. If you are, I encourage you to build it with jQuery, and look forward to your follow up blogpost.
Re: React Is the New IBM (2023)
#30I see the point but I think the article is overplaying its hand. Sacrificing performance for a cleaner programming model is a reasonable tradeoff, it's weird that it's being criticized as though it were a matter of principle. I'm very much a backend person and I don't like React either -- as far as I'm concerned raw HTML on a webpage as God intended peak UI -- but if you're writing full webapps you're going to need s…
It's just a fairly lengthy fall into a trap that many, many programmers fall into: detaching their craft from the business purpose it serves. A webpage rendering Xms faster has negative value if it e.g. took 3 months longer to hire the programmer responsible for writing it, or if that programmer costs $100,000/yr more, or if training them to proficiency took 6 months, etc etc. The advantages of well-known frameworks…