6 ms·

I'm a developer who primarily uses ReactJS for the front-end. I chose the library years ago because it just made sense to me. I really liked the syntax (JSX),

I'm a developer who primarily uses ReactJS for the front-end. I chose the library years ago because it just made sense to me. I really liked the syntax (JSX), the lifecycle methods and the quick hot reloads. The only thing at the time that I really didn't like was the build system (browserify, gulp, webpack, babel, etc) as I found it overly complicated. Now all of that is basically invisible with "create-react-app" and I can just get right to building applications in seconds - life is pretty good. With each React update however, I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. I worry that it will become just another bloated "framework" with unnecessary complexity and drive me into the lighter weight and more focused alternatives such as VueJS or Svelte. Perhaps the React team is getting bored? IMO I'd like to see a base ReactJS with these advanced features being add-ons in some fashion. Keep the version I like to use lean and the complexity just where I like it.

PKop 7y ago
> I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. It is. Because through experience developers realized these concerns need to be addressed, and handled... by something. It is unavoidable to have a useful application. Having the framework integrated to help you do so is much less painful than piecing together separate tools, or having 20 different libraries construct their own way to do so (if it is solveable in a uniform way that simply needs to be advocated and agreed upon). But in any case, why can't you just not use them? What is the pain point caused by ignoring the changes... and choosing separate tools to solve these problems if that's what you prefer?
- jabits 7y ago
  Well, with any large, complex system, you have to learn enough about everything to know what not to use. I have been developing applications of many types for decades and it seems every time I look at react (I am responsible for one production react app that I did not write) it seems there is some new major change on how to approach the entire framework...it's daunting. And with all the constant changes to the main underlying technologies (HTML, CSS and JavaScript), it's even more so...
- runawaybottle 7y ago
  If the Jquery authors said ‘if u don’t like sizzle selector, feel free to use standard dom functions to grab your elements’ We’d all be pissed if the sizzle selector wasn’t awesome and well thought out api. What I keep seeing with React is really bad api design with things like hooks (because classes are so complicated, someone link that documentation post) and redux is horrific boilerplate to manage global state. Ok no problem, don’t use it. Discourse ends there right? No I’m sorry, reducers, hooks, ‘suspense’ stuff is not intuitive. This needs to be properly discussed. Can I possibly even start the discussion at why the hell these things are being named in this way? Is that not a start? Functions and Classes are stupid? A debounce function that’s possibly a promise, stuff we know about, is suddenly like the ‘suspense’ api? Does any thought go into this anymore for how average developers have to approach this horseshit?
  - DCoder 7y ago
    > Can I possibly even start the discussion at why the hell these things are being named in this way? This reminds me a lot of Perl with its creative naming for things, e.g. promises giving you a `Vow` object that you can `keep()` or `break()`. Or how you `bless` an associative array into becoming an object of a certain class. On the one hand, it is good to have precise and specific terms without reaching for a thesaurus or overloading the same term (e.g. the many meanings of `static` in C). On the other hand, if every framework and language invents its own terms for everything under the sun, that will not help polyglots or newcomers. (On the third hand, we have foreigners trying to spot a difference between a "promise" and a "vow".) Promises are my favourite example of this, because just between C++, C#, JavaScript, and Perl, I can find three-and-a-half different taxonomies for the same functionality.
  - marcoseliziario 7y ago
    Those are advanced resources. For what they do, they are pretty straightforward, but if you are just starting, you don't need to care about reducers, hooks, suspense. You don't even need to do a SPA to take advantage of react, thus, you don't even need a router to start.
    - 7y ago
tanilama 7y ago
As with all packages. They started slim and nimble, but the scope grows, it gets heavy and bloated. React used to be great, and to some degree it still is, but somehow its contributor has a vision to make it our generation's J2EE, which IMO, is due to be hated by a lot of people, including me.
- frosted-flakes 7y ago
  Except React is a lot more slim than it used to be.
huy-nguyen 7y ago
The important thing to remember here is that you don't have to use all of these newfangled features. As stated in the write up, these are primitives for library developers (e.g. apollo-graphql) to build on top of. The only real development that affects end-users in the past year or so is the migration to function components but even then, you can keep using class components (although you do have to rename some method names but even then, the React team provides automatic codemods for that).
- vast 7y ago
  "You don't have to use it" is a very common statement when a part of the userbase battles feature creep, complexity or just bad decisions. And it is always a lie. Most projects are driven by collectives or passed to new maintainers, which naturally takes this choice away from you. Optional is never optional.
- com2kid 7y ago
  > The only real development that affects end-users in the past year or so is the migration to function components Except for those of us using React Native, where functional components break live editing! Thankfully a fix for that is coming soon, in a other 2 or 3 months maybe I can start using hooks... :/
schneidmaster 7y ago
> IMO I'd like to see a base ReactJS with these advanced features being add-ons in some fashion. Keep the version I like to use lean and the complexity just where I like it. I actually think this is pretty much exactly what the React team has done. They've made very few breaking changes over time; you can still use mixins, React.createClass, and most of the other syntax from 2015 if you really want to. You don't have to use hooks, suspense, or any of the other new features, and they've been quite explicit about their commitment to avoiding churn (because Facebook's codebase also has tons of legacy components that they don't want to rewrite either). Or if your argument is just that you should have an option to use a React bundle that is smaller in size and excludes the new functionality -- React as a library is actually significantly smaller than it was in earlier versions [0]. They've applied a lot of learnings and improved the architecture over time, such that the framework is faster and leaner under the hood despite still supporting the same legacy APIs. For what it's worth, I don't think the React team is bored; I think they're trying to conceive of frontend engineering as something more holistic than just the view layer. For example, old-school React is great for encapsulating and reusing bits of view as components, but how do we encapsulate and reuse bits of business logic or interactions? With hooks. How do I compose together my components to give a seamless loading experience, rather than a bunch of spinners and holes in the UI? With suspense. They're not really diverging from a view layer, just thinking at a higher level about how a view is engineered and how to provide primitives and abstractions that make it easy to build a good, complete UX (not just layout). [0]: https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d
- bihnkim 7y ago
  > They're not really diverging from a view layer, just thinking at a higher level about how a view is engineered and how to provide primitives and abstractions that make it easy to build a good, complete UX (not just layout). Thank you for this eloquent wording, you've saved me a lot of time and energy in my responses to people who don't get this point.
_bxg1 7y ago
> With each React update however, I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. Overall I'd agree, but I don't think concurrent mode falls into that category. It really is a view-layer thing, and it's something that's not really feasible to do from the outside (unlike, say, state management).
- Phillips126 7y ago
  In this situation yes, the concurrent mode does feel like a view-layer thing. I just don't want the future of ReactJS to look something like Angular 1 - which may never happen. I just worry that someday the team may decide maybe they should start moving in that direction.
leerob 7y ago
> Perhaps the React team is getting bored? No, you're just not solving problems at the scale Facebook is. You probably don't need to use Suspense.
- Phillips126 7y ago
  That is true, the applications I build are typically internal business use only and have relatively low number of concurrent users. I just don't want React to suffer from any scope-creep and become the next "do everything" Angular 1 was - which was a nightmare I had to suffer through for a while. While this likely wont ever happen, it's always something I worry about. When you love something you use daily, change is hard (but improvements are always welcome - which this feature could be).
deleted 7y ago
[deleted]
tuesdayrain 7y ago
Vue 2 has honestly been my favorite developer experience of all time, but they're basically turning into a slightly different flavor of React with Vue 3.0 in my opinion. The current API will continue to be officially supported, although I don't expect the same to be true for community docs/tutorials/libraries. So I'm in the process of converting my Vue apps to React.
- Phillips126 7y ago
  That is interesting. I know Vue 2 had a huge community of very pleased users but I have not been following the developments of Vue 3. This is basically the general fear I have with React. While there really hasn't been any conversations that I am aware of talking about going beyond the view-layer, I don't want it to be the next Angular 1 which made me want to pull my hair out constantly.
watt3rpig 7y ago
Agreed. I loved React and now only like it. The app I work on at work is an absolute monstrosity with render props and context. You can say oh don’t use if you don’t like it! But in the real world you are forced to use others code.

PKop 7y ago

> I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. It is. Because through experience developers realized these concerns need to be addressed, and handled... by something. It is unavoidable to have a useful application. Having the framework integrated to help you do so is much less painful than piecing together separate tools, or having 20 different libraries construct their own way to do so (if it is solveable in a uniform way that simply needs to be advocated and agreed upon). But in any case, why can't you just not use them? What is the pain point caused by ignoring the changes... and choosing separate tools to solve these problems if that's what you prefer?

jabits 7y ago
Well, with any large, complex system, you have to learn enough about everything to know what not to use. I have been developing applications of many types for decades and it seems every time I look at react (I am responsible for one production react app that I did not write) it seems there is some new major change on how to approach the entire framework...it's daunting. And with all the constant changes to the main underlying technologies (HTML, CSS and JavaScript), it's even more so...
runawaybottle 7y ago
If the Jquery authors said ‘if u don’t like sizzle selector, feel free to use standard dom functions to grab your elements’ We’d all be pissed if the sizzle selector wasn’t awesome and well thought out api. What I keep seeing with React is really bad api design with things like hooks (because classes are so complicated, someone link that documentation post) and redux is horrific boilerplate to manage global state. Ok no problem, don’t use it. Discourse ends there right? No I’m sorry, reducers, hooks, ‘suspense’ stuff is not intuitive. This needs to be properly discussed. Can I possibly even start the discussion at why the hell these things are being named in this way? Is that not a start? Functions and Classes are stupid? A debounce function that’s possibly a promise, stuff we know about, is suddenly like the ‘suspense’ api? Does any thought go into this anymore for how average developers have to approach this horseshit?
- DCoder 7y ago
  > Can I possibly even start the discussion at why the hell these things are being named in this way? This reminds me a lot of Perl with its creative naming for things, e.g. promises giving you a `Vow` object that you can `keep()` or `break()`. Or how you `bless` an associative array into becoming an object of a certain class. On the one hand, it is good to have precise and specific terms without reaching for a thesaurus or overloading the same term (e.g. the many meanings of `static` in C). On the other hand, if every framework and language invents its own terms for everything under the sun, that will not help polyglots or newcomers. (On the third hand, we have foreigners trying to spot a difference between a "promise" and a "vow".) Promises are my favourite example of this, because just between C++, C#, JavaScript, and Perl, I can find three-and-a-half different taxonomies for the same functionality.
- marcoseliziario 7y ago
  Those are advanced resources. For what they do, they are pretty straightforward, but if you are just starting, you don't need to care about reducers, hooks, suspense. You don't even need to do a SPA to take advantage of react, thus, you don't even need a router to start.
  - 7y ago

tanilama 7y ago

As with all packages. They started slim and nimble, but the scope grows, it gets heavy and bloated. React used to be great, and to some degree it still is, but somehow its contributor has a vision to make it our generation's J2EE, which IMO, is due to be hated by a lot of people, including me.

frosted-flakes 7y ago
Except React is a lot more slim than it used to be.

huy-nguyen 7y ago

The important thing to remember here is that you don't have to use all of these newfangled features. As stated in the write up, these are primitives for library developers (e.g. apollo-graphql) to build on top of. The only real development that affects end-users in the past year or so is the migration to function components but even then, you can keep using class components (although you do have to rename some method names but even then, the React team provides automatic codemods for that).

vast 7y ago
"You don't have to use it" is a very common statement when a part of the userbase battles feature creep, complexity or just bad decisions. And it is always a lie. Most projects are driven by collectives or passed to new maintainers, which naturally takes this choice away from you. Optional is never optional.
com2kid 7y ago
> The only real development that affects end-users in the past year or so is the migration to function components Except for those of us using React Native, where functional components break live editing! Thankfully a fix for that is coming soon, in a other 2 or 3 months maybe I can start using hooks... :/

schneidmaster 7y ago

> IMO I'd like to see a base ReactJS with these advanced features being add-ons in some fashion. Keep the version I like to use lean and the complexity just where I like it. I actually think this is pretty much exactly what the React team has done. They've made very few breaking changes over time; you can still use mixins, React.createClass, and most of the other syntax from 2015 if you really want to. You don't have to use hooks, suspense, or any of the other new features, and they've been quite explicit about their commitment to avoiding churn (because Facebook's codebase also has tons of legacy components that they don't want to rewrite either). Or if your argument is just that you should have an option to use a React bundle that is smaller in size and excludes the new functionality -- React as a library is actually significantly smaller than it was in earlier versions [0]. They've applied a lot of learnings and improved the architecture over time, such that the framework is faster and leaner under the hood despite still supporting the same legacy APIs. For what it's worth, I don't think the React team is bored; I think they're trying to conceive of frontend engineering as something more holistic than just the view layer. For example, old-school React is great for encapsulating and reusing bits of view as components, but how do we encapsulate and reuse bits of business logic or interactions? With hooks. How do I compose together my components to give a seamless loading experience, rather than a bunch of spinners and holes in the UI? With suspense. They're not really diverging from a view layer, just thinking at a higher level about how a view is engineered and how to provide primitives and abstractions that make it easy to build a good, complete UX (not just layout). [0]: https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d

bihnkim 7y ago
> They're not really diverging from a view layer, just thinking at a higher level about how a view is engineered and how to provide primitives and abstractions that make it easy to build a good, complete UX (not just layout). Thank you for this eloquent wording, you've saved me a lot of time and energy in my responses to people who don't get this point.

_bxg1 7y ago

> With each React update however, I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. Overall I'd agree, but I don't think concurrent mode falls into that category. It really is a view-layer thing, and it's something that's not really feasible to do from the outside (unlike, say, state management).

Phillips126 7y ago
In this situation yes, the concurrent mode does feel like a view-layer thing. I just don't want the future of ReactJS to look something like Angular 1 - which may never happen. I just worry that someday the team may decide maybe they should start moving in that direction.

leerob 7y ago

> Perhaps the React team is getting bored? No, you're just not solving problems at the scale Facebook is. You probably don't need to use Suspense.

Phillips126 7y ago
That is true, the applications I build are typically internal business use only and have relatively low number of concurrent users. I just don't want React to suffer from any scope-creep and become the next "do everything" Angular 1 was - which was a nightmare I had to suffer through for a while. While this likely wont ever happen, it's always something I worry about. When you love something you use daily, change is hard (but improvements are always welcome - which this feature could be).

deleted 7y ago

[deleted]

tuesdayrain 7y ago

Vue 2 has honestly been my favorite developer experience of all time, but they're basically turning into a slightly different flavor of React with Vue 3.0 in my opinion. The current API will continue to be officially supported, although I don't expect the same to be true for community docs/tutorials/libraries. So I'm in the process of converting my Vue apps to React.

Phillips126 7y ago
That is interesting. I know Vue 2 had a huge community of very pleased users but I have not been following the developments of Vue 3. This is basically the general fear I have with React. While there really hasn't been any conversations that I am aware of talking about going beyond the view-layer, I don't want it to be the next Angular 1 which made me want to pull my hair out constantly.

watt3rpig 7y ago

Agreed. I loved React and now only like it. The app I work on at work is an absolute monstrosity with render props and context. You can say oh don’t use if you don’t like it! But in the real world you are forced to use others code.