Redux is difficult. I will agree that Redux + React is difficult. However, React on it's own is far too simple compared to something like Angular for me to consider it "problematic" regarding it's usability. If anything, adding more features will only increase the difficulty of learning React. For instance, if Redux was React's default data store, I'd have to say that React is on par in difficulty to Angular.
Yeah, and that is a commonly recognized problem to many JS developers I interact with. React should be taught with mobx if you're trying to avoid difficulty
I've used React, React + Redux and Gatsby several times for freelance work, as I enjoy utilizing different technologies and keeping up-to-date on the newest tech. However, from a business standpoint, I've evaluated it at my current company and the last and just couldn't recommend its use to our stakeholders, unless the app would later become a native app and sharing code between React and React Native would be of benefit.
Personally, I'm a big fan of the React library, but most of us rarely work at large tech companies who have large teams of developers segregated to a specific side of the stack and nothing else. I've found it common at every company I've worked at for back end developers to work on the front end when fixing bugs or trying to get an MVP out where resources might be stretched thin. It's also these same developers who built all the "legacy" apps we, as front end devs, all dread to work on, with the spaghetti-code jQuery barely holding everything together.
To a beginner, or a developer not focused on the front end (especially those who learned JavaScript in ES5 and are baffled by all the functional syntax used in React examples), the React documentation is severely lacking and React's lack of structure is the quickest way back to the "wild west" of jQuery. Without significant planning and detail to development standards, a React project will fail or become unmaintainable as soon as it starts to grow in size.
Admittedly, I have no experience with Mobx. It's been on my list to learn, but all the recent React updates have had me at a loss of where to start learning. React's current problem is it's trying to solve too many issues and it's degrading the developer experience because of it, regardless of whether we bring in the ecosystem or not.
Aside from the main issues I've outlined previously, my main concern with bringing React to scale is its instability. I don't mean it's not stable at a functional level, but the team seems to have no idea what they want to do with it and just keep dumping more and more features on top of it to patch design flaws or add things 1% of people needed in the first place. That said - I'm pretty excited about a few of the newer features, just because of their ability to ditch Redux in many aspects... however, I'm not sure I agree with them being built into the library, as it creates even more confusion over the "right" way to do things when there's so many options.
Personally, I'm of the mind that state management and routing should be core functionality in React (not necessarily in the same package, though, because not everyone will need them). The React community is extremely vibrant and there's tons of awesome packages out there for just about anything you'd need, but the two most popular paired packages (Redux & ReactRouter) differ quite a bit from the core concepts of the React library and the simplicity of React is lost on them. Sure, you can choose different packages to replace them, but these are still community-driven and are likely highly susceptible to API instability from one version to the next, or come at the cost of being different than the "typical" React stack, thus having to spend more time ramping up new developers on your project than need be.
As a business choice, I'd be really curious to hear why developers not working at large tech companies would choose React for their team. I realize this is very much dependent on your specific team, but I'm curious, nonetheless, what advantages you felt React had over other options?
It's a good choice for business because: the talent is there, the support is good, there structure/arch doesn't inhibit growth, the componenttization is something occurring in every library and even native in browsers, the ability to make something that is bad is superior to the inability to make exactly what you want, and compared to other libraries, the modularity and choices it opens up are the most expansive.
Further, many of the arguments that are used against React could be used against any technology.
If you look at rigid frameworks like Angular as a "good idea" then, imo, maybe you should just use something like wix or WordPress.
As far as "instability", you don't have to use newer versions of React. However you should, because new features rarely break old code, but when they do there is almost always a way to adapt old code to run the newer version with little effort. Look at it this way: why would you update the version unless you hired a developer to do it, and why would you hire a developer unless you wanted some coding done?
A good example of how react is not the jQuery of our time is Preact. Another good example is Vue. Most frameworks are now copying React. jQuery was its own beast.
I'd also have to argue that React's docs are very thorough, you're just probably looking in the wrong place, or are expecting it to cover things that aren't handled by React. The fact that the docs aren't lengthy in places is a testament to how uncomplicated the idea is.
As far as "the quickest way back to the 'wild west' of jQuery", React encourages OOP, but if you decide to do it wrong or poorly then you could do that with almost any technology. I never make the argument "don't use databases because a person might not normalize correctly".
Lastly, if React included state management and routing, it would no longer be React. It would be something I would advise against using at that point, because it wouldn't handle one job perfectly (managing a view) but do multiple jobs in an opinionated way. The beauty of React is the ability to hone it into your needs. I personally don't use create-react-app anymore, and I rarely use Redux. I bundle with Parcel instead of webpack, and depending on the situation I might add a router or not. I don't ship extra code that isn't used. If React started including routers and state management, would we have to remove it if we didn't need to use it? That seems intrusive and unnecessary.
jQuery was never meant to do something conceptually new. jQuery was meant to copy the way DOM manipulation was already done and make the syntax easier and more convenient.
React is the thing that other libraries are copying, like how jQuery copied the DOM manipulation that was already built into the browser.
The fact that so many things are changing because of and evolving from React means that it is an advancement, and not just a library that "makes things easier".
@uniwrighte
- Definitely not looking at Angular as a good idea, though I do appreciate the slightly more structured code in something like Vue versus React (Angular has some cool concept, but it seems over-engineered for a lot of things). There's something to be said about structure within a codebase. Many people choose to use a framework because of:
The tools included that allow you to not have to reinvent the wheel on every new app, and
The established file structure and conventions that make anyone who knows the framework able to jump into a new project without any knowledge of it and instantly see what's going on
My comment about jQuery had nothing to do with its features and everything to do with its unstructured nature. While this makes it highly flexible, it also makes it easy to produce messy, unmaintainable code. With companies working in large teams of engineers that already have established style guides on how to produce React applications, using the library totally makes sense, but I've seen a lot of newer companies pick up React just because it's popular and lead themselves down the path of spaghetti code. I'm not saying React is a bad choice for small companies, but it definitely takes more planning before starting a large project than most other established libraries out there. You have to be diligent about setting up Higher-Order Components / Functional Components in order to not mix too much logic with your markup, otherwise it quickly becomes really hard to read.
Also, I completely agree with you on not including state management and routing in the base React library, which is what I said in the first place. My point is that I'd feel more comfortable using React on a larger project if there were officially supported packages for both of these. Using Vue as an example - Vuex seems like an extension of Vue itself when you add it to a project. Its concepts follow and enhance those of Vue, whereas Redux, while extremely powerful and IMO a better state management system for larger apps than Vuex because of its concept of immutability, increases the complexity of React ten-fold because it doesn't really adhere to the same simplicity as the base library. The same could be said about VueRouter vs React Router. Why they decided to remove the ability to define your routes as a JavaScript object in the new version baffles me. I get that JSX is a key concept of React, but I question the motives of a JS developer who would rather define routing logic in XML-like syntax, instead of JS/JSON notation. Weird. :P
I definitely won't contest that React and its ecosystem is pushing innovation faster than any other library/framework out there right now. They have a large team behind it that's dedicated to improving and innovating with it, so it doesn't surprise me, as it's backed by a company that uses it everywhere. The same can't be said about something like Angular where Google itself is so fragmented on their products - they have multiple UI libraries between the organization and also use React and others across several products. Without a single point of development, it'd be hard for them to push much on the innovation side, not to mention the companies mostly utilizing Angular are larger enterprise organizations who are notoriously slow to change. There are definitely a lot of cool things coming out of the React camp and I don't think they will cease to be the leader in many things in the future, but just because some libraries are copying things that React does, doesn't mean they aren't doing it better. It's a hard position for Facebook to be in - they are driving the innovation but others have the opportunity to learn from it and improve it, which is why I think we see new features to React so consistently, because they have to keep innovating to stay relevant with how fast the JS ecosystem moves.
With great power comes great responsibility I guess.
For me spagehtti code is when you consistently have to open 4 or 5 files to understand what is happening.
As an experienced React developer, I can read almost an code with accurately named components within a few minutes, and I usually can understand the strucure w/o opening more than one file.
Your App.js is the entry point, whatever you name it. Find that, and you know what the entire application does, unless someone intentionally made it harder for themselves. I don't have much experience with Angular, so I won't really try to compare, but I do know that other devs complain about sifting through boiler plate. With that said, I'm also sure there are some poorly designed Angular implementations out there.
As far as react-router-dom, the reason you would want XML for your routes is to make it more declarative with your components. Instead of reaching around to some function and tossing your components into it, you can just declare it directly.
If you wanted to do it out of JSX, then here:
const routes = [{comp: Comp, path: "/comp"})
and a one liner in render OR you could make a stateless functional component:
You can do it however you want, but the point is that it allows you to interact with the DOM via a logical abstraction instead of boxing you into a do-this do-that model like jQuery or possibly almost any framework with a rigid structure. If you think about it VanillaJS/jQuery are about is strict as it gets, because you have to declare every action (or try to work around that and build your own version of a view library).
P.S. don't know how the code will look on this platform, so thank you for bearing with me
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Redux is difficult. I will agree that Redux + React is difficult. However, React on it's own is far too simple compared to something like Angular for me to consider it "problematic" regarding it's usability. If anything, adding more features will only increase the difficulty of learning React. For instance, if Redux was React's default data store, I'd have to say that React is on par in difficulty to Angular.
So the "problem" is Redux and the fact that people tend to treat React and Redux as a package?
Yeah, and that is a commonly recognized problem to many JS developers I interact with. React should be taught with mobx if you're trying to avoid difficulty
I've used React, React + Redux and Gatsby several times for freelance work, as I enjoy utilizing different technologies and keeping up-to-date on the newest tech. However, from a business standpoint, I've evaluated it at my current company and the last and just couldn't recommend its use to our stakeholders, unless the app would later become a native app and sharing code between React and React Native would be of benefit.
Personally, I'm a big fan of the React library, but most of us rarely work at large tech companies who have large teams of developers segregated to a specific side of the stack and nothing else. I've found it common at every company I've worked at for back end developers to work on the front end when fixing bugs or trying to get an MVP out where resources might be stretched thin. It's also these same developers who built all the "legacy" apps we, as front end devs, all dread to work on, with the spaghetti-code jQuery barely holding everything together.
To a beginner, or a developer not focused on the front end (especially those who learned JavaScript in ES5 and are baffled by all the functional syntax used in React examples), the React documentation is severely lacking and React's lack of structure is the quickest way back to the "wild west" of jQuery. Without significant planning and detail to development standards, a React project will fail or become unmaintainable as soon as it starts to grow in size.
Admittedly, I have no experience with Mobx. It's been on my list to learn, but all the recent React updates have had me at a loss of where to start learning. React's current problem is it's trying to solve too many issues and it's degrading the developer experience because of it, regardless of whether we bring in the ecosystem or not.
Aside from the main issues I've outlined previously, my main concern with bringing React to scale is its instability. I don't mean it's not stable at a functional level, but the team seems to have no idea what they want to do with it and just keep dumping more and more features on top of it to patch design flaws or add things 1% of people needed in the first place. That said - I'm pretty excited about a few of the newer features, just because of their ability to ditch Redux in many aspects... however, I'm not sure I agree with them being built into the library, as it creates even more confusion over the "right" way to do things when there's so many options.
Personally, I'm of the mind that state management and routing should be core functionality in React (not necessarily in the same package, though, because not everyone will need them). The React community is extremely vibrant and there's tons of awesome packages out there for just about anything you'd need, but the two most popular paired packages (Redux & ReactRouter) differ quite a bit from the core concepts of the React library and the simplicity of React is lost on them. Sure, you can choose different packages to replace them, but these are still community-driven and are likely highly susceptible to API instability from one version to the next, or come at the cost of being different than the "typical" React stack, thus having to spend more time ramping up new developers on your project than need be.
As a business choice, I'd be really curious to hear why developers not working at large tech companies would choose React for their team. I realize this is very much dependent on your specific team, but I'm curious, nonetheless, what advantages you felt React had over other options?
It's a good choice for business because: the talent is there, the support is good, there structure/arch doesn't inhibit growth, the componenttization is something occurring in every library and even native in browsers, the ability to make something that is bad is superior to the inability to make exactly what you want, and compared to other libraries, the modularity and choices it opens up are the most expansive.
Further, many of the arguments that are used against React could be used against any technology.
If you look at rigid frameworks like Angular as a "good idea" then, imo, maybe you should just use something like wix or WordPress.
As far as "instability", you don't have to use newer versions of React. However you should, because new features rarely break old code, but when they do there is almost always a way to adapt old code to run the newer version with little effort. Look at it this way: why would you update the version unless you hired a developer to do it, and why would you hire a developer unless you wanted some coding done?
A good example of how react is not the jQuery of our time is Preact. Another good example is Vue. Most frameworks are now copying React. jQuery was its own beast.
I'd also have to argue that React's docs are very thorough, you're just probably looking in the wrong place, or are expecting it to cover things that aren't handled by React. The fact that the docs aren't lengthy in places is a testament to how uncomplicated the idea is.
As far as "the quickest way back to the 'wild west' of jQuery", React encourages OOP, but if you decide to do it wrong or poorly then you could do that with almost any technology. I never make the argument "don't use databases because a person might not normalize correctly".
Lastly, if React included state management and routing, it would no longer be React. It would be something I would advise against using at that point, because it wouldn't handle one job perfectly (managing a view) but do multiple jobs in an opinionated way. The beauty of React is the ability to hone it into your needs. I personally don't use create-react-app anymore, and I rarely use Redux. I bundle with Parcel instead of webpack, and depending on the situation I might add a router or not. I don't ship extra code that isn't used. If React started including routers and state management, would we have to remove it if we didn't need to use it? That seems intrusive and unnecessary.
What do you mean by that? Thank you!
jQuery was never meant to do something conceptually new. jQuery was meant to copy the way DOM manipulation was already done and make the syntax easier and more convenient.
React is the thing that other libraries are copying, like how jQuery copied the DOM manipulation that was already built into the browser.
The fact that so many things are changing because of and evolving from React means that it is an advancement, and not just a library that "makes things easier".
@uniwrighte - Definitely not looking at Angular as a good idea, though I do appreciate the slightly more structured code in something like Vue versus React (Angular has some cool concept, but it seems over-engineered for a lot of things). There's something to be said about structure within a codebase. Many people choose to use a framework because of:
The tools included that allow you to not have to reinvent the wheel on every new app, and
The established file structure and conventions that make anyone who knows the framework able to jump into a new project without any knowledge of it and instantly see what's going on
My comment about jQuery had nothing to do with its features and everything to do with its unstructured nature. While this makes it highly flexible, it also makes it easy to produce messy, unmaintainable code. With companies working in large teams of engineers that already have established style guides on how to produce React applications, using the library totally makes sense, but I've seen a lot of newer companies pick up React just because it's popular and lead themselves down the path of spaghetti code. I'm not saying React is a bad choice for small companies, but it definitely takes more planning before starting a large project than most other established libraries out there. You have to be diligent about setting up Higher-Order Components / Functional Components in order to not mix too much logic with your markup, otherwise it quickly becomes really hard to read.
Also, I completely agree with you on not including state management and routing in the base React library, which is what I said in the first place. My point is that I'd feel more comfortable using React on a larger project if there were officially supported packages for both of these. Using Vue as an example - Vuex seems like an extension of Vue itself when you add it to a project. Its concepts follow and enhance those of Vue, whereas Redux, while extremely powerful and IMO a better state management system for larger apps than Vuex because of its concept of immutability, increases the complexity of React ten-fold because it doesn't really adhere to the same simplicity as the base library. The same could be said about VueRouter vs React Router. Why they decided to remove the ability to define your routes as a JavaScript object in the new version baffles me. I get that JSX is a key concept of React, but I question the motives of a JS developer who would rather define routing logic in XML-like syntax, instead of JS/JSON notation. Weird. :P
I definitely won't contest that React and its ecosystem is pushing innovation faster than any other library/framework out there right now. They have a large team behind it that's dedicated to improving and innovating with it, so it doesn't surprise me, as it's backed by a company that uses it everywhere. The same can't be said about something like Angular where Google itself is so fragmented on their products - they have multiple UI libraries between the organization and also use React and others across several products. Without a single point of development, it'd be hard for them to push much on the innovation side, not to mention the companies mostly utilizing Angular are larger enterprise organizations who are notoriously slow to change. There are definitely a lot of cool things coming out of the React camp and I don't think they will cease to be the leader in many things in the future, but just because some libraries are copying things that React does, doesn't mean they aren't doing it better. It's a hard position for Facebook to be in - they are driving the innovation but others have the opportunity to learn from it and improve it, which is why I think we see new features to React so consistently, because they have to keep innovating to stay relevant with how fast the JS ecosystem moves.
With great power comes great responsibility I guess.
For me spagehtti code is when you consistently have to open 4 or 5 files to understand what is happening.
As an experienced React developer, I can read almost an code with accurately named components within a few minutes, and I usually can understand the strucure w/o opening more than one file.
Your App.js is the entry point, whatever you name it. Find that, and you know what the entire application does, unless someone intentionally made it harder for themselves. I don't have much experience with Angular, so I won't really try to compare, but I do know that other devs complain about sifting through boiler plate. With that said, I'm also sure there are some poorly designed Angular implementations out there.
As far as react-router-dom, the reason you would want XML for your routes is to make it more declarative with your components. Instead of reaching around to some function and tossing your components into it, you can just declare it directly.
If you wanted to do it out of JSX, then here:
const routes = [{comp: Comp, path: "/comp"})and a one liner in render OR you could make a stateless functional component:
{routes.map((route)=><Route path={route.path} component={route.comp}/>)}You can do it however you want, but the point is that it allows you to interact with the DOM via a logical abstraction instead of boxing you into a do-this do-that model like jQuery or possibly almost any framework with a rigid structure. If you think about it VanillaJS/jQuery are about is strict as it gets, because you have to declare every action (or try to work around that and build your own version of a view library).
P.S. don't know how the code will look on this platform, so thank you for bearing with me