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.
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