47 ms·

The self-fulfilling prophecy of React

• jgwil2 4y ago
  One criterion the article omitted was portability: I haven't followed React Native for a few years but I imagine a lot of people want a framework that will allow them to share code between mobile apps and web apps.
• sonicgear1 4y ago
  Liking and defending React is borderline Stockholm Syndrome at this point.
• DecoPerson 4y ago
  Eh, this article is wrong right off the bat. “React isn't great at anything except being popular.” When the rubber hits the road, React is good. There’s a hundred thousand tiny little facets of its design that all contribute its effectiveness in getting functional (as in operationally successful) results. I’m no React fanatic. I hate the bundle sizes, the weird quirks with hooks, the footguns with performance, etc etc. But it works, and the results speak for themselves. I recently hacked for two weeks on React, Node and React Native to produce a CRUD app for Chrome and Android. It’s no FAANG app, being hosted locally for the site that needed, no localisation, ugly code, barely optimized… but it works! It has served its purpose well with minimal bugs for months, saving potentially thousands of hours of tedious labour. With React, I can prototype and get results fast. I’ve tried Vue, Angular, Vanilla, Blaze/Meteor, EmberJS, and even tried my own custom framework based on MobX. None were as good for getting results. For a bunch of little reasons, React is just… really effective.
  • boffinism 4y ago
    The sentence immediately after the one you quoted was: "Don’t get me wrong: React is good". So dismissing the article on the grounds that 'React is good' doesn't get you very far.
    • aeternum 4y ago
      React is good enough. And using a framework that devs are already familiar with is grossly underrated. Sure good devs can learn any language/framework, but there is a learning curve and most write shitty code while unfamiliar with a framework. Popularity is an important feature.
  • xani_ 4y ago
    >Eh, this article is wrong right off the bat. > “React isn't great at anything except being popular.” So did you stop reading the rest of the article after you hit that sentence or what ?
    • bayesian_horse 4y ago
      In my opinion React is "great" at a lot of anything, besides being popular. The original author makes the point that other frameworks are greater, and I don't agree with the unqualified nature of that judgement. React is really effective. And that makes it "great" in my book.
    • DecoPerson 4y ago
      The article is arguing that companies keeping using it and devs keep learning React because it’s popular and a “safe choice.” I’m arguing that they keep choosing it because it’s effective and markedly more effective than the other choices currently available.
      • apd_ 4y ago
        In which way is React more effective than say Svelte?
        • Robin_Message 4y ago
          React Native
  • pc86 4y ago
    You're basically agreeing with (and summarizing) the article, so I'm not sure what exactly you think the article is wrong about?
  • woojoo666 4y ago
    Any examples of places you think React's design does better than say, Vue or Svelte?
    • bayesian_horse 4y ago
      In my opinion, two-way bindings are evil...
      • jesuscript 4y ago
        For simple inputs it’s fine. What are really solving by methodically doing that one-way?
        • Marazan 4y ago
          Two way data bindings works in the absolutely most trivial case. As soon as you go any amount of complexity higher in your program two way databinding is pure poison. Two-way databinding is the absolute very worst feature people took from Flex.
    • wokwokwok 4y ago
      I had the unfortunate job of learning vue recently and it sucks hard at some edge cases. Specifically, imagine you a component that takes an arbitrary node to render. Just pass the node to the temple right? Ha. This api sucks -> https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html Compared to having “{node}” in react.
      • eyelidlessness 4y ago
        They are almost literally the exact same API. Prior to the “automatic JSX transform”, they were basically identical. That’s how both libraries support JSX, which isn’t always exactly a mapping to h but is almost totally in both React and Vue (and Preact, and even in Solid if you ignore recommendations to use its custom JSX transform). The API you’re criticizing is specifically good because it enables what you prefer in React.
  • otabdeveloper4 4y ago
    You know what else works? HTML <form>. And I guarantee you 100 percent the <form> is miles ahead of your React "app" in internationalization, accessibility, performance and portability.
    • Tomuus 4y ago
      Using the Web Platform and using React are not opposites, you can do both. See: Remix as a framework that bakes in these ideas, but using the platform is easily achievable yourself too. Making this distinction between HTML <form>s and React shows a clear misunderstanding of the programming model that React provides. It targets the platform in a native way. This is how React DOM, React Native, and libraries like Ink[1] work. [1] https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink
      • otabdeveloper4 4y ago
        Maybe, but I've never (as in not even once) seen a React "app" that didn't try to re-implement the web platform and didn't fail on many user-facing metrics.
    • yazaddaruvala 4y ago
      I’ve built many real world web forms. React (or similar) is the only way to keep them sane. Interdependencies between fields. Toggling visibility, dynamically changing drop downs based on previous values. They almost always require local and remote validation. Sometimes long running validation that needs to be triggered early so it’s done by “submit time”. If it’s not done the submit needs to wait. Any and all invalidation based on changing previous fields. Adding explainability. Submission preview. Mixing multi-media with regular text values. Complex error messaging that sometimes requires interactivity (e.g. uploading images may have errors for image quality and it’s nice to have the ability to crop or re-center an image from the error message). If you think my requirements are over and above, maybe, but if you care about user experience it’s critical. If you think the forms I’m building are “overly complicated” and “rare”, I disagree. Almost all of the above even apply to one of the simplest/very common usecase: “What is your address?”. eg handling global addresses with ergonomic drop downs, postal code validation, previewing the address and asking for user input for normalizing the address, etc. Similarly very common use cases for forms, contact information with phone number and/or email validation. Using web forms is basically impossible or at best user hostile in 2022.
  • the_gipsy 4y ago
    > When the rubber hits the road, React is good. Except the back button doesn't work right.
    • zero_shift 4y ago
      That's history management. Not a React concern.
      • the_gipsy 4y ago
        Say that to the user.
        • deleted 4y ago
          [deleted]
        • smrq 4y ago
          That... doesn't make sense. The user isn't complaining that React is bad, just that your app is bad. And your app is bad because you handled history incorrectly, which has nothing to do with your choice of UI framework.
• snshn 4y ago
  Great article. I see React as today's PHP... same terrible community, similar issues and also extremely messy code, yet if you dabble with it, you'll find a job where people just don't know any better.
  • azangru 4y ago
    > I see React as today's PHP... I see it as today's jQuery.
    • shadowgovt 4y ago
      Yeah, React doesn't have the massive security holes baked deeply into the design that PHP did.
    • snshn 4y ago
      That's another good one. I feel like the crowd that used to code all that horror for Wordpress, Magento, Joomla, and other PHP CMSes, slowly moved to jQuery from backend coding, and then has transitioned to React full-time as things became more frontend-heavy. Still same freelancers from 3rd world countries and junior devs who just want to pay their bills and honestly don't even like computers that much. That's why there's so much terrible software today, not just websites. Back in the 90s and early 00s our industry was full of people who truly loved computers and wanted to make something good. Today you have to really be careful what tech stack you pick, that can make a difference between being surrounded by people who just blindly follow popular trends and real badasses who can make something great out of nothing.
  • nicoburns 4y ago
    I think the comparison with PHP is somewhat merited in that they're both practical technology communities with a "get stuff done" attitude. React is also often the entrypoint to programming these days (most bootcamps teach React) in a way that PHP used to be. I see this much more positively than you though. There's a lot of good code written in PHP these days. And it's great that programming is accessible to more people.
    • 4y ago
• azangru 4y ago
  Is the tide on React finally turning?
  • 727564797069706 4y ago
    We can hope, but it'll take more time for people to understand what a mediocre library React is.
  • tail_exchange 4y ago
    Doesn't seem like it. It's still the top rated framework according to State of JS. Also, what would be a better alternative, since you don't like it? Seems like it's yet another technology HN loves to hate, but every developer I know likes it.
    • azangru 4y ago
      It's not that I don't like it; I use it daily at work. It's just that I am seeing far too many people instinctively reaching for it when they need to build a frontend of any complexity, for any purpose. I was like that once myself, and I'm looking back to those days with embarrassment. Personally, I like the movement back towards the web platform, browser standards, and web components. For many cases, these are more than enough.
  • danielvaughn 4y ago
    The tide will only turn when a competitor arises who has a clear advantage over React. I've all of the major JS frameworks, and while they're all nice, none of them are a no-brainer as far as ditching React.
• someone22 4y ago
  "JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return. The only thing worse than using JSX with React is not using JSX with React." - JSX is the best part of React. Without it i would not even work on it or even consider any other framework. Hence i consider Solid as the only viable better alternative.
  • pwdisswordfish9 4y ago
    Agreed, other than JSX, React is an otherwise pretty meh UI library.
  • ptrwis 4y ago
    I would like to have JSX in Angular
  • davidjfelix 4y ago
    I agree - I think JSX does what templating languages have been trying to do for years. That being said, solid is hardly the only one out there competing that can use JSX: - https://github.com/vuejs/babel-plugin-jsx https://github.com/vuejs/babel-plugin-jsx - https://mithril.js.org/jsx.html https://mithril.js.org/jsx.html - https://preactjs.com/guide/v10/getting-started#setting-up-jsx https://preactjs.com/guide/v10/getting-started#setting-up-js... I think people are starting to see the power of it when it's used in a functional manner (rather than early class-based components). A lot of alternate template libraries are only minorly different in syntax and use different styles of interop to handle the crossover. I think .svelte and .riot are fairly close, while still being somewhat html-like, rather than JS first.
    • someone22 4y ago
      Does anyone of those have granular updates? I think granular updates makes Solid a great framework.
      • davidjfelix 4y ago
        That's kinda moving the goalposts. I agree that Solid is one of the more viable competitors to react for the combination of JSX + a VDOM-less model (this operates much like svelte), but my point was that it wasn't *Solely* Solid's use of JSX (there are many others adopting or trying to adopt JSX) that makes it viable.
• bzxcvbn 4y ago
  > Vue is one of the most successful and well-funded open-source projects in history. Don't be ridiculous. I will not believe such kind of hyperbole without concrete numbers. In 2021, the Linux foundation had a $177M revenue. Does Vue's funding compare in the slightest?
  • m0llusk 4y ago
    "... one of the ..." is a fairly weak assertion
    • bzxcvbn 4y ago
      That's a fairly weak article then.
  • rk06 4y ago
    Is revenue really the defining factor of success for "open source"? Is higher revenue the indicator of "well funded"? I think not. Open Source success would be indicated by adoption. And "well funded" indicated by sustainability of the project. And in thos regards, Vue is both very popular and well funded. And among open source projects of current era, it is one of the most well known one akin to linux and git. PS: Comparing a 6yr old project with 22yr old one is hardly fair. Not to mention that linux is quite big in scope
• pjmlp 4y ago
  When some CMS only adopt React or Next.js as their tier 1 JavaScript framework this self-fulfilling prophecy keeps renewing itself.
• Semaphor 4y ago
  > JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return. Oh boy, now that’s some flame-bait. I don’t like JSX, and like the Author also prefer Vue over React, but I know a lot of people simply dislike other frameworks *because* they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
  • nicoburns 4y ago
    > I know a lot of people simply dislike other frameworks because they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it). Count me in that camp. My take is that while JSX isn't perfect, it's less of a cludge (and much more flexible because it compiles down to JS) than the templating languages that other frameworks use. I'd love it if they'd add just a little bit more sugar to JSX though. Support for JS-style comments would be top of my list.
    • solardev 4y ago
      {/* I would be so happy to never have to do this again */}
      • stickfigure 4y ago
        Doesn't every editor have a "comment" hotkey? I can't remember the last time I typed block comment characters in any language. cmd-/ in IntelliJ.
        • solardev 4y ago
          I don't want to make the whole line a comment. I just wanna add a comment where the language don't want me to.
          • stickfigure 4y ago
            Select the fragment you want to comment out, then hit cmd-/. It doesn't have to be a whole line.
• zinckiwi 4y ago
  I think he undersells the virtue of being the “least likely to be regretted.” That is criterion number one for me if I’m trying to pick something that will be used for years into an uncertain future.
  • aabhay 4y ago
    I’ve seen some incredibly regrettable React code bases (and teams that had to manage them)
    • bayesian_horse 4y ago
      I sincerely doubt that would be better with any other framework. With React, there at least are enough good examples for complex code bases.
    • jdmg94 4y ago
      Every company I've worked for has some sort of shit show on their codebase. Using React was never a guarantee that your code was going to be great, the tool doesn't determine the outcome. You could have the best equipment and if your builders are trash the house is still going to be mediocre
• quickthrower2 4y ago
  Probably there will be a grass roots if devs hacking at home with not-Reacts, loving it, bringing it to work. It is not like you need to only use one framework per company. There is a lot of melting-pot coding happening out there. React was probably successful in part because it didn’t require a rewrite.
  • shadowgovt 4y ago
    Depending on the scale and goals, there are huge advantages to companies standardizing on one framework. Nothing burns more than having to dedicate an additional quarter to a project because half the code you need to finish the task is sitting atop another API or, much worse, in a different language. And when we're talking web apps, There's real material cost to the end user in using more frameworks than are strictly necessary. React is large, but it tends to be large with a spanning set of features that means you don't have to glom something else in alongside it.
    • quickthrower2 4y ago
      I agree that it is advantageous for companies to standardize but often they don't. React + Vue in one app might be a bit crazy but React in the main app and Vue in an internal app, or some secondary app might be OK. Resume-driven development is a thing, as well as joy-driven development. Devs are gonna be devs! There is a mild conflict between what is good for a devs career and what will make the shareholders of that company the most money. It is almost like a super-polite tug of war over future potential dollars between the two. Mostly incentives align but sometimes not.
• salt-thrower 4y ago
  The fact that React is “good,” in the author’s own admission, combined with its raw popularity and staying power is why I would still choose it for any greenfield project.
• unconed 4y ago
  I couldn't disagree more. What all these React spinoffs seem to be doing is unlearning the lessons encoded in the React architecture and replacing them with more magic by "helpfully" applying state changes immediately instead of in a controlled fashion. But this is going to create mixtures of old and new state, which creates subtle bugs down the line. Discussions about VDOM also seem mostly pointless because it is clear to me most people's mental model of how React renders is flat out wrong. If you are redundantly touching the DOM, that means you haven't memoized your components, or you are needlessly making copies of the same state. All of these have far bigger performance implications. In fact, even without memo(...), React renders can halt early. Quoting from the Use.GPU/Live docs, which is a true React extension with the same semantics: "If a component renders the exact same JSX object as before, React will not re-render that child, even if the child is not memoized. So there is a hidden semantic in React: when you construct a JSX expression anew, you are requesting that those children be re-rendered unless memoized. But if you reuse a JSX expression from before, you are implicitly giving permission to ignore any unchanged children." This is crucial to understand when stacking context providers. I don't get the sense that React derivatives have been used to build e.g. desktop-class apps. They mostly seem optimized for web sites. While it is true that React does a lot of things at run-time instead of build time, this is necessary for building truly data driven apps. JSX is really Lisp quoting in disguise. If you can't recognize this, you should probably brush up on the fundamentals.
  • sdgluck 4y ago
    Here's a link to the docs for anyone else who is interested to read them: https://usegpu.live/docs/guides-memoization https://usegpu.live/docs/guides-memoization
  • danielvaughn 4y ago
    Agreed. Last year, for instance, I tried Svelte. I had a great time for a while, everything was fairly simple...but then I hit a specific scenario. I can't recall what it was, but it led to me digging as deep as I could into their docs to try and understand how Svelte was doing that whole $ thing. I nearly melted my brain trying to understand it. That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.
• postalrat 4y ago
  I think the key to react's success is that it's basically just javascript and so works well with typescript. Just write a function that returns an element.
  • Marazan 4y ago
    Bingo. The great lesson that React learnt from Flex is that your Components should just be code. In Flex your fancy MXML components are 1 to 1 mappable to plain Actionscript. Not templates, not an opaque resource bundle, not some whole other thing. Just code.
• cabirum 4y ago
  React is a mature project with a huuuge ecosystem of libraries and components. It is wery well tested. While not being particularly great at anything, its not worst at anything, either. I dont expect a competent dev to ever encounter performance issues with it. Other frameworks have their own problems. Solid requires a custom babel compiler plugin. Some are new and lack components, placing a huge backlog to reimplement everything from scratch, just not worth it. We need a framework that will not tie components and libs to itself, so they can be used with other frameworks or with plain ts as well.
  • kapilkaisare 4y ago
    > We need a framework that will not tie components and libs to itself, so they can be used with other frameworks or with plain ts as well. That's why I wish web components would see greater adoption. Having worked through jQuery, Backbone, Sencha ExtJS, AngularJs, Angular 2 and React over the course of a 15 year career, It's frustrating when you can't switch frameworks because the cost to rewrite your existing components trumps the potential efficiencies of adopting a new set of design patterns and affordances.
  • orange8 4y ago
    > Solid requires a custom babel compiler plugin. Don't all of them do though? Like @babel/preset-react for example
    • cabirum 4y ago
      No, babel is completely optional for react+typescript.
• Aeolun 4y ago
  I dunno, by my reckoning the following are the top items in the category. Performance: Solid Learning curve: React Bundle size: ? Scalability: React Community and support: React Financial backing: React Developer experience: React Hireability: React
  • danielvaughn 4y ago
    Bundle size is probably Svelte, if I had to guess.
  • solardev 4y ago
    Also... "Good enough, let's spend time considering other things instead: React" It may no longer be the best at anything anymore, but it's a polished well-rounder that will probably be fine for the typical web app. Less cognitive load when you just use it and follow the herd.
  • thomaslord 4y ago
    Are you putting react there because you consider it to have the largest learning curve? If not, I'd probably substitute Vue. When I was first getting into reactive frontend frameworks it was part of a time-sensitive project, and we chose Vue because we could basically just write HTML and sprinkle in the reactivity. This was back in the Vue 2 days before they made everything functional, and I still think that older Vue API is the most self-explanatory for people who already know HTML and some vanilla JS.
  • steve_taylor 4y ago
    React wouldn't be my pick for scalability. For large, complex and dynamic pages, its performance is significantly degraded by the virtual DOM. There are various workarounds to limit the size and frequency of virtual DOM renders, but they can only go so far, which is why we now have concurrent mode. Solid and Svelte are more scalable in that sense. Learning curve: Hooks can be quite unintuitive for the React beginner. React's learning curve was far gentler when all components were classes and the lifecycle was simpler.
    • 4y ago
• pweissbrod 4y ago
  What's the point of this article? An attention getting headline followed by some bombastic claims followed by walking them back later in the next paragraph. It's like generating debate for the sake of debate. I get the impression these things exist just to keep engagement numbers up
  • davidhariri 4y ago
    Same reaction. This stuff is catnip for curmudgeons.
  • jdmg94 4y ago
    Author has 3 years in the industry, probably at the peak of the Dunning-Kruger curve
• shadowgovt 4y ago
  This article really undersells the value of a stable, popular API. React keeps getting picked because it has an ecosystem. And that's the most valuable thing for medium to large scale enterprise jobs. Web developers are positively thirsty for abstractions that are powerful enough to get the job done without having to learn something new in 2 years. In an industry of near perpetual churn for the apparent sake of churn, having something you can just cling to that does the job almost all of the time is great. You can focus on the actual problems you want to solve while someone else burns their time arguing whether you could solve them faster with Vue, hypothetically, in a spherical development environment where everybody on the team was already Vue experts.
  • yencabulator 4y ago
    Stable? Classes vs functions & hooks is two completely unrelated APIs for the same thing, and that sort of churn is all over.
    • shadowgovt 4y ago
      And yet because they're still under one framework they inter-operate relatively smoothly. Far more smoothly than if one were trying to change from React to another framework. All of my old class-based components still work under my React hook-and-function code.
• nfRfqX5n 4y ago
  Feels like every time someone criticizes React, they assume the people using it are clueless idiots that mindlessly follow the crowd.
  • v0idzer0 4y ago
    People who assume that suffer from the Dunning Kruger effect
• jackconsidine 4y ago
  I've had the opportunity to train junior developers on React, Vue, Svelte, Solid, and even Angular. And I've used Ember professionally. The objective time-to-profficiency has made React (and Solid which is quite similar to React) the most obvious choice for us, and I'm one uncomfortable with consensus. Svelte doesn't quite have the staying power of React or Vue yet. Since it's a superset of JavaScript, it's harder to teach, and the component frameworks just aren't there yet. Vue is great, but Vue 3 took a step towards performance and a step away from intuitive readability IMO- it's probably better suited to a team with homogeneously high experience.
  • aabhay 4y ago
    That’s ironic because Vue 3 is soo much more React-like with the useThing() syntax.
  • localvoid 4y ago
    > (and Solid which is quite similar to React) How is it similar when React lets you write non-incremental algorithms when you working with your state and with Solid you are forced to write incremental algorithms? Simple aggregate (GROUP BY) use cases that your average junior developer will be able to solve in 5 minutes with React will be a huge problem even for experienced Solid developers. The only similarity is that it is also using JSX syntax, but with completely different semantics.
  • rk06 4y ago
    This is surprising that folks picked up React faster than Vue/svelte/solid. I suspect that they already have prior react knowledge
• aabhay 4y ago
  Personal viewpoint alert: I deeply despise React, and have turned down job offers simply because they made that framework choice. Vue is so much more simple and concise, and its CSS markup in particular is just incredibly good. If anything, React gives you way too much rope to hang yourself and you end up with some mess like quoting CSS inside of some object to apply to another object
  • bayesian_horse 4y ago
    In my opinion CSS should not go anywhere near the component code. With bootstrap or something similar (even some dissimilar frameworks), much of the "extra styling" is achieved with utility classes. Not using utility classes and a consistent, thought-out CSS frameworks leads to great pain when scaling the codebase. Bootstrap is a lot like React. You don't appreciate the "bloat" until you need it. Or worse, you recognize you reimplemented the wheel a dozen times without noticing and most of your "wheels" are polygons with a different number of edges.
    • mgkimsal 4y ago
      The majority of my Vue SFC have no css/styling in them - using the utility classes of a general library (bootstrap/etc) is generally pretty good. There are times when you do need some override, or something custom local to a specific component. Scoped CSS in an SFC is very useful. I had to do some react a couple of years back and I was more than a bit surprised it wasn't supported. "Oh, you can use this plugin" but... the other 4 people on the team didn't use it, discouraged it, and saw nothing wrong at all with needing to coordinate style changes specific to one component in relatively disconnected style files. I got one "it's better this way" but I think he was meaning "this is what I already know".
      • bayesian_horse 4y ago
        In my opinion it is harder to get stuff like alignment right. The various utility classes in Bootstrap (and other framework) are a blessing because you can have things like "give me two times the usual margin to the right" without having to hardcode the margin value. Using any specific CSS - scoped or unscoped - for a particular component is not a good sign. This might not always be avoidable. Vue has a mechanism for that, but you can't really exchange it for something that fits your needs. It's going to be there, trying to please you with all the features the upstream developers thought you'd need and you have to program around those feature.
• pgt 4y ago
  If the premise is to be believed, the article is only making the problem worse... Personally, I can't stand writing JavaScript and prefer to insulate myself against the moving target that is ECMAScript by writing declarative UIs in ClojureScript + Reagent, which uses React behind the scenes: https://reagent-project.github.io/ https://reagent-project.github.io/ There is some interesting new stuff on the horizon like Hyperfiddle Photon, which compiles network I/O for you. As for me, an old dinosaur, I'm tired of learning new syntax. Clojure the language has not changed since its release. Lisp has been around since the 60s. It will be around in another 60 years. For me, it is the 100-year language. I'm sure it's not the end goal, but I am willing to bet it will be a Lisp-like.
• bayesian_horse 4y ago
  It's popular to hate on React. I still like it, and much of the "dislikes" I hear come from not actually understanding React and using it in the "functional programming" way it was designed to be used in. Same with Redux.
• riddleronroof 4y ago
  Vite works with React. And you can get the same performance as Vue. I get thé author’s general point. But most of us are not trying to innovate on front end frameworks. And a CTOs job is to make a better product. Not a playground for their experiments.
• emptyparadise 4y ago
  React is the Unix of the web, huh.
• bastawhiz 4y ago
  > React’s performance relative to the field is pretty well-documented, so I don’t feel we need to go into it here. But suffice to say: if your goal is to build the most performant thing you can, React isn’t what you’re considering. React is amazing in that you can build nearly anything in a mediocre way and it'll probably be fast enough. And when there are performance issues, there's a ton of resources and tools to figure out why and how to make it better. That's not to say React has great performance. Everything in our field has performance tradeoffs. But on the whole, I think it's really disingenuous to say React's performance is bad. Python is orders of magnitude slower than Rust but for any use case where performance is that critical, you weren't fretting about language choice in the first place. If you actually had a use case where you're rendering a massive spreadsheet or lists with tens of thousands of nodes or some other wildly complicated UI, React can do the job if you really wanted it to, but why are you even fighting that battle in the first place? Most UIs are boring. Dialog boxes. Forms. Tooltips. If your CTO is trying to optimize one of these UIs for sixty frames per second instead of thirty, they're an absolute fool and shouldn't be evaluating front end frameworks.
  • neon_electro 4y ago
    Can you elaborate on the final sentence of your post?
    • deleted 4y ago
      [deleted]
    • bastawhiz 4y ago
      A CTO should be worried about the big picture and product quality. Not an imperceptible performance difference. CTOs should be detached from the implementation details of the code except where it poses long term risk to the business. A text box rendering in 0.2ms versus 0.6ms is a useless distinction for a person in leadership to waste their time on.
  • anonymoushn 4y ago
    How did we get to a place where it's unreasonable to expect to change some text boxes within 50 million cycles?
• difosfor 4y ago
  I don't understand why people don't base their apps and frameworks off of standard browser and JS supported techniques like custom elements and template literals with tag functions like Lit. Is this fragmentation really still serving a purpose or just legacy support for choices like JSX that were made in the past when these standards weren't available yet?
  • Existenceblinks 4y ago
    component: custom element wrapped in init(name, store, listOfUpdateFnPair) view: uhtml or lit-html (don't use lit-element) action: DOM event delegation for intercepting anything happens on view model: a global store passed to when custom element is defined. update: list of [selector, f({model, view}] pairs passed to when custom element is defined. --- Congratulation we now have a self-contained Elm architecture.
  • akira2501 4y ago
    I feel like an entire generation of programmers got cheated and didn't have to write desktop applications to get "their software" used in any real world context. As a result, they don't really understand what's possible, and the simple ways you can go about it... particularly, as you've flagged, with all the modern tools available in "standard browsers" now. The way I see people using flexbox makes me cringe a little, too.
    • frosted-flakes 4y ago
      Can you elaborate on that flexbox comment? What don't you like about flexbox?
      • akira2501 4y ago
        I love absolutely love flexbox. This is super opinionated and based on the types of software I'm typically exposed to. I think most people just don't understand how to get the most out of it in terms of creating user interfaces, and use "table" oriented thinking like percentage widths and media size queries to control overall layout. I think you should use it the way that something like QT's BoxLayout and GridLayout containers work. Strictly using flex-grow and min-width, max-width and justify-content to control layout. I can design just about any interface with just these CSS classes, with very occasional use of the three properties above: .VBox { display: flex; flex-flow: column nowrap; } .HBox { display: flex; flex-flow: row nowrap; } .VGrid { display: flex; flex-flow: column wrap; align-items: flex-start; } .HGrid { display: flex; flex-flow: row wrap; align-items: flex-start; } .Grow { flex-grow: 2; }
• Existenceblinks 4y ago
  Imagine being a professional in an engineering field and thinking this situation is acceptable. Except of course being a building contractor who reduce cost by lowering grade of materials. Hopefully your new house has reasonable price.
• dang 4y ago
  Other ongoing thread: Introducing Svelte, and Comparing Svelte with React and Vue (2021) - https://news.ycombinator.com/item?id=32763509 https://news.ycombinator.com/item?id=32763509 - Sept 2022 (187 comments)
• flappyeagle 4y ago
  This critique doesn’t hold water. In fact this entire style of critique is misleading. Let’s apply it to Excel. Not the best community. Python’s is more active and technical. Not the best at collaboration. Google sheets is natively collaborative. Not the best at charting. Tableau is superior and much more powerful. Etc. But it doesn’t matter. Excel is the best choice for most analytical users.
  • deleted 4y ago
    [deleted]
  • wruza 4y ago
    The company I work at hired a financial analyst and his first task became to standardize some reports/data according to textbook practices. He said it’s a headache to do in a spreadsheet and he’ll better use python. Excel may be the only choice for those who grew up without accessible programming around, but times change.
• jesuscript 4y ago
  Quite frankly I haven’t seen interesting enough UIs the last few years to care too much about framework advancement. Sometimes my instincts kick in and alert me that ‘such and such component rerenders too much’, but then I realize it’s some dumb text and no one cares. I move on. If you got a different type of UI, I can see why React would not saturate your use case.
• strken 4y ago
  > JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return. The only thing worse than using JSX with React is not using JSX with React. Not sure I understand this, or if I do understand it, I definitely don't agree. HTML's a tree. Function calls are a tree. They're similar in nature and they map cleanly to each other. > Or how you can’t use some standard HTML attributes in JSX (because JSX doesn’t know the difference between a React prop and an HTML attribute). Or memoization. Or how there aren’t real conditionals, so you have to rely on short-circuit operators. Or how preventing infinite loops is your responsibility—even though there aren’t really loops, so you have to use array methods…you know what, let’s just move on. These are natural consequences of representing HTML as code, and they help me understand the first quote a bit better. I still don't think JSX is bad. Putting flow control into the template language in the style of Vue, Angular, or even the supposedly logicless Mustache ends in a programming style that I dislike, where the dividing line between template logic and logic in the actual code isn't clear, and you need to refactor heavily when you reach the gaps in what the template language lets you do. They're closer to failures of EcmaScript. Coffeescript and Ruby weren't ideal, but their syntactic sugar would have let you do (in ES-like pseudocode): const TodosList = ({ todos }) => ( <div class="todo-list"> { if (todos.length > 0) { todos.map(t => <Todo key={t.id} todo={t} />); } else { <p>No todos yet</p> } } </div> ); Blending code and data can look a bit scary, but it lets you copy the blocks of code around like normal. You could (in a theoretical world where if statements returned the result of the last line of the branch) just copy that code outside the JSX, and have it work properly. With horrible JSX ternary operators you still have to rewrite, but that's the fault of the JS part of JSX not the underlying language-agnostic concept, and it's still something I prefer to putting logic in the template language itself.
  • somewhereoutth 4y ago
    > HTML's a tree. Function calls are a tree. They're similar in nature and they map cleanly to each other Yes, this is a key point. Indeed, many other 'constructed artifacts' compose nicely as trees, and thus functional languages are a natural fit for defining them parametrically.
  • alex504 4y ago
• kumarvvr 4y ago
  Interesting to see that Angular only comes up in Scalability & Financial Backing sections. And I do agree that in every other metric Angular is worse. However, I feel that developer productivity wise and team output wise, Angular is a safe and reliable choice. I only wish there was some framework that has the tenets of React and the structure of Angular.
  • jeremycarter 4y ago
    Angular is moving in the right direction now I think.
• johnfn 4y ago
  I think the reason this article is wrong is this. The author says that React isn't the best in any singular category, and is solidly middle of the pack. But that actually makes sense; being best at one thing (such as bundle size) means you're probably making some tradeoff against another thing (such as functionality). React isn't as fast as Svelte, but Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many. React isn't as thin as Preact (or whatever other small library there is), but that means that React has more functionality. React might not be as easy to learn as some other frameworks, but that's because, honestly, React chose the right abstractions to build, and those aren't always the easiest to understand. (Honestly, they aren't hard to understand either; it's a minor difference at most, but it is what it is.) And honestly, if you were to build a big matrix of frameworks graded across all these categories, I suspect you'd find that leaders in one category almost invariably tank in other categories, for the exact reason that you have to make significant cutbacks in order to beat the tradeoffs that React made.
  • josephg 4y ago
    I'm not convinced. In programming language / library design, you can often "have your cake and eat it too" if you can find a better design. Better designs take years to invent and mature - jQuery came out in 2006. React came out in 2013 (7 years later) and I think it improved on jQuery in just about every way. But now its 2022. Its been 9 years since React came out. As far as I can tell, clever folks have improved on how react works in just about every way in turn. What deep tradeoffs are Solid or Svelte making in exchange for their speed? I can't spot any. As far as I can tell, React's virtual DOM diffing is pure overhead - so good riddance. Solid and Svelte use a different approach to deal with state (similar to React's hooks) that honestly I prefer anyway. Dealing with state in react is a mess. Where do the new frameworks lose to React on any technical metric? Svelte is designed to be compiled, but lets be honest - in 2022 almost everyone is compiling our JS anyway. Go ahead and build a matrix of frameworks if you want. The competition is fierce. Like jQuery before it, React hasn't aged well. I'd bet good money that react, like jQuery, doesn't come out on top.
    • jack_pp 4y ago
• throwaway1851 4y ago
  I don’t come from a JS background, and JS makes me very angry every time I use it. But it’s unavoidable if you want to build something on the web. I tried to pick up React a few years ago for a project, saw the JSX, and put it right back down. At the time, Vue’s emphasis on HTML templates was comforting and approachable, since I like HTML and its simplicity and visual structure. So I tried Vue, and found it was easy to go from toy examples to real, working projects with no major gotchas. I recently spent some time learning Vue 3, and I’m a little less enamored. The composition API is nice for not requiring deeply nested code inside a giant object literal. But having my code littered with .value is ugly and a source of endless bugs. (You also don’t always need .value, such as when referencing a Pinia store. Ugh.) I looked into the pending “Reactivity Transform”, but it too introduces weird surprises and seems like its issues may be unsolvable. Bottom line: I hope and pray for the day WASM allows Python to get a decent footing in the browser environment.
  • frosted-flakes 4y ago
    What do you dislike about JSX? It's just a tree of function calls.
    • throwaway1851 4y ago
      Just the visual appearance. It’s so chaotic. I’m sure it’s very powerful, and that’s why people like it. I just don’t have a very high tolerance for clutter.
      • frosted-flakes 4y ago
        It looks almost exactly like HTML though? The only difference is wrapping curly brackets around expressions. I admit that if you embed long expressions directly in the JSX it can chaotic, but I tend to assign these expressions to variables first, then put the variable in the JSX. Or break it up into another component.
        • throwaway1851 4y ago
• ZephyrBlu 4y ago
  What the author fails to realize is that being popular (I.e. shared language and network effects) is extremely valuable. With React you know it will work and scale (In terms of your organization) well. You cannot say the same for many other frameworks yet. For a company that has pretty generic frontend needs React is probably the best choice.
  • rk06 4y ago
    Yeah, you can point out ae many flaws as you want, but popularity, longevity, and inertia are the main business priorities. Before React, angular js was popular for this very reason despite its well known issues and digest cycle headaches Technical merits are secondary concerns and only become primary when software engineers are empowered to make these decisions
  • whatarethembits 4y ago
    This. Vast majority of the companies out there are NOT software companies. Meaning, they don’t have full time developers, at least none with decent experience, on a full time payroll. Their internal tools/portals/sites are either maintained by contractors every now and then or junior developers/interns. In these cases, popularity of a technology, documentation, ease of hire, being able to hit the ground running etc are far important than a slightly smaller bundle size and a few extra ms response time. It’s a difference between being able to hire someone easily and not i.e being able to develop features vs months of delays and cost in order to hire a senior “efficient” dev for one of the lesser known platforms. Choice of tech stack falls somewhere middle or bottom of the list of things to consider when delivering a solution/product. Good enough is good enough. Other factors are far more dominant after a certain point.
• throwaway787544 4y ago
  Ansible is absurdly terrible. But good luck finding anyone who wants to use any other configuration management tool for less than 20 servers. Jenkins is horrible. But it's by far the most ubiquitous ci/cd thing. Terraform is less horrible, but still pretty bad. Yet it's impossible to work for any company that wants to do IaC and not use it. If the Peter Principle says "incompetence rises to the top", the Poettering Principle should be "the most popular garbage rises to the top".
• michaelwww 4y ago
  Tired: React Wired: Web Components
  • dmitriid 4y ago
    Have Web Components solved any of these issues that don't exist in any of the "tired" frameworks https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728 ?
    • michaelwww 4y ago
      That tweet is 3 years old. Web Components weren't ready for prime time a few years ago. Google has the Lit framework is using it in Angular. Web Components are here to stay. I'd like to know what Rich Harris thinks about Web Components today. Microsoft just released their Web Component frame work: The adaptive interface system for modern web experiences. Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard Web Components. Standards-based Web Components are the foundation of each FAST component, making them compatible with almost any modern web framework, including those listed below. https://www.fast.design/ https://www.fast.design/
      • dmitriid 4y ago
        > That tweet is 3 years old. Web Components weren't ready for prime time a few years ago. So. Have they solved any of the issues listed? > Google has the Lit framework is using it in Angular. You've missed a few words in there. yes, Google has Lit. And yes, Angular can be twisted to use them (but doesn't use them by default). > Web Components are here to stay. I'd like to know what Rich Harris thinks about Web Components today. Literally nothing you wrote answers my question. And the answer is: no, despite the tweet being 3 years old and web components "not being ready for prime time then", none of those issues have been solved in the three years since. --- Edit. As to what Rich Harris thinks about them now? https://twitter.com/Rich_Harris/status/1518912939876618242 https://twitter.com/Rich_Harris/status/1518912939876618242 They're the past. Specifically, they took our best ideas circa 2010 and ossified them into the platform https://twitter.com/Rich_Harris/status/1513638143584518154 https://twitter.com/Rich_Harris/status/1513638143584518154 I don't see any evidence of [fameworks will be transpilers to native web components in the next 5 years]. if anything, i think we'll see frameworks begin to explore the notion that 'component' is a purely author-time concept etc.
• v0idzer0 4y ago
  How do you write such a long article of bold claims without mentioning a better alternative? If React is so bad, what’s better? Why not put your alternative through the same analysis with the same criteria? This is yet another lazy “I don’t like React” take.
  • EGreg 4y ago
    svelte is way better
• lmeyerov 4y ago
  The article starts to edge on the switching costs issue and just misses it. Dislodging a great incumbent -- even if the greatness comes from its network effects -- generally takes either the ability to eat it from the inside when marginally better... Or being well past marginally better. Most of the article is ultimately just not that important, for most use cases meriting a SPA, to give you the ecosystem benefits. React was such a tool, but the new ones are have individual innovations that are great but just not a night and day step up for teams. The market has rejected the categories in the blogpost as too weak ROI. I do think it's fair to wonder what new frameworks ought to solve. Ex: As web GPU finally happens, we'd expect framework churn. Or, maybe it will be less about the framework, and more about the AI, or GIS+AR integration. Or some incredible tooling stack, like copilot is doing for autocomplete. Or maybe better multilplayer mode & collaboration. Just not smaller bundles and faster first paint.
• GiorgioG 4y ago
  The one thing that drives me crazy with react compared to angular (having moved to a react shop from an angular shop) is the fact that every react app we have in house is architected/structured differently. One is using nextjs and xstate, another is using react router and redux, another is a CRA based app, and so on. At a large org you wind up needing a committee to try to standardize on app architecture. With Angular at least, most things have well defined patterns.
  • jeremycarter 4y ago
    Its an observation a lot of React evangelist ignore.
  • likortera 4y ago
    I used to think like this, but nowadays I think that's no a real problem, at eñadt to me. I find it very easy to go across different JavaScript projects with different libraries, etc. Usually the worst part is understanding the business domain, the warts of the application, the know bugs, problems, etc. The libraries used, as long as they have documentation and are supported and more or less widely used...that's fine, they're easy to learn. And if I have to switch between 10 different projects, then for me that's the actual problem, not the fact they have different architectures. What has been a terrible experience for me, was when at two past companies in an attempt to "standardize" they ended up with custom in house libraries and wrappers, all of them built in house, undocumented, with the original developers already gone and nobody knowing/wanting to touch them. And then the rejection of any kind of improvement or modernization because "then that new app will have a different architecture"... So what? We have a terrible one, and we need to do every project terrible, so everything is consistently terrible.
• kaeruct 4y ago
  The author mentions: >Besides JSX, React itself has its own bevy of unique conventions and trip-ups (not to mention two completely different syntaxes that are not fully interoperable). But elaborates no further. Does anyone know which two syntax they are referring to?
• BrandiATMuhkuh 4y ago
  Choosing react, because others choose react is simply another word for "quasi standard" or "industry standard". For me, who hires Devs and works with react daily, having an industry standard is wonderful. I still remember the stressful and heated days of the past. Where every 6 month a new framework came out. Today, I can hire a junior developer and within 24h they contribute to the code. No need to train them for many months. This makes both lifes much nicer. I don't have to spend a lot of time training. And they feel like they are contributer early on.
  • megalord 4y ago
    Don't know anything about your company or product, but I've been in 4 different companies where React was used. Every single one had different setup, best practices, state management lib, "the way" of doing things, bundler (create-react-app, next.js), etc. Each project was so big, that I'm little in doubt about your statement "within 24h they contribute to the code". It could be your react apps are very very small or junior devs are very very good and probably shouldn't be called juniors.
• hnbad 4y ago
  I thought the title was a reference to what every developer I know said about React after a few months of working on React when it first became popular: "React is amazing but it won't live forever. It's hard to imagine what the framework that takes its throne will look like but it will probably look nothing like what we've seen before. Either way, React can't be the end. There will be a next framework." So far that hasn't manifested. Vue arguably took some learnings from React but it feels more like a step back than a paradigm shift in some ways (not that that makes it bad, mind you). Remember that React took its throne from Angular and remember how Angular looked at the time. That's the kind of change we're looking for. Most React developers I know know that React will go away eventually and that they'll switch to something else at that point. Mind you, they all didn't start out as React developers, so this isn't their first rodeo. But that new "genre defining" framework (as the article puts it) just doesn't exist yet, or if it does, it hasn't gained any real traction.
• naranha 4y ago
  I think TSX/JSX is one of the top reasons to use React. It is so tightly integrated with Typescript and the IDE/VSCode that it allows you to type check your markup at every step. That was one of the biggest things I missed in Vue (2). But I think these days Vue also supports JSX (?). Other reasons are that you have a lot of control over what gets re-rendered when using memoization, with the huge but that there a lot of foot guns. As well as it is easy to write terribly performing code in react, while it is really hard to write fast/good code.
• megalord 4y ago
  I have been in 4 different companies, with a decent to very good salary. React is self-fulfilling prophecy also because developers want to make as much money as possible and companies need more React developers because, at least in my experience, development is so much harder and slower with react - so companies need more react developers, and because there aren't many in the market, price (salary) per developer goes even higher. So everybody learns React, because companies need more React developers, because development is too slow. Think about it, which developer would prefer framework/library that gets job done quicker and easier, but pays less?
  • zero_shift 4y ago
    Your reasoning may be backward: Companies with poor codebases have middling developers, and middling developers choose the most common languages. It's the same with Java versus Clojure. Are LISP macros really the reason those Clojure devs seem so productive compared to Java bodyshops? Or is it the most talented devs going after exotic technology, and the less able going for the lowest common denominator?
• Scarblac 4y ago
  React is: - Good enough - Easy to find developers for - Extremely well supported with libraries for whatever you want to do - Good enough. I'm convinced it'll still be the top framework ten years from now. That better frameworks exist is just not relevant, the above are what matters.
• davedx 4y ago
  "JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return." Author's opinion, and one I find very strange. JSX with TypeScript is one of the best features of React, it's a dream compared to Angular's awkward arcane syntax (that didn't have type checking until what, a year or two ago?). I get that people don't like React, that's fine. But "React is popular because it's popular" is an intellectually dishonest argument. There are obviously good reasons technically competent people choose it for projects.
  • Induane 4y ago
    I think it's a combination of the network effect along with the "good enough" element. There is a point where a framework gains inertia regardless of whether or not there are better offerings simply because it's what people are used to. Companies like solutions where there is an substantial pool of developers from which to choose. Etc... It might actually be popular because it's popular; that isn't necessarily a dishonest argument on it's own. But usually when something is popular because it's popular it's also technically competent to enough of a degree that it's good enough.
    • joshmanders 4y ago
      Or... hear me out... None of the existing alternatives really have been good enough to completely rewrite their applications for. It's disingenuous to say that React got popular for no reason and now people just don't want to change. React-isms ooze all over everything that came after it. If it was just "meh, good enough" until something better came out, then why does Preact name itself after React and have a react-compat mode and base itself on JSX? If React was just "meh, good enough" then why does every other framework out there take inspiration from React and when React came out with something all these other frameworks came out with their implementation of that feature?
  • Cthulhu_ 4y ago
    But Angular's even older than React is at this point. That said, React gained a lot of popularity while Angular was in the limbo of AngularJS to Angular 2; I think a lot of people switched up then. I'm currently doing Angular again and I hate it (especially combined with NgRx, why do I need half a dozen observables, reducers, actions, selectors, etc just to make a HTTP request?), it's a step back from React in my last assignment; React's functional style with hooks and react-query was a great combo. I'm not saying it's the best, but it worked for me. For my next trick, I should learn Vue. Although on the other hand, front-end fatigue kicked in years ago. It's just the same thing again; some forms, validation, layout/style and a REST API, just using the tool-du-jour. Sigh.
• richeyryan 4y ago
  This article, and all the ones like it, remind me of Worse is Better. Specifically, the key point from that essay is: "The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing." This post concedes that point in the first couple of paragraphs. Much like C and Unix-like systems, this is why React isn't going anywhere. Indeed not based on the competition it has now. The best its competitors can do is convince React to steal their ideas and keep pushing toward doing 90% of the right thing. [1] https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html
• polydevil 4y ago
  JSX is awesome. And it is optional. React picked js-first approach. Everything inside curly braces is a valid js expression. So you can use more and more vanilla js features and be happy, while some angular-first frameworks forces you to use some strange semantics; They also make you learn new pseudo attributes - ng-if, ng-for, etc. Those are not valid html attributes. And you cant translate that knowledge anywhere else. With react you just need to remember to pass className instead of class and sometimes to pass key prop and you are good to go. Overhead is minimal. Since jsx is optional, you can write <Component value={1} />, {Component({ value: 1 })} or createElement(Component, { value: 1 }), which gives you so much control.
• k__ 4y ago
  React popularized component based architectures for frontends by making them incredibly easy to use in a time where people constantly fought against Angular idiosyncrasies. It was a breath of fresh air.
• jatins 4y ago
  React may or may not be the best choice today but one thing to remember is that every single UI framework today (Vue, Angular and even beyond Web: Flutter, SwiftUI) borrowed React's component model and I am glad they did. It's such a beautiful abstraction and so much more manageable than anything we had before it.
  • Cthulhu_ 4y ago
    Interesting observation given that Angular, Dojo, even BackboneJS came out before React, all going for a component-based UI framework.
    • jatins 4y ago
      Angular 1 was a mess of filters, controllers, scopes, directives, services and what not. The only closest thing to what we call a component today in their was directive but it was never the main abstraction BackboneJS was MVC iirc? Don't remember if they had any notion of self contained component but it was very different from the MVVM paradigm react introduced. No experience with Dojo so can't comment but I remember MVC being the paradigm with most mindshare before React became popular.
• qeternity 4y ago
  "But it’s remained a consistent 80% of the pack for three years now, which doesn’t seem like a strong sign of continued adoption." Bizarre take. Market share may not be increasing, but this means that 8 of 10 new projects are currently choosing React...if that's not continued adoption, I don't know what is.
• aristofun 4y ago
  There is no problem with react, it’s an amazing piece of technology that has moved us all forward. There is a problem with people over using and abusing it. And it’s not react’s fault.
• silent_cal 4y ago
  I spent a few months learning HTML, CSS and JS because I thought they were the backbone of web development. I got decent at it and found it pretty enjoyable, because everything seems to make sense - HTML structures the page, CSS handles the design, and JS handles the functionality. React, on the other hand, I find very confusing. I don't understand what problem all that complexity and abstraction is supposed to solve. Aren't HTML/CSS/JS really good and time-tested tools for web development on their own?
  • noman-land 4y ago
    React solves problems you don't often run into when making simple websites with simple functionality. Once you start trying to build complex, dynamic web applications that involve loads of state changing over time, and user and API interactions, it can get really messy and cumbersome. Think Gmail, Spotify, Facebook. Now if you try to add other engineers to the project, without some sort of framework, it's difficult for them to understand what's going on, or to change things without cascading consequences.
• thayne 4y ago
  So what framework(s) is better in every category, and why is it better?
• jdmg94 4y ago
  Author is at the peak of the Dunning-Kruger curve
• typingcyclist 4y ago
  Not sure I understand the point of this article. It seems that we're trying to talk about how popularity doesn't reflect the most advanced technical solution. But where is that the case? Java's adoption is huge compared to say Clojure or Elixir. One reason why people choose React is due to being able to hire a specific set of developers and leverage the huge eco-system of tools, libraries and information surrounding React. React has reached the late majority now, and it's everywhere. Most of these mentioned libraries, i.e. Svelte or SolidJS, are probably more in the early adopter phase. These things take time.