I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.<p>I don't have experience with all of these technologies but have been using React since its inception, and let me tell you, there is no amount of (reasonable) money that would make me want to go back to the times when jQuery the big new thing. It was awful! Procedurally manipulating the DOM! I mean, c'mon guys. Talk about a mess... Where are all of the FP evangelists when you need them?<p>And I know someone out there is bound to downvote me and respond with something like, "B b b but that one site where it downloaded 300kB of JS for a landing page! It's such a bad user experience!". Sure. That's precisely what I'm talking about /s.<p>The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually <i>reason</i> about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense.<p>I get it. It makes web pages a bit slower, and sometimes (maybe more often than that) get abused. That isn't fun for anyone. But level the critique at the idiots downloading a MB of JS to power a single dropdown, not the tool managing that dropdown's state.
<i>The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo.</i><p>No.<p>The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity.<p>Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today.<p>An alternative solution is to go back to the true traditional approach & address the interactivity issues <i>within</i> that architecture (REST/HATEOAS).
When I'm pressed to oversimplify, I usually respond with "A React component is basically a function that takes a set of parameters and spits out HTML, and can react to changes in those parameters and update said HTML. The rest is implementation detail."
So I can't discern if React is a loved or hated technology (also it doesn't have to be binary). At the company I was working at the front end devs brought in React and were super excited about it, but reading a couple comments in here it seems like people have some reservations.<p>I haven't invested the time into as I don't have a use case but I keep hearing about and now get the sense it isn't necessarily worth looking at until i have a needed case.
Just skimmed through it, but this looks like a great intro for non-technical folk. I'll be saving it for when people ask me for resources into getting into frontend dev.
Thanks for sharing your illustrations but this site/page is an effing CPU/GPU HOG!!!!<p><a href="https://imgur.com/9Pi1rBa" rel="nofollow">https://imgur.com/9Pi1rBa</a>
Have you tried developing a doctors appointment website with React (or any SPA frameworks) say Django or Flask? It's a pain in the ass. Usually, you throwaway all the cool things about Django and turn it into a stupid JSON API and then you build a bunch of cruddy shit with npm tooling and cry yourself to javascript dependency hell. Then you need another server to serve up this bundle.js and a barebones index.html file. Great if you're building a Google Docs competitor. 99.999% of the people aren't.<p>I think VueJS is excellent and surprising to see React's popularity. Vue can be used just like jQuery without any nodejs tooling. Just like every discussion about this topic, React fanboys will respond with "But, technically, you can do that with React too" [1], yeah... It sucks at doing that. Without JSX, you can't interweave for example Jinja2 templates + React. Nor can you interweave JSX + Jinja2. With VueJS? It's just HTML with a few v- attributes. Even if React worked well with direct script tags in HTML, it still sucks at it because it's mainly designed for SPAs in mind. There is a lot of existing discussion on this topic [1].<p>I absolutely abhor the tooling/npm/babel/nodejs/webpack all this nonsense that Javascript frameworks need. They should be sort of like jQuery - no prebuilding steps - just drop and play. A doctors appointment website doesn't need to be an SPA. VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.<p>Oh btw, Svelte is yet another one - of course its SPA framework (Good luck trying to make it work on an MPA website). I am completely underwhelmed by Svelte, and ofcourse the JS peeps are flocking to it. :|<p>[1] <a href="https://news.ycombinator.com/item?id=24520116" rel="nofollow">https://news.ycombinator.com/item?id=24520116</a>