3 ms·

> React-land is crazy sauce In what sense? I develop my front ends primarily in React, and other than hooks - which a lot of people have adopted anyway, and o

> React-land is crazy sauce In what sense? I develop my front ends primarily in React, and other than hooks - which a lot of people have adopted anyway, and only extended the lib - the API seems very stable. The 3rd party library ecosystem may be wild because React is superpopular and people are publishing npm packages with half-baked solutions of dubious utility, but there's always a good library or two for 95% of tasks (good: regularly maintainted, fully-featured, well-documented, tested, typed, etc.). I don't have any experience with RN so I don't know how things are there, but your comment seems to be about the React ecosystem at large and doesn't correspond to my experience at all.

hardwaresofton 6y ago
I wouldn't consider myself a React expert because I basically stopped using it or recommending it once Vue came out, but stuff like: - Needing shouldComponentUpdate to do anything nontrivial (it's a bad sign for what should be a library if people make "X demystified"[0] posts). - The sheer amount of times React has been basically rewritten, with - Hooks (to be fair Vue has this too, and it's not actually a bad feature, but as usual React introduced it in a near inscrutable way). - Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call. React had the initial idea, but it just feels like the stuff that came after (Vue in particular) delivered better on the simplicity we all wanted. There are so many little gotchas all over the place that people just paper over/memorize, when Vue 2/3 basically works as advertised right out of the box, need(ed?) less hacks, and you can get reasonably productive and performant in <1 day after reading all the docs. Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day. The combined complexity is not worth it when compared to Vue in my opinion. These days if I want to use something, I do vue + vue-router + parcel and call it a day, and get productive much quicker though the ecosystem isn't quite as big. For uber-simplicity I like mithril[2][3] though -- but it falls down when you start looking at advanced features like SSR/rehydration. React has the best third party support/ecosystem because of the amount of hype and OSS friendly companies that are using and benefiting from React. It also is the best corporate choice -- react developers are more fungible, you will benefit from more of the free work done by the F/OSS crowd, etc. [0]: https://www.freecodecamp.org/news/react-shouldcomponentupdate-demystified-c5d323099ef6 https://www.freecodecamp.org/news/react-shouldcomponentupdat... [1]: https://backbonejs.org/#View https://backbonejs.org/#View [2]: https://github.com/MithrilJS/mithril.js/ https://github.com/MithrilJS/mithril.js/ [3]: https://github.com/MithrilJS/mithril.js/issues/1838 https://github.com/MithrilJS/mithril.js/issues/1838
- arcturus17 6y ago
  These points hardly justify how one could casually that drop React land is "crazy-sauce" while recommending NativeScript... There's quite a bit to address here: > Needing shouldComponentUpdate to do anything nontrivial I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you. > The sheer amount of times React has been basically rewritten I honestly wouldn't know or care if the library has been "rewritten", "extended" or "patched" or what they've done to the underlying code - because the core API has not really changed in years... Like I said, hooks extended the library and developers could transition at their own pace or not transition at all. > Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call. There are many React codebases that don't use Redux. But it's still a great state management library (or pattern) for moderately complex UIs. If you have your own state-management solution (including "simple AJAX calls", whatever that means in the context of Flux or state management), you can use it... > you can get reasonably productive and performant in <1 day after reading all the docs Ditto for React... Any semi-competent dev can be writing at least presentational components with basic network calls in a day... Moderately complex state management and asynchronous actions that affect state take longer to wrap your head around, but I doubt that Vue really simplifies this. UI programming can become naturally complex under certain requirements, and I doubt there is a framework that can completely abstract away this complexity. > Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day That's Create-React-App, which completely abstracts the need for pretty much everything except React-Router (10min to setup) and Redux (which nowadays you can substitute with plenty of alternatives). You can be writing business logic and views in 15 minutes, tops. And in a fair amount of cases, CRA stands the test of time, too: I've got code in production for very large customers using it and I know of startups that are building complex products in their second or third year of operations and haven't even ejected their app... > the amount of hype and OSS friendly companies Sure, there are network effects - popularity begets popularity. But surely a library or framework can't live on hype alone? Look at Angular... React also - mainly, rather - remains popular because it has seen significant improvements to its core and ecosystem.

hardwaresofton 6y ago

I wouldn't consider myself a React expert because I basically stopped using it or recommending it once Vue came out, but stuff like: - Needing shouldComponentUpdate to do anything nontrivial (it's a bad sign for what should be a library if people make "X demystified"[0] posts). - The sheer amount of times React has been basically rewritten, with - Hooks (to be fair Vue has this too, and it's not actually a bad feature, but as usual React introduced it in a near inscrutable way). - Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call. React had the initial idea, but it just feels like the stuff that came after (Vue in particular) delivered better on the simplicity we all wanted. There are so many little gotchas all over the place that people just paper over/memorize, when Vue 2/3 basically works as advertised right out of the box, need(ed?) less hacks, and you can get reasonably productive and performant in <1 day after reading all the docs. Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day. The combined complexity is not worth it when compared to Vue in my opinion. These days if I want to use something, I do vue + vue-router + parcel and call it a day, and get productive much quicker though the ecosystem isn't quite as big. For uber-simplicity I like mithril[2][3] though -- but it falls down when you start looking at advanced features like SSR/rehydration. React has the best third party support/ecosystem because of the amount of hype and OSS friendly companies that are using and benefiting from React. It also is the best corporate choice -- react developers are more fungible, you will benefit from more of the free work done by the F/OSS crowd, etc. [0]: https://www.freecodecamp.org/news/react-shouldcomponentupdate-demystified-c5d323099ef6 https://www.freecodecamp.org/news/react-shouldcomponentupdat... [1]: https://backbonejs.org/#View https://backbonejs.org/#View [2]: https://github.com/MithrilJS/mithril.js/ https://github.com/MithrilJS/mithril.js/ [3]: https://github.com/MithrilJS/mithril.js/issues/1838 https://github.com/MithrilJS/mithril.js/issues/1838

arcturus17 6y ago
These points hardly justify how one could casually that drop React land is "crazy-sauce" while recommending NativeScript... There's quite a bit to address here: > Needing shouldComponentUpdate to do anything nontrivial I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you. > The sheer amount of times React has been basically rewritten I honestly wouldn't know or care if the library has been "rewritten", "extended" or "patched" or what they've done to the underlying code - because the core API has not really changed in years... Like I said, hooks extended the library and developers could transition at their own pace or not transition at all. > Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call. There are many React codebases that don't use Redux. But it's still a great state management library (or pattern) for moderately complex UIs. If you have your own state-management solution (including "simple AJAX calls", whatever that means in the context of Flux or state management), you can use it... > you can get reasonably productive and performant in <1 day after reading all the docs Ditto for React... Any semi-competent dev can be writing at least presentational components with basic network calls in a day... Moderately complex state management and asynchronous actions that affect state take longer to wrap your head around, but I doubt that Vue really simplifies this. UI programming can become naturally complex under certain requirements, and I doubt there is a framework that can completely abstract away this complexity. > Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day That's Create-React-App, which completely abstracts the need for pretty much everything except React-Router (10min to setup) and Redux (which nowadays you can substitute with plenty of alternatives). You can be writing business logic and views in 15 minutes, tops. And in a fair amount of cases, CRA stands the test of time, too: I've got code in production for very large customers using it and I know of startups that are building complex products in their second or third year of operations and haven't even ejected their app... > the amount of hype and OSS friendly companies Sure, there are network effects - popularity begets popularity. But surely a library or framework can't live on hype alone? Look at Angular... React also - mainly, rather - remains popular because it has seen significant improvements to its core and ecosystem.