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