Opinionated Comparison of React, Angular2, and Aurelia(github.com)
github.com
Opinionated Comparison of React, Angular2, and Aurelia
https://github.com/stickfigure/blog/wiki/Opinionated-Comparison-of-React%2C-Angular2%2C-and-Aurelia
168 comments
> The beauty of React is that it forces you to think in a slightly different way. Vue seemed more accessible for a spaghetti code writer
This has been my experience too with React and Vuejs. React requires thorough planning beforehand to write good code. You need to plan the parent-children structure before you jump in. It's easy to write shitty code in react too if you jump in headfirst; resulting in the kind of "enterprise boilerplate" others are talking about in this thread. Personally, I am happy with React at the moment (and React Fiber let's you return an array of components, so no more wrapping your components around a span - yay!).
This has been my experience too with React and Vuejs. React requires thorough planning beforehand to write good code. You need to plan the parent-children structure before you jump in. It's easy to write shitty code in react too if you jump in headfirst; resulting in the kind of "enterprise boilerplate" others are talking about in this thread. Personally, I am happy with React at the moment (and React Fiber let's you return an array of components, so no more wrapping your components around a span - yay!).
I haven't tried React but I felt the complete opposite with Vue. I've never written more beautiful front-end code than what I've done in Vue. Did you use .vue files? Did you use a proper state tree like Vuex?
Isnt Redux about using components to dispatch actions, and all the logic happens in the reducers for the store? So, the Model part is not inside the react view components which are just used for display. If you have uncontrolled components(React terminology for forms with extra data not handled by props), then form validation might require some processing in the components.
Partially, you're right. Some logic happen in reducers, but not all, because they must be pure. For example, you can't call new Date() in a reducer, because it's not pure.
Imagine you have a TodoList with Items that have: a priority and a createdDate. TodoList is always sorted by 'priority, created DESC'. There's also an email service that gives you a high-level overview of the TodoList like so:
So, your business logic is like this:
If a user creates a new TodoItem:
- You need to get the current date (unpure, so this must come from an action creator [1])
- You must update the "entity" of TodoList and sort and recalculate its summary
- This summary must be send out as an email
Or to sum it up: You have an action that triggers a bunch of totally unrelated side effects. This has nothing to do with the state of the View, which Redux manages. But it's still important business logic to this app.
The question now is: How do you manage that? Because this clearly must be outside of React and Redux. Some people just slap other libraries on top, but I never found a satisfactory explanation on how to implement such workflows "properly".
Too many tutorials are way too simple and gloss over these details.
[1]: http://stackoverflow.com/a/34135166/
Imagine you have a TodoList with Items that have: a priority and a createdDate. TodoList is always sorted by 'priority, created DESC'. There's also an email service that gives you a high-level overview of the TodoList like so:
High Prio (3 items)
Mid Prio (1 item)
Low Prio (0 items)
Total: 4 items, last created: 2017-04-07 11:38
So, your business logic is like this:
If a user creates a new TodoItem:
- You need to get the current date (unpure, so this must come from an action creator [1])
- You must update the "entity" of TodoList and sort and recalculate its summary
- This summary must be send out as an email
Or to sum it up: You have an action that triggers a bunch of totally unrelated side effects. This has nothing to do with the state of the View, which Redux manages. But it's still important business logic to this app.
The question now is: How do you manage that? Because this clearly must be outside of React and Redux. Some people just slap other libraries on top, but I never found a satisfactory explanation on how to implement such workflows "properly".
Too many tutorials are way too simple and gloss over these details.
[1]: http://stackoverflow.com/a/34135166/
It's 100% Redux ecosystem responsibility to perform the actions you want. I understand where you come from, as you perfectly described a procedure and it sounds natural to think that way. Redux and Event sourcing systems force you to decompose in 3 functions this procedure
- Action creator: the action creator newTodo() creates an action = {type: 'new', body = 'yo', date: new Date()}. This action creator can be colocated in the reducer file.
- Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting. A selector is a function that takes a part of the state as an input and return a new datastructure. Use reselect if you have perf concerns and want to persist it. It can be colocated code wise with the reducer file.
- Saga: for the side effects of sending an email, we use Redux Saga for ol' REST based endpoints. Those can be colocated code wise with the reducer file.
So yes you have 4 functions for your todo business logic: some action creators, some selectors, some sagas and the reducer. They can all be in the same file. It takes a bit of practice to figure out what is the right cut-off point. But all in all, interns and old farts like me all grasped it way more easily than Angular 1 scope concept for a more rewarding value.
- Action creator: the action creator newTodo() creates an action = {type: 'new', body = 'yo', date: new Date()}. This action creator can be colocated in the reducer file.
- Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting. A selector is a function that takes a part of the state as an input and return a new datastructure. Use reselect if you have perf concerns and want to persist it. It can be colocated code wise with the reducer file.
- Saga: for the side effects of sending an email, we use Redux Saga for ol' REST based endpoints. Those can be colocated code wise with the reducer file.
So yes you have 4 functions for your todo business logic: some action creators, some selectors, some sagas and the reducer. They can all be in the same file. It takes a bit of practice to figure out what is the right cut-off point. But all in all, interns and old farts like me all grasped it way more easily than Angular 1 scope concept for a more rewarding value.
This is helpful, thank you. One note:
> Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting.
Yes, I read about that before. Don't put in the store what can be computed. But in my case, this isn't used in a view, but in a separate "object" that can be shared with others without sharing the underlying data. So, while the report attributes are all computed, they must be stored somewhere for later individual retrieval.
Anyways, could you please clarify this:
> So yes you have 4 functions for your todo business logic
Where do I bundle these 4 functions so that they're called always in the same order?
> It takes a bit of practice to figure out what is the right cut-off point.
Yes, that's my struggle right now ;)
> Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting.
Yes, I read about that before. Don't put in the store what can be computed. But in my case, this isn't used in a view, but in a separate "object" that can be shared with others without sharing the underlying data. So, while the report attributes are all computed, they must be stored somewhere for later individual retrieval.
Anyways, could you please clarify this:
> So yes you have 4 functions for your todo business logic
Where do I bundle these 4 functions so that they're called always in the same order?
> It takes a bit of practice to figure out what is the right cut-off point.
Yes, that's my struggle right now ;)
The common solution seems to be using redux-thunk to shoehorn all of this business logic into the action creators. I think that's an absolutely terrible idea. IMO redux-thunk muddies up the terms "dispatch" and "action creator" and essentially creates a huge noob trap where new programmers don't even know what an action creator is anymore and they use the wrong terminology for everything.
Having said that, I think the thunk pattern is a fantastic solution. The two things the business logic functions need to do their job are dispatch, and the state, and the way redux-thunk does it with dependency injection makes your business logic functions very easy to test.
If somebody can come up with a solution with the same principle but without the absolutely moronic overloading of terms that people somehow find acceptable about redux-thunk, then they'll be onto a winner.
Having said that, I think the thunk pattern is a fantastic solution. The two things the business logic functions need to do their job are dispatch, and the state, and the way redux-thunk does it with dependency injection makes your business logic functions very easy to test.
If somebody can come up with a solution with the same principle but without the absolutely moronic overloading of terms that people somehow find acceptable about redux-thunk, then they'll be onto a winner.
Thanks for the input. This reflects what my problem is as a beginner with all this stuff: Where do I actually put everything? There's no universal answer of course, but this is why I (and certainly many others) feel intimidated by the JS ecosystem as a whole.
The Redux FAQ has a related entry: http://redux.js.org/docs/faq/CodeStructure.html#structure-bu... .
Out of curiosity, could you give me some examples of what you view as "business logic", and what troubles you're having placing that into a React+Redux app?
(Also worth noting that BigJono and I debated the merits of redux-thunk in another recent thread: https://news.ycombinator.com/item?id=13987613 ).
Out of curiosity, could you give me some examples of what you view as "business logic", and what troubles you're having placing that into a React+Redux app?
(Also worth noting that BigJono and I debated the merits of redux-thunk in another recent thread: https://news.ycombinator.com/item?id=13987613 ).
Thanks for the link. Business logic, to me, is: 1. Make sure that domain rules are enforced and keep data consistent. 2. For every use case, always trigger the same sequence of actions (behavior and side effects).
Imagine a fitness app where you can enter workouts and how much water you drank. You may enter only one workout per day (rule) and you cannot enter more than 1 gallon of water (rule). When you add a workout (behavior & side effects): the weather API is called and the current weather is added to the workout, the workout is stored in the DB, some calculated statistics are updated, your public "progress report card" is updated, you get a "good job!" push notification.
In my PHP OOP spaghetti approach, I might create an AddWorkoutCommand that executes() these actions by calling a bunch of other functions in other objects and trigger an event for optional listeners/actions. With Redux, not everything is in the same store (or in the store at all) and I don't even know where to start. It feels like this doesn't have anything to do with Redux, because it's partially not even state/view-related.
Maybe I'm overthinking this, but I do have a hard time finding a good tutorial that shows how to work with behavior and rules that goes beyond "add this item to the todo array".
Imagine a fitness app where you can enter workouts and how much water you drank. You may enter only one workout per day (rule) and you cannot enter more than 1 gallon of water (rule). When you add a workout (behavior & side effects): the weather API is called and the current weather is added to the workout, the workout is stored in the DB, some calculated statistics are updated, your public "progress report card" is updated, you get a "good job!" push notification.
In my PHP OOP spaghetti approach, I might create an AddWorkoutCommand that executes() these actions by calling a bunch of other functions in other objects and trigger an event for optional listeners/actions. With Redux, not everything is in the same store (or in the store at all) and I don't even know where to start. It feels like this doesn't have anything to do with Redux, because it's partially not even state/view-related.
Maybe I'm overthinking this, but I do have a hard time finding a good tutorial that shows how to work with behavior and rules that goes beyond "add this item to the todo array".
I could picture handling that kind of thing several different ways.
First, the UI may want to prevent the user from being able to hit "Add" or something if a workout already exists for that day. The component could use a selector to determine if there's an existing workout, return the flag in `mapState`, and disable buttons or forms appropriately.
Second, the action creation logic could decide to not actually dispatch an `ADD_WORKOUT` action by inspecting the current state and only dispatching the action if allowed. (I have some relevant examples of redux-thunk use cases like this at [0]).
Third, the action could get always dispatched, but the reducer could make the decision whether to actually insert the proposed workout into state.
Regarding the side effects, this is a good use case for "sagas". Dispatch an `ADD_WORKOUT` action that triggers a saga, but is ignored by the reducers. The root saga kicks off a child saga when it sees that action. The workout saga could then decide whether it needs to actually add the workout based on state, dispatch another action that actually updates the state, make the AJAX call for weather and persist it to the server, and trigger a push notification. (You can do same thing in a thunk, it just would need explicit promise usage rather than the synchronous-looking code of a generator-based saga.)
Lastly, this isn't a direct answer to your question, but you may be interested in some of the more in-depth Redux tutorials I've collected. They're in the 'Redux Tutorials#Project-Based Tutorials" section of my links list [1]. In particular, I recommend "Building a Simple CRUD App with Redux" [2], and my own "Practical Redux" series [3].
Hopefully this gives you some ideas. I'd also invite you to come ask questions in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Great place to hang out, learn, and discuss React + related topics.
[0] https://gist.github.com/markerikson/ea4d0a6ce56ee479fe8b356e...
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] http://www.thegreatcodeadventure.com/building-a-simple-crud-...
[3] http://blog.isquaredsoftware.com/series/practical-redux/
First, the UI may want to prevent the user from being able to hit "Add" or something if a workout already exists for that day. The component could use a selector to determine if there's an existing workout, return the flag in `mapState`, and disable buttons or forms appropriately.
Second, the action creation logic could decide to not actually dispatch an `ADD_WORKOUT` action by inspecting the current state and only dispatching the action if allowed. (I have some relevant examples of redux-thunk use cases like this at [0]).
Third, the action could get always dispatched, but the reducer could make the decision whether to actually insert the proposed workout into state.
Regarding the side effects, this is a good use case for "sagas". Dispatch an `ADD_WORKOUT` action that triggers a saga, but is ignored by the reducers. The root saga kicks off a child saga when it sees that action. The workout saga could then decide whether it needs to actually add the workout based on state, dispatch another action that actually updates the state, make the AJAX call for weather and persist it to the server, and trigger a push notification. (You can do same thing in a thunk, it just would need explicit promise usage rather than the synchronous-looking code of a generator-based saga.)
Lastly, this isn't a direct answer to your question, but you may be interested in some of the more in-depth Redux tutorials I've collected. They're in the 'Redux Tutorials#Project-Based Tutorials" section of my links list [1]. In particular, I recommend "Building a Simple CRUD App with Redux" [2], and my own "Practical Redux" series [3].
Hopefully this gives you some ideas. I'd also invite you to come ask questions in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Great place to hang out, learn, and discuss React + related topics.
[0] https://gist.github.com/markerikson/ea4d0a6ce56ee479fe8b356e...
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] http://www.thegreatcodeadventure.com/building-a-simple-crud-...
[3] http://blog.isquaredsoftware.com/series/practical-redux/
Just to be clear, I wasn't debating the merits of thunks, I love the pattern. I was just questioning the decision to use redux middleware to implement them. Redux-thunk action creators do not return an action. It's a misnomer to call them action creators.
Redux reducers don't manage the state of the view, but of the app. Redux state is the "M" in MVC; Redux action creators are the "C".
The view's job is to display the current state, translating it into something presentable. Views call action creators to request changes to the state, or to report events that action creators should use to make changes to the state. Action creators implement business logic.
Edit: To be clear, this doesn't mean you have to do logic in action creators. You can keep action creators "pure" (not thunked), and instead have a business logic layer that mediated between view and action dispatching. Saga is one way of doing this. Redux doesn't mandate anything specific.
Reducers are a way to serialize the state so that all state transitions happen as a strictly sequential chain of modifications. This is done to prevent the spaghetti mess you get when (as in traditional MVC systems like Cocoa) everyone is allowed modify the state directly, and views merely observe state. By flowing state through a single bottleneck, there's only one moment when the UI needs to transition to a new state. With observation-based systems, it's completely unpredictable and certainly not reversible.
React components do of course also have something called "state", but you have to think of that as the UI state, i.e. things needed to manage the view, such as whether a dropdown is open or what the current text of an input is.
There's also the temptation to put UI-specific state in Redux. This is perfectly normal, and even desirable. The "M" in MVC is not some abstract ivory-tower notion that there exists some world state that's entirely independent of the view. The state serves the view; whatever the view needs must be provided by the state.
The view's job is to display the current state, translating it into something presentable. Views call action creators to request changes to the state, or to report events that action creators should use to make changes to the state. Action creators implement business logic.
Edit: To be clear, this doesn't mean you have to do logic in action creators. You can keep action creators "pure" (not thunked), and instead have a business logic layer that mediated between view and action dispatching. Saga is one way of doing this. Redux doesn't mandate anything specific.
Reducers are a way to serialize the state so that all state transitions happen as a strictly sequential chain of modifications. This is done to prevent the spaghetti mess you get when (as in traditional MVC systems like Cocoa) everyone is allowed modify the state directly, and views merely observe state. By flowing state through a single bottleneck, there's only one moment when the UI needs to transition to a new state. With observation-based systems, it's completely unpredictable and certainly not reversible.
React components do of course also have something called "state", but you have to think of that as the UI state, i.e. things needed to manage the view, such as whether a dropdown is open or what the current text of an input is.
There's also the temptation to put UI-specific state in Redux. This is perfectly normal, and even desirable. The "M" in MVC is not some abstract ivory-tower notion that there exists some world state that's entirely independent of the view. The state serves the view; whatever the view needs must be provided by the state.
"The main advantage of React over Vue and Angular is: React Native. Vue doesn't have anything close to it."
I haven't tried it, because the components don't look native. Buttons with text that have a shadow? What on earth is that? It looks less polished than Ionic and suffers the same problems of all Cordova-based hybrid apps: No native input controls. For me, this is a dealbreaker.
Cordova is all about plugins. You can use a native datepicker plugin for example.
If you need native functionality, use a plugin. (there's probably one already there, but maybe you need to write a tiny bit of native code).
I guess that's the whole point of hybrid that people don't understand - it's a hybrid, and you get to choose the best of both, making the trade offs you need to make for the best result.
Not ideal for every app/budget, but I think people just don't get this part - use the native plugins if you need them! :)
Ship fast, and slowly replace all the bits with native (if you need to). [fast|cheap|good] pick two! (then the third).
If you need native functionality, use a plugin. (there's probably one already there, but maybe you need to write a tiny bit of native code).
I guess that's the whole point of hybrid that people don't understand - it's a hybrid, and you get to choose the best of both, making the trade offs you need to make for the best result.
Not ideal for every app/budget, but I think people just don't get this part - use the native plugins if you need them! :)
Ship fast, and slowly replace all the bits with native (if you need to). [fast|cheap|good] pick two! (then the third).
So, the idea of Ionic/Cordova is: You can release an app without writing native code. Your suggestions certainly work, but they bring up questions:
- How do I write the native code you mentioned?
- How do I plugin the native datepicker in Ionic?
- How do I deal with different native plugins for iOS and Android?
I bet there are solutions for all of these problems, but then again, I might just want to consider React Native, because Ionic doesn't bring any more benefits over React Native.
With Hybrid, it's all a compromise, and it might be worth it. That's not my point. My point is: Don't use Ionic/web-based hybrid, if native input controls play an important part in your app. It might simply not be worth it, because there are better tools to achieve the same outcome.
- How do I write the native code you mentioned?
- How do I plugin the native datepicker in Ionic?
- How do I deal with different native plugins for iOS and Android?
I bet there are solutions for all of these problems, but then again, I might just want to consider React Native, because Ionic doesn't bring any more benefits over React Native.
With Hybrid, it's all a compromise, and it might be worth it. That's not my point. My point is: Don't use Ionic/web-based hybrid, if native input controls play an important part in your app. It might simply not be worth it, because there are better tools to achieve the same outcome.
The datepicker native input plugin exists, so it's just installing it. Then you get a JS api for it.
If it doesn't exist somewhere in the thousands of plugins available, you'll have to make it yourself. The other thing that happens, is perhaps a plugin is only available for Android. Maybe there's another one with a slightly different JS api for iOS... or none.
I've also done emscripten compiled C++ mixed in there. Which replaced various native apps. Since it was mostly OpenGL anyway... the few controls were easily implemented in JS/Html.
Anyway... just trying to share some options. Lots of native cordova plugins available (which I guess is it's main point). I really don't care what other people do... and somehow got drawn in to this discussion again!
If it doesn't exist somewhere in the thousands of plugins available, you'll have to make it yourself. The other thing that happens, is perhaps a plugin is only available for Android. Maybe there's another one with a slightly different JS api for iOS... or none.
I've also done emscripten compiled C++ mixed in there. Which replaced various native apps. Since it was mostly OpenGL anyway... the few controls were easily implemented in JS/Html.
Anyway... just trying to share some options. Lots of native cordova plugins available (which I guess is it's main point). I really don't care what other people do... and somehow got drawn in to this discussion again!
Thanks for the suggestions. While trying Ionic, I didn't install Cordova plugins to fine-tune input control. I will give it another shot.
I mostly agree, just a silly nitpick: Fast usually means cheap, especially if you are talking about software engineering. So I'd say the choice is between "fast & cheap" and good.
Really nicely put.
> There are a few more frameworks I would have loved to try, including Polymer and Vue.js. There just wasn't enough time to do a deep dive with all of them.
I hope he gives Vuejs a try. As a javascript beginner, who tried Angular, Angular2, A bit of React and VueJS, I just loved the flexibility and approach of VueJS. I was instantly productive thanks to the amazing documentation and vue-cli that just worked out of the box setting up my project.
PS: Never really spent much time on React as I tried it after VueJS and did not feel like proceeding much further with my tests.
I hope he gives Vuejs a try. As a javascript beginner, who tried Angular, Angular2, A bit of React and VueJS, I just loved the flexibility and approach of VueJS. I was instantly productive thanks to the amazing documentation and vue-cli that just worked out of the box setting up my project.
PS: Never really spent much time on React as I tried it after VueJS and did not feel like proceeding much further with my tests.
Agreed.
I've used Angular 2, React+Redux, and now Vuejs on different projects (and on personal projects, stuff like om, elm, etc).
Vuejs feels like they cheated somehow.
For people in Redux-land: they took the reactivity of MobX and gave it Redux' level of debuggability. One important way, I think, is that Vuex formalizes the 'actions-dispatching-actions' use case of Redux middlewares (which redux says 'is not a part of the architecture, but is important enough to be in core'); in Vuex, all action creators can dispatch other actions, and it throws an error in dev mode if you try to mutate state in a non-safe way.
I've used redux for a couple of years, and felt the pain of juggling different libraries (especially the struggles to manage router state) -- Vue is a delightful experience. Its chrome plugin is ridiculously useful; its documentation always seems clear and helpful; things work together.
I can't wait to see what Alibaba does with Weex -- essentially React Native for Vuejs. I did a test spike with it a month ago, and am trying to keeping tabs on it ...
I've used Angular 2, React+Redux, and now Vuejs on different projects (and on personal projects, stuff like om, elm, etc).
Vuejs feels like they cheated somehow.
For people in Redux-land: they took the reactivity of MobX and gave it Redux' level of debuggability. One important way, I think, is that Vuex formalizes the 'actions-dispatching-actions' use case of Redux middlewares (which redux says 'is not a part of the architecture, but is important enough to be in core'); in Vuex, all action creators can dispatch other actions, and it throws an error in dev mode if you try to mutate state in a non-safe way.
I've used redux for a couple of years, and felt the pain of juggling different libraries (especially the struggles to manage router state) -- Vue is a delightful experience. Its chrome plugin is ridiculously useful; its documentation always seems clear and helpful; things work together.
I can't wait to see what Alibaba does with Weex -- essentially React Native for Vuejs. I did a test spike with it a month ago, and am trying to keeping tabs on it ...
For our team React + Redux + Redux Saga + TypeScript has been a great way to develop our complex SPAs. We do use MobX selectively (dynamic forms), but the big benefits of the combination is the ability for our team to work productively without stomping on each other. Big factors are the explicit layout for domain models in the store, clear points for mutation, testable orchestrations via sagas, JSON schema validation and type generation.
The downside is the ceremony around it all but everything is so predictable and reliable it's a huge relief. Velocity is now good. We didn't choose this combination first off (via GraphQL, MobX, thunks), but the team decided that this combination was the best way for us to solve the issues we had encounter in the past.
The downside is the ceremony around it all but everything is so predictable and reliable it's a huge relief. Velocity is now good. We didn't choose this combination first off (via GraphQL, MobX, thunks), but the team decided that this combination was the best way for us to solve the issues we had encounter in the past.
I'm actually using a similar stack to you today -- redux + sagas, flow, json-schema.
However, in my experience, Vuex also has explicit stores and clear points for mutation -- Vuex stores are really clear and composable. It's also about 10 lines to get redux-sagas to working with Vuex.
If it weren't for react-native, I'd be pushing to use Vue + Vuex whenever possible. So I'm watching Weex with bated breath :) -- it's very cool that it's recently become an Apache Foundation project!
However, in my experience, Vuex also has explicit stores and clear points for mutation -- Vuex stores are really clear and composable. It's also about 10 lines to get redux-sagas to working with Vuex.
If it weren't for react-native, I'd be pushing to use Vue + Vuex whenever possible. So I'm watching Weex with bated breath :) -- it's very cool that it's recently become an Apache Foundation project!
I really like Vue as well. However, one big problem I found with it is that the community is tiny compared to React. Whereas with React people would respond to my questions on SO within minutes, with Vue it can take days, and that is if I get a response. I'd consider myself intermediate-level so I can usually work my way around whatever problem I'm having, but I would hesitate to recommend Vue to a beginner.
As a Vue beginner, I had the best luck asking questions on https://gitter.im/vuejs/vue and often got responses in minutes.
I wish the author had tried Polymer because it's the most underrated one.
I just love the way Polymer components declare/consume dependencies (as tags in the component file)
and connect all sub-components in the template markup via attributes - It makes data binding relationships between components and their children very clear.
Polymer is basically an inverted version of React (and it achieves a similar outcome). In React, template markup is nested inside the code. In Polymer, code is nested inside the template markup.
I really like React but I wouldn't use it for a personal project knowing that Polymer exists. I hope Polymer will gain more traction because I would love to be able to use it professionally.
Polymer is basically an inverted version of React (and it achieves a similar outcome). In React, template markup is nested inside the code. In Polymer, code is nested inside the template markup.
I really like React but I wouldn't use it for a personal project knowing that Polymer exists. I hope Polymer will gain more traction because I would love to be able to use it professionally.
I've used both Polymer and Vue for a few projects, and Vue's single file component method, coupled with WebPack, is almost identical to writing an app with Polymer.
Except that Vue doesn't ship with all the Polyfill baggage that Polymer does. Polymer has came a long way, but it still feels slow on anything but Chrome.
Once the Web Component spec is finalized, and built into browsers, I think Polymer will be a great choice. Today though, I gotta give the nod to Vue.
Except that Vue doesn't ship with all the Polyfill baggage that Polymer does. Polymer has came a long way, but it still feels slow on anything but Chrome.
Once the Web Component spec is finalized, and built into browsers, I think Polymer will be a great choice. Today though, I gotta give the nod to Vue.
Polymer traction is looking good, over 7k people on slack channel, 750 elements on webcomponents.org. And they got first day on google IO this year, youtube main site is being rewritten in it, ING, IBM, GE are using it, so it gets quite a bit of love from enterprise too.
I feel more comfortable using technologies that have had moderate, steady growth in popularity over many years like Polymer than technologies which experienced sudden, explosive growth like Angular 1 (we know how that turned out).
Early explosive growth means that the technology is hype-driven; adopters haven't given themselves the time to critically and objectively evaluate the solution - It's not so different from economic bubbles. People get excited and buy into it without thinking and then at some point in the future when they realise that it won't live up to their expectations they all start selling at the same time.
Early explosive growth means that the technology is hype-driven; adopters haven't given themselves the time to critically and objectively evaluate the solution - It's not so different from economic bubbles. People get excited and buy into it without thinking and then at some point in the future when they realise that it won't live up to their expectations they all start selling at the same time.
I remember looking at Polymer before I discovered Angular Material, and I really wanted to give it a go. I guess I played it safe by sticking with the thing I already knew, and I liked the Material docs. But I'd still like to try Polymer.
My biggest hangup with trying new platforms is finding a good UI framework to go with it, I like handing off styling to people who know what their doing.
My biggest hangup with trying new platforms is finding a good UI framework to go with it, I like handing off styling to people who know what their doing.
In React there are no templates, just component trees.
Everything in react is done in the template language.
This react below is not JavaScript... it's a reverse template language with a mix of not-quite-html and not-quite-JavaScript. jQuery style code is nicer than that! I hate the enterprise boilerplate in react projects. No wonder they're all failing!
This react below is not JavaScript... it's a reverse template language with a mix of not-quite-html and not-quite-JavaScript. jQuery style code is nicer than that! I hate the enterprise boilerplate in react projects. No wonder they're all failing!
class Square extends React.Component {
constructor() {
super();
this.state = {
value: null,
};
}
render() {
return (
<button className="square" => this.setState({value: 'X'})}>
{this.state.value}
</button>
);
}
}
If you don't like the "boilerplate" of a single class definition, use a functional component, which is just a function that returns JSX, that is also a component. It could literally not be more straightforward.
Or could you not hear me over the sound of that axe you're grinding? :)
Or could you not hear me over the sound of that axe you're grinding? :)
[deleted]
*stateless components
JSX is not a template language, it is just syntax sugar: see it as a different way to write javascript:
https://facebook.github.io/react/docs/jsx-in-depth.html
you can't say the same about templates.
It's not JavaScript, and it mixes in almost-html... but it's not a template language?
Wrong. It's a template language, even if Facebook tells you otherwise.
Wrong. It's a template language, even if Facebook tells you otherwise.
It really isn't a template language as the term is commonly used. If you feel so strongly about the weird syntax you can write equivalent code in javascript syntax instead.
return React.createElement(
button,
{ className: "square", onClick: () => this.setState({value: 'X'}) },
this.state.value
);
That's not a good thing.
I want to write this, and have it actually be HTML:
I want to write this, and have it actually be HTML:
<div>
<div>
</div>
<div>
Though I personally can tolerate JSX, maybe you like SGML templating [1] which uses native markup mechanisms such as entity references for fully HTML-aware and injection-free templating.
[1]: http://sgmljs.net/docs/templating.html
Disclaimer: my project, and SGML is most certainly not a "lightweight template engine" by any measure
[1]: http://sgmljs.net/docs/templating.html
Disclaimer: my project, and SGML is most certainly not a "lightweight template engine" by any measure
That looks like JavaScript. Yes, of course you can use that - but which react projects do it that way? It seems this is mostly pulled out when people go... ewwwwwwww, stinky...
Most use the html+javascript language which is compiled and then spits out JavaScript and html. This is pretty much identical to PHP - which is a preprocessor template language.
Anyway, facebook says it reminds me of a template language, so I'll believe them.
Most use the html+javascript language which is compiled and then spits out JavaScript and html. This is pretty much identical to PHP - which is a preprocessor template language.
Anyway, facebook says it reminds me of a template language, so I'll believe them.
> Most use the html+javascript language which is compiled and then spits out JavaScript and html. This is pretty much identical to PHP - which is a preprocessor template language.
No, it spits out javascript (the exact same javascript that I wrote), which returns shadow DOM trees (which are javascript objects), which the renderer looks at to modify the actual DOM.
Also not sure what you mean by "looks like" javascript. It's clearly javascript - just a function call with 4 arguments.
No, it spits out javascript (the exact same javascript that I wrote), which returns shadow DOM trees (which are javascript objects), which the renderer looks at to modify the actual DOM.
Also not sure what you mean by "looks like" javascript. It's clearly javascript - just a function call with 4 arguments.
Template languages create strings. JSX creates hyperscript.
JSX by its nature statically checks for tag balance, etc. The non-JavaScript part of its syntax has actual semantics. In a template language the non-Turing-complete part of the syntax is just strings.
JSX is a perfectly good notation for describing how data maps to its presentation in a DOM tree.
JSX by its nature statically checks for tag balance, etc. The non-JavaScript part of its syntax has actual semantics. In a template language the non-Turing-complete part of the syntax is just strings.
JSX is a perfectly good notation for describing how data maps to its presentation in a DOM tree.
if you want to build your UI with React you have to think about JSX as an easier way to write javascript. you can see it as a template language but it won't help you to code :)
[deleted]
I like both Vue and Polymer. I've also tried react and while I get it works, I don't really like it.
So far Polymer is my go to solution, but Vue is close second. I like the fact that everything (web components) is native to browser platform.
So far Polymer is my go to solution, but Vue is close second. I like the fact that everything (web components) is native to browser platform.
The vue looks good.
Yeah, Vue.js is for people who make things. React is for enterprises who don't seem to mind being 3 months late shipping basic stuff.
In react everything is done in the template language. It's a sort of reverse template language, that doesn't even really use proper html for things. So weird.
Vue is just all together, and is based on web standards. Not a weird thing by facebook enterprise developers who think that documents are dead and everything should be a slow loading monster single page thingo. Vue does components properly.
React components aren't. They tell you to move state from the child to the parents. That's not a component, and probably one of the biggest reasons many of the react projects are giant messes.
React is sort of like the old enterprise thing that doesn't solve any of the real issues with Angular style frameworks.
React does have a pretty good marketing budget though. Lots of evangelists paid to talk it up. Plus lots of developers who have invested so much time learning useless non-standard framework stuff. Also, there's plenty of freelance gigs cleaning up failed messy react projects.
Yeah, Vue.js is for people who make things. React is for enterprises who don't seem to mind being 3 months late shipping basic stuff.
In react everything is done in the template language. It's a sort of reverse template language, that doesn't even really use proper html for things. So weird.
Vue is just all together, and is based on web standards. Not a weird thing by facebook enterprise developers who think that documents are dead and everything should be a slow loading monster single page thingo. Vue does components properly.
React components aren't. They tell you to move state from the child to the parents. That's not a component, and probably one of the biggest reasons many of the react projects are giant messes.
React is sort of like the old enterprise thing that doesn't solve any of the real issues with Angular style frameworks.
React does have a pretty good marketing budget though. Lots of evangelists paid to talk it up. Plus lots of developers who have invested so much time learning useless non-standard framework stuff. Also, there's plenty of freelance gigs cleaning up failed messy react projects.
Ah, so jQuery spaghetti has now been replaced by React messes. I can also contribute that I've seen some Angular abominations and - a year or two back - some baleful Backbone projects. It's almost like whatever the framework or the library you give developers to use, regardless of its quality or scope, they're capable of making a mess with it! Hard to imagine, I know.
Except Vue projects seem to be succeeding. This is good for clients, but bad for freelancers getting paid lots to clean up messes.
The good components, and the docs are the biggest reasons. But also it's a very well thought through thing based on web specs, using html technology. People can get useful work done almost right away, and what they made is self contained by default, limiting their damage. It also works for the document case, AND the single page app case. Want to make a landing page that converts well? Vue has your back. Want to use that one jQuery plugin, because it's awesome... Vue can do that easily - it plays nice with others.
React should copy it more, and copy web standards more.
The good components, and the docs are the biggest reasons. But also it's a very well thought through thing based on web specs, using html technology. People can get useful work done almost right away, and what they made is self contained by default, limiting their damage. It also works for the document case, AND the single page app case. Want to make a landing page that converts well? Vue has your back. Want to use that one jQuery plugin, because it's awesome... Vue can do that easily - it plays nice with others.
React should copy it more, and copy web standards more.
Speaking of evangelists...
I'm happily cleaning up react messes :) As my dads plumber friend used to say... "There's money in shit!".
Fair cop. Not sure why I'm participating in a JavaScript framework internet discussion. I wish people would concentrate on standards, and apps.
Fair cop. Not sure why I'm participating in a JavaScript framework internet discussion. I wish people would concentrate on standards, and apps.
I personally have to refrain from commenting a lot of times - the arguments that happen tend to be the equivalent of video game console flame wars.
What component library do you recommend for Vue?
> React components aren't. They tell you to move state from the child to the parents.
You don't have to do that if you don't want to - I don't in the react I write. Is there anything special about vue components which would allow you to keep state in child components in vue but force you to move the state to parent components in react?
You don't have to do that if you don't want to - I don't in the react I write. Is there anything special about vue components which would allow you to keep state in child components in vue but force you to move the state to parent components in react?
> And the React ecosystem tends to either lack typings or provide poor/broken typings.
React integrates really well with flow[1] (which is not surprising because they're both developed at Facebook) and in my experience flow's typesystem is more powerful (OCaml inspired) than TypeScript one (C# inspired):
- non-nullable types by default is a big deal (they added support for non-nullable types in TypeScript 2, but enabling it with `--strictNullChecks` is a breaking change, so I don't think many users have done the switch).
- the type checker is sometimes not strict enough to be sound [2].
[1] : https://flowtype.org
[2] : http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...
React integrates really well with flow[1] (which is not surprising because they're both developed at Facebook) and in my experience flow's typesystem is more powerful (OCaml inspired) than TypeScript one (C# inspired):
- non-nullable types by default is a big deal (they added support for non-nullable types in TypeScript 2, but enabling it with `--strictNullChecks` is a breaking change, so I don't think many users have done the switch).
- the type checker is sometimes not strict enough to be sound [2].
[1] : https://flowtype.org
[2] : http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...
> React integrates really well with flow
No. The flow types around React are really poor. There are many things flow can't represent. The types are 'private' (all types in flow with a dollar in the name are private, not publicly supported. eg. React$Element).
The implementation of React$Element is hardwired into flow. If you have to include specific support for libraries it tells a lot about the expressiveness of the underlying type system, doesn't it?
There is no way to represent a react node, fragment etc. Properly typing children of a react component is impossible.
No. The flow types around React are really poor. There are many things flow can't represent. The types are 'private' (all types in flow with a dollar in the name are private, not publicly supported. eg. React$Element).
The implementation of React$Element is hardwired into flow. If you have to include specific support for libraries it tells a lot about the expressiveness of the underlying type system, doesn't it?
There is no way to represent a react node, fragment etc. Properly typing children of a react component is impossible.
> React integrates really well with flow[1] (which is not surprising because they're both developed at Facebook)
It can integrate just as well with TypeScript.
> flow's typesystem is more powerful (OCaml inspired)
It lacks access control for class properties/methods, I wouldn't call that powerful. https://flow.org/en/docs/types/classes/
It can integrate just as well with TypeScript.
> flow's typesystem is more powerful (OCaml inspired)
It lacks access control for class properties/methods, I wouldn't call that powerful. https://flow.org/en/docs/types/classes/
> It lacks access control for class properties/methods, I wouldn't call that powerful.
You mean `private` and such ? Well JavaScript don't support taht either yet, and flow is a type-system for JavaScript, it's not a new language on its own.
About the «powerful» word: Flow has had an algebraic data type (ADT) from the beginning, the kind of type system you'd find in functional programming languages, whereas TypeScript has and Object-Oriented type-system (à la Java or C#). ADT are usually considered «more powerful» since it offers more ways to write logical invariants in your code. The recent versions of TypeScript tries to retro-fit some features of ADTs into it, like non-nullable types or sum types, but it's a bit hacky IHMO[1].
[1]: https://www.typescriptlang.org/docs/handbook/advanced-types....
You mean `private` and such ? Well JavaScript don't support taht either yet, and flow is a type-system for JavaScript, it's not a new language on its own.
About the «powerful» word: Flow has had an algebraic data type (ADT) from the beginning, the kind of type system you'd find in functional programming languages, whereas TypeScript has and Object-Oriented type-system (à la Java or C#). ADT are usually considered «more powerful» since it offers more ways to write logical invariants in your code. The recent versions of TypeScript tries to retro-fit some features of ADTs into it, like non-nullable types or sum types, but it's a bit hacky IHMO[1].
[1]: https://www.typescriptlang.org/docs/handbook/advanced-types....
Typescript has had Discriminated Unions as long as I can remember (pre 1.0). Why do you think they've been hacked in?
The ending is what makes this article:
>Overall, I'm not 100% sure I made the right choice, but I only have to live with it for two years.
People are great at short term thinking, and tend to be terrible at long term thinking. Just some anecdata: I had a look at some source code for a 10+ year old web app before JS libraries were popular. I could understand perfectly how a click on a link resulted in a URL hash change and how the hash change resulted in updates on the page. Nowadays it would be written off as coding your own framework since web developers can't be trusted to code without a framework anymore. But it worked with the least amount of indirection possible and it was simple to understand 10 years later. Web apps today just get rewritten every two years.
>Overall, I'm not 100% sure I made the right choice, but I only have to live with it for two years.
People are great at short term thinking, and tend to be terrible at long term thinking. Just some anecdata: I had a look at some source code for a 10+ year old web app before JS libraries were popular. I could understand perfectly how a click on a link resulted in a URL hash change and how the hash change resulted in updates on the page. Nowadays it would be written off as coding your own framework since web developers can't be trusted to code without a framework anymore. But it worked with the least amount of indirection possible and it was simple to understand 10 years later. Web apps today just get rewritten every two years.
Don't worry, the simpleness and adequateness of plain old JavaScript (+ maybe jquery) and basic web techniques is re-discovered like every 5 years. Right now, we're at the height of the React hype cycle which just means we're approaching its imminent downfall due to generational forces (though I still do like some aspects of React specifically).
Sorry to sound defaitist, but like you say, the goal of React (and AngularJS, vue, ...) is to simplify web frontend development and improve maintainability. But these cost benefits are offset by their (absurd, IMHO, for most use cases) upfront complexity and thus can't possibly be attained within two years. Also, the desire to work in an agile fashion where everybody should be able to do everything (back- and front-end work) works against expert/thermonuclear front-end development tools.
Sorry to sound defaitist, but like you say, the goal of React (and AngularJS, vue, ...) is to simplify web frontend development and improve maintainability. But these cost benefits are offset by their (absurd, IMHO, for most use cases) upfront complexity and thus can't possibly be attained within two years. Also, the desire to work in an agile fashion where everybody should be able to do everything (back- and front-end work) works against expert/thermonuclear front-end development tools.
A critical point about these types of frameworks it that their benefits wont necessarily outweigh the complexity they bring to every project, and specifically they are likely to be needlessly complex in smaller projects.
In larger or long-term projects though the ability to use formal conventions to break down an app into components that have solid documentation already written on how to do this or that in a way that will scale and extend is quite valuable.
Additionally being able to reach out to a large community of developers who use similar conventions and plugins is quite valuable for troubleshooting those 10%/90% problems or finding a drag-n-drop solution that's compatible with your stack.
In larger or long-term projects though the ability to use formal conventions to break down an app into components that have solid documentation already written on how to do this or that in a way that will scale and extend is quite valuable.
Additionally being able to reach out to a large community of developers who use similar conventions and plugins is quite valuable for troubleshooting those 10%/90% problems or finding a drag-n-drop solution that's compatible with your stack.
Yes, you can understand a 10+ year old web app's JavaScript, but that's because there was very little JavaScript on it to begin with.
I used to write a lot of jQuery, and in my experience once the code on a page became longer than ~500 lines, it became significantly more difficult to wrap one's head around.
With the new tools the baseline for understanding the code is higher, but if you meet that baseline then you can grok code that is much more complex.
I used to write a lot of jQuery, and in my experience once the code on a page became longer than ~500 lines, it became significantly more difficult to wrap one's head around.
With the new tools the baseline for understanding the code is higher, but if you meet that baseline then you can grok code that is much more complex.
Agreed. jQuery is NOT going to be coming back around for another round of dominance. It will continue to slowly fade.
It was a huge step forward, but that was several steps back...
It was a huge step forward, but that was several steps back...
It just shows how fast the web moves (or how old I am) that someone can write "Then the Web happened...pages were giant jumbled messes of template and jQuery."
There were plenty of new paradigms and new headaches before the JQuery era!
There were plenty of new paradigms and new headaches before the JQuery era!
The history of a subject does not exist prior to someone's interest in it. It must be an internet meme, because it happens way too often. Someone the other day posted an article in which the author said Github "invented" the term Fork. Mmmmkay...
OP here. My first draft of the intro was a long-winded history that went all the way back to Win16 thunking. It was too long and detracted from the point of the article, so I cut it down.
I'd actually like to see that history as another post, then :) Last fall I did a presentation called "The (R)Evolution of Web Dev", which covered a brief history of web dev technologies and gave an overview of modern web dev tech and trends: http://blog.isquaredsoftware.com/2016/10/presentation-modern... . I also ran across a couple similar presentations recently: http://www.bcssouthwest.org.uk/presentations/MikeEvans2016.p... and https://hackernoon.com/modern-web-development-bf0b2ef0e22e .
Anyway, excellent post. I'm actually a Redux maintainer, and spend a lot of time answering questions about use of React and Redux. I'd be happy to chat with you sometime about any React+Redux-related topics or questions you might have. I'm @acemarke on Twitter, and also in the Reactiflux chat channels at https://www.reactiflux.com .
Anyway, excellent post. I'm actually a Redux maintainer, and spend a lot of time answering questions about use of React and Redux. I'd be happy to chat with you sometime about any React+Redux-related topics or questions you might have. I'm @acemarke on Twitter, and also in the Reactiflux chat channels at https://www.reactiflux.com .
I figured ;) Good article.
> Angular's routing seems to involve "one big routing config".
That's wrong. You can split the routing configuration just like in react-router or Aurelia. It also supports lazy loading of child routes and components. So you don't have one giant application to serve at bootup time. It is also documented really well: https://angular.io/docs/ts/latest/guide/ngmodule.html#!#lazy...
That's wrong. You can split the routing configuration just like in react-router or Aurelia. It also supports lazy loading of child routes and components. So you don't have one giant application to serve at bootup time. It is also documented really well: https://angular.io/docs/ts/latest/guide/ngmodule.html#!#lazy...
I was re-structuring the routing in an Angular 2 app yesterday and I came to the same conclusion as the author. I think the documentation in the routing section doesn't go into enough detail about how to configure the modules for the desired encapsulation. The documentation you've posted is what is required - but it's in module not routing. It's hard to find.
Angular core team here, we're restructuring some of our docs at the moment and this is super useful feedback. Thanks!
I really like Aurelia so far. It offers me a lot of tools as a developer to develop projects my own way.
It feels like working with raw ES6 with a small but powerful library on top. Anyone good Javascript developer can pick it up in a matter of a few hours which makes onboarding very easy.
It is still young and small when comparing it to its big brothers but you should try it anyway. It's really a joy to work with.
I keep reading about how there is no community but that isn't true at all. The Gitter chat is very active and you can get an answer there in a matter of minutes.
----
My answer to the article's conclusion:
"My team is small and doesn't have a professional web designer; I need other people's components."
- In my experience using other people's components is often the weakness in big projects. You end up spending more time customizing them to your need than it would have taken building them yourself using the project's specification. That being said, yes, you do need either a full-stack or a front-end dev. for that.
"I also hit too many stumbling blocks building out my spike, requiring hours of painful research."
- The building system is very simple and looks like the ones I do myself but bigger. You can choose between Webpack and JSPM. You can even use their very simple CLI if you are not used to front-end build systems.
"I never did succeed at getting a dialog to open, show a progress bar, and close programmatically."
- ... Really? That's the basic tutorial on their website. Was an attempt even tried?
It feels like working with raw ES6 with a small but powerful library on top. Anyone good Javascript developer can pick it up in a matter of a few hours which makes onboarding very easy.
It is still young and small when comparing it to its big brothers but you should try it anyway. It's really a joy to work with.
I keep reading about how there is no community but that isn't true at all. The Gitter chat is very active and you can get an answer there in a matter of minutes.
----
My answer to the article's conclusion:
"My team is small and doesn't have a professional web designer; I need other people's components."
- In my experience using other people's components is often the weakness in big projects. You end up spending more time customizing them to your need than it would have taken building them yourself using the project's specification. That being said, yes, you do need either a full-stack or a front-end dev. for that.
"I also hit too many stumbling blocks building out my spike, requiring hours of painful research."
- The building system is very simple and looks like the ones I do myself but bigger. You can choose between Webpack and JSPM. You can even use their very simple CLI if you are not used to front-end build systems.
"I never did succeed at getting a dialog to open, show a progress bar, and close programmatically."
- ... Really? That's the basic tutorial on their website. Was an attempt even tried?
That's the basic tutorial on their website.
No it isn't. The basic tutorial raises a dialog with a close button that the user clicks.
Try raising the dialog, advancing a progress bar, and closing the dialog - all without user interaction. Eg, you're showing progress for an activity that should block out all interaction. It just doesn't work.
No it isn't. The basic tutorial raises a dialog with a close button that the user clicks.
Try raising the dialog, advancing a progress bar, and closing the dialog - all without user interaction. Eg, you're showing progress for an activity that should block out all interaction. It just doesn't work.
The search grid that I have built using Aurelia does that.
It's been a while so I don't have the exact code in my head. I simply modified the progress bar of the tutorial so that I can pass a parameters that make it so nothing can be clicked if it is set to "true" and also binds the "disabled" parameter of the buttons in the dialog.
I don't want to be "that guy" but how is any of this hard? Everything is open source, you can modify everything to your requirements and build the parts that don't exist.
It's been a while so I don't have the exact code in my head. I simply modified the progress bar of the tutorial so that I can pass a parameters that make it so nothing can be clicked if it is set to "true" and also binds the "disabled" parameter of the buttons in the dialog.
I don't want to be "that guy" but how is any of this hard? Everything is open source, you can modify everything to your requirements and build the parts that don't exist.
This kind of comparison is meaningless. Compare React to Veu.js, as these are both view renderers, not full MV* frameworks. And compare Angular2 to Ember (with Fastboot), both of which are opinionated MV* frameworks. Not sure why this is on the front page
Because when people say "React" they don't mean "React" but "React plus X" (React Router, Redux, what have you). Or the "React ecosystem".
In the real world "Angular" (i.e. the Angular ecosystem), "Ember" (i.e. the Ember ecosystem), "React" (i.e. the React ecosystem), "Aurelia" (i.e. pretty much just Aurelia because nobody actually uses Aurelia so there's no ecosystem -- just kidding, maybe) etc compete against each other. It's not about the actual libraries themselves.
One could toss in "Backbone" (i.e. jQuery plus Backbone) for good measure but barely anyone considers Backbone a viable option for new code (rather than something you want to migrate old code away from).
It's on the front page because people who aren't already dedicated to any of these ecosystems literally ask "should I use React or Angular (or Ember or ...)?".
I think the only mistake is to talk about "frameworks" as if the choice is a choice between frameworks when it's obviously about the ecosystems not libraries (whether those libraries are frameworks or not).
In the real world "Angular" (i.e. the Angular ecosystem), "Ember" (i.e. the Ember ecosystem), "React" (i.e. the React ecosystem), "Aurelia" (i.e. pretty much just Aurelia because nobody actually uses Aurelia so there's no ecosystem -- just kidding, maybe) etc compete against each other. It's not about the actual libraries themselves.
One could toss in "Backbone" (i.e. jQuery plus Backbone) for good measure but barely anyone considers Backbone a viable option for new code (rather than something you want to migrate old code away from).
It's on the front page because people who aren't already dedicated to any of these ecosystems literally ask "should I use React or Angular (or Ember or ...)?".
I think the only mistake is to talk about "frameworks" as if the choice is a choice between frameworks when it's obviously about the ecosystems not libraries (whether those libraries are frameworks or not).
> not full MV* frameworks
Vue.js has an official router, and an official "redux" like data store.
https://router.vuejs.org/en/
https://vuex.vuejs.org/en/intro.html
It is absolutely a full MV* framework. Vue.js also supports server-side rendering, in fact I use Vue.js as my template engine when using node.js .
https://vuejs.org/v2/guide/ssr.html
Angular2 router is in a separate package, does it make is short of a full MV* solution? no.
What I like with Vue.js is that complexity is opt-in. In the sense that it doesn't force you to use a cli (it has a cli), it doesn't force you to use webpack or an asset pipeline (it has support for webpack). It doesn't force you to use a third party language, but you can... You start small then scale with your needs, instead of having to deal with complexity upfront. That used to kind of be the case with AngularJS 1 too, that's why it got widely adopted.
Vue.js has an official router, and an official "redux" like data store.
https://router.vuejs.org/en/
https://vuex.vuejs.org/en/intro.html
It is absolutely a full MV* framework. Vue.js also supports server-side rendering, in fact I use Vue.js as my template engine when using node.js .
https://vuejs.org/v2/guide/ssr.html
Angular2 router is in a separate package, does it make is short of a full MV* solution? no.
What I like with Vue.js is that complexity is opt-in. In the sense that it doesn't force you to use a cli (it has a cli), it doesn't force you to use webpack or an asset pipeline (it has support for webpack). It doesn't force you to use a third party language, but you can... You start small then scale with your needs, instead of having to deal with complexity upfront. That used to kind of be the case with AngularJS 1 too, that's why it got widely adopted.
I found it interesting and he specifically pulled in react-router to get the balance needed for the comparison to be valid.
When your application is just some views plus some routing - then that would be a fair comparison.
But in most real world situations (SPA) it's much more: Form validation, Data Fetching, Unit Testing, Component styling, Translations, Modularization, ...
You make it sound like no one has ever had to make a decision to choose between different frameworks.
This article is spot on. I've been building Angular 2 and React (Native) apps over the last 3 months and I have broadly similar conclusions. Once React clicked, it really is very easy to reason about.
With regard to the DI problem, I created a combination of static classes for things like the User object and function collections with observables for app state. I didn't use Redux. You can get similar behaviour with Observable zip/scan/reduce and it's much more lightweight.
With regard to the DI problem, I created a combination of static classes for things like the User object and function collections with observables for app state. I didn't use Redux. You can get similar behaviour with Observable zip/scan/reduce and it's much more lightweight.
> Save the global components off as global variables and just use them ... When my ActivityIndicator component mounts, it saves itself off to a global. Any code can import busy and run busy.start() and busy.stop().
What is the story that FP folks need to tell here, so that people don't do things like this?
What is the story that FP folks need to tell here, so that people don't do things like this?
The big bugbear is global, mutable state. Global immutable state is not nearly as much of a big deal. Local mutable state, likewise.
Once that global immutable state turns out to be less than immutable (e.g you introduce the ability to change program configuration at runtime), you should look for an efficient way of do DI, which in functional programming just means "how do I pass the same first argument to a lot of functions at the same time". The Reader monad is probably the most archetypally FP approach to the problem.
Once that global immutable state turns out to be less than immutable (e.g you introduce the ability to change program configuration at runtime), you should look for an efficient way of do DI, which in functional programming just means "how do I pass the same first argument to a lot of functions at the same time". The Reader monad is probably the most archetypally FP approach to the problem.
Nothing. We know it's messy, but React doesn't really provide a better way of doing this.
Context is barely mentioned in the docs, "not recommended" by the devs. Redux is incredibly verbose and overcomplicated. Passing "global" things down in props is just madness (if everything needs it).
Personally I use context, or a singleton (which is just a hidden global really). It's naughty, but usually required for one or two things per application.
FP folks aren't sages hiding in caves who we all wait to come down from the mountains once a year with their crusty wisdom...
Context is barely mentioned in the docs, "not recommended" by the devs. Redux is incredibly verbose and overcomplicated. Passing "global" things down in props is just madness (if everything needs it).
Personally I use context, or a singleton (which is just a hidden global really). It's naughty, but usually required for one or two things per application.
FP folks aren't sages hiding in caves who we all wait to come down from the mountains once a year with their crusty wisdom...
Passing data via props has never been a problem for me. It's explicit, the chain of dependencies explicit, the data flows in one direction, and components can still be dumb while letting us push the glue layer all the way to the top.
No one has ever approached that code and been confused or had issues tracking down bugs in my experience.
I agree it's ugly. I've found it triggers the same sense in a lot of developers that make them over-abstract code to achieve DRY at the expense of simplicity (this is just an observation, I don't have an opinion on if it's good or bad!).
No one has ever approached that code and been confused or had issues tracking down bugs in my experience.
I agree it's ugly. I've found it triggers the same sense in a lot of developers that make them over-abstract code to achieve DRY at the expense of simplicity (this is just an observation, I don't have an opinion on if it's good or bad!).
React doesn't, but JS perhaps does.
A lot of my code has to be mounted in separate root components and it's not allowed to be a SPA.
In this instance, it was convenient to use event listeners, though it's very similar to calling a global.
A lot of my code has to be mounted in separate root components and it's not allowed to be a SPA.
In this instance, it was convenient to use event listeners, though it's very similar to calling a global.
ok, well "Nothing" means folks go OP route, globals everywhere—if that's expected than I guess there's no problem. I did not think globals everywhere was what React expected users to implement.
Aurelia is componentised, so you can use React as the view engine which (in theory) would give you the benefits of React alongside decent routing and DI (which can also be swapped out).
One other thing that Aurelia is good about is not requiring a lot of DSL. The maintainers aren't interested in developer lock in or mindshare like Facebook and Google, so the code you write is more portable than with React or Angular - it's a shame the author didn't make more of this.
Additionally the maintainers provide guarantees that they won't pull the projects, which Facebook and Google do not.
That said, it's hard to argue that the ecosystem around React+Redux and Angular makes it very hard for the smaller players to get a look in for all sorts of reasons.
One other thing that Aurelia is good about is not requiring a lot of DSL. The maintainers aren't interested in developer lock in or mindshare like Facebook and Google, so the code you write is more portable than with React or Angular - it's a shame the author didn't make more of this.
Additionally the maintainers provide guarantees that they won't pull the projects, which Facebook and Google do not.
That said, it's hard to argue that the ecosystem around React+Redux and Angular makes it very hard for the smaller players to get a look in for all sorts of reasons.
Comparing plain React with Angular and Aurelia is completely useless. You cannot write a big serious application with Form Validation, Data Fetching, Testing, etc, just with React itself. A fair comparison would be to write a whole "real world" project and then see what parts you have to use and learn to be able to write a full React application.
Author didn't compare "plain React". Author compared React with React Router (and possibly Redux/whatever for state).
Did you only read the part about the documentation?
Did you only read the part about the documentation?
Comparing is never useless. How else would you discover differences? For someone like me, who is in the same process of finding the right js framework, articles like this do help.
But you probably mean: the comparison excluded some crucial details.
But you probably mean: the comparison excluded some crucial details.
> But you probably mean: the comparison excluded some crucial details.
Exactly. You have to compare these kind of frameworks/libraries in "real world" situations and not just build two subpages and create some simple components to form an opinion. Real world single page applications need much more than just the view layer and a router.
Exactly. You have to compare these kind of frameworks/libraries in "real world" situations and not just build two subpages and create some simple components to form an opinion. Real world single page applications need much more than just the view layer and a router.
Please please go read the article before making this type of statement.
I did, no worries :)
OP here. Perhaps you overlooked my comment in the intro that my spike solution was the first few screens of my real-world app? The code samples in the article are distilled/simplified from the spike solutions.
My React spike became my real app, and structurally looks pretty much the same (even 2 months of dev later). If you think there are some important concerns that I left out (and I'm sure there are), please be specific so that I/we can learn.
My React spike became my real app, and structurally looks pretty much the same (even 2 months of dev later). If you think there are some important concerns that I left out (and I'm sure there are), please be specific so that I/we can learn.
Please don't imply that others haven't read the article.
That may be your criteria for evaluation, but it may not be everyone's criteria. Second, is he claiming to speak objectively for everyone? No, it's an anecdote/opinion - says it right in the title.
This is just blatantly false. I've got several apps in production using nothing but React, React-Router and a unit testing library. In-fact I'd posit that it's easier to write good, maintainable code using a minimal toolset than it is to cram a bunch of rubbish in there that dictates your software's architecture. I've seen more people shoot themselves in the foot with things redux and redux-thunk than I have seen use them properly.
I'm working on my first Angular2 app (inside Ionic 2) and have not been overly impressed. Most (all) of these will be first-project-pain but I'll list them anyway:
* The massive coupling in app.module.ts and app.component.ts
* Coming as a backend dev, the coupling of services to the view layer
* Terminology of service/provider, and the general standard of documentation (3rd parties are far better than the official docs)
* Having a definite 'Angular way' of doing things, but not documenting it explicitly
And new to a modern JS project:
* Observables need a mindshift,and I'm still adjusting * Keeping clean separation between layers. Subscribing to events to update viewmodel attributes helps, but I feel I'm lacking separation and over-coupling
Of the example code samples I've adapted, I've found the Aurelia community to be consistently high quality and well thought through, which can't be said for Angular.
* The massive coupling in app.module.ts and app.component.ts
* Coming as a backend dev, the coupling of services to the view layer
* Terminology of service/provider, and the general standard of documentation (3rd parties are far better than the official docs)
* Having a definite 'Angular way' of doing things, but not documenting it explicitly
And new to a modern JS project:
* Observables need a mindshift,and I'm still adjusting * Keeping clean separation between layers. Subscribing to events to update viewmodel attributes helps, but I feel I'm lacking separation and over-coupling
Of the example code samples I've adapted, I've found the Aurelia community to be consistently high quality and well thought through, which can't be said for Angular.
"* Having a definite 'Angular way' of doing things, but not documenting it explicitly"
Here you go https://angular.io/docs/ts/latest/guide/style-guide.html
Here you go https://angular.io/docs/ts/latest/guide/style-guide.html
I have a feeling that the Angular 2 docs are still a work in progress. For a long time, for example, the testing docs were still unfinished, even after the release.
I know yet another Framework but a lot of your issues I think are solved with Vuejs as they provide a quite mature and well documented component library which is using Streams (under the hood) and their single-file approach solves a lot of issues (https://vuejs.org/v2/guide/single-file-components.html).
additionally, they provide their own router, redux implementation which are all working very well with the components.
I think Vuejs has some great approaches which makes it easy especially for people who want to use new frontend stuff but not with the complexity and technical depth Angular2, React and others introduce.
additionally, they provide their own router, redux implementation which are all working very well with the components.
I think Vuejs has some great approaches which makes it easy especially for people who want to use new frontend stuff but not with the complexity and technical depth Angular2, React and others introduce.
/me Quietly goes back to using Knockout and Typescript to happily pootle along building apps without worrying about routing, SPAs and other added complexity.
Simplicity brings its own rewards.
Simplicity brings its own rewards.
In my experience, this initial added complexity and learning curve results in significantly higher productivity once a comfortable knowledge level is obtained. I can't imagine going back to Knockout and I truly believe I can develop 2x with React and it's ecosystem.
Been using Vuejs for a couple of months now. Just love it's simplicity and flexibility. Tried Angular 2 earlier. It was ok. But they've lost it with their new release cycle. I guess people will hesitate to use it.
Needed a routing solution where we had to load list-> multiple details(multiple tabs from a list of items; loaded using ajax/websockets) not single detail view. Not sure either Angular or Vue's router could do it. So we ended up implementing a custom one.
Needed a routing solution where we had to load list-> multiple details(multiple tabs from a list of items; loaded using ajax/websockets) not single detail view. Not sure either Angular or Vue's router could do it. So we ended up implementing a custom one.
FWIW, Angular's release cycle is roughly based on the same cadence as React :)
:)
Wasn't aware of that. Haven't tried React. Maybe because I am a bit impatient.
My key to success with react-router was to use context and redux to get props to the routed components. Sub-components from there can accept props directly. After a while it feels natural - any necessary information is stored in the store.
This is an anti-pattern unless you actually have shared state between pages. Otherwise it's functionally no different to just having local state on each page and all you have is lots of unnecessary boilerplate.
This is way more common than I realised before I started working in teams. Each page does it's own API calls to the server (either directly, or more commonly through some sort of horrible misuse of redux-thunk), stores the data in it's own little section of the redux store, and then receives the exact same data back as props :/
This is way more common than I realised before I started working in teams. Each page does it's own API calls to the server (either directly, or more commonly through some sort of horrible misuse of redux-thunk), stores the data in it's own little section of the redux store, and then receives the exact same data back as props :/
In general, you only need react-router if you have multiple pages with some kind of shared state (ie: a dashboard).
I do know exactly what you are talking about. We do have some single pages that implement the boiler plate just so that they are consistent with the others.
I do know exactly what you are talking about. We do have some single pages that implement the boiler plate just so that they are consistent with the others.
Regarding the Angular DI part: You don't need "provides" anymore on each component, afaik it's even deprecated. You just need to define it once on the module that defines the DI providers. And in the module of the component import that module. But your findings may already have been from some time ago where things were different in Angular land. That's for me the saddest story of Angular 2: Between alpha, beta, RC and final release dozens of things changed, which required me to constantly change my app. Now that it's stable I'm quite sophisticated with it.
> afaik it's even deprecated.
No, it's not. You use providers on a component when you want to have a new instance of that Service when a new Component instance of that type gets created. So you have complete control over the DI. More details here: https://angular.io/docs/ts/latest/guide/dependency-injection...
No, it's not. You use providers on a component when you want to have a new instance of that Service when a new Component instance of that type gets created. So you have complete control over the DI. More details here: https://angular.io/docs/ts/latest/guide/dependency-injection...
I swear "React is just a library, not a framework" is the new "JavaScript is just a scripting language, not a programming language". The comments in this thread are a great example of this.
Well for me React being just a library is the very reason to use it. Frameworks are constraining, you code "inside" them and can't get out. Libraries are giving more freedom, you code "along" them. For example, I was really hating react-router and wrote my own, with proper state and url injection, in one or two sessions. I guess it would have been much harder if I was "inside" a framework.
I like the conclusion and it's a fair comparison. I, however, can't stand react with reasons I don't want to get into.
But I would kill to see a middle ground between react and angular.
But I would kill to see a middle ground between react and angular.
I would love to hear how people solve the snackbar problem in React. I don't even see how you would solve it with redux since that's just the state.
The snackbar problem is actually what redux is built to solve. You would "provide the toast()" function by having components dispatch a "toast" action. From there, your reducer would modify the snackbar state accordingly, e.g. by implementing a stack of toasts, and you would have a single global component render that state into popups.
Yeah. There's a dozen existing "notifications with Redux" libs already: https://github.com/markerikson/redux-ecosystem-links/blob/ma... .
Behavior-wise, it basically just amounts to a pair of SHOW and CLOSE actions, possibly with the reducer tracking an array of open notification entries, and a component that maps over the array and shows an actual notification entry. I glanced at the ones in my list, saw the similarities, and just wrote my own.
Behavior-wise, it basically just amounts to a pair of SHOW and CLOSE actions, possibly with the reducer tracking an array of open notification entries, and a component that maps over the array and shows an actual notification entry. I glanced at the ones in my list, saw the similarities, and just wrote my own.
in other words, you don't call functions, you send messages.
[deleted]
The specific problem is solved by having the toasts as state and having the Snackbar merely concern itself with presenting that state.
The general problem of shared state is solved with Context (which react-redux uses btw) which is actually quite similar to Angular's DI except it's generally not advertised as something you should use yourself as an application developer (because it's usually too low-level compared to something like react-redux or react-router).
The general problem of shared state is solved with Context (which react-redux uses btw) which is actually quite similar to Angular's DI except it's generally not advertised as something you should use yourself as an application developer (because it's usually too low-level compared to something like react-redux or react-router).
What is the snackbar problem?
See the section in the article with the heading "Dependency Injection". It talks about a specific scenario where there is one component that needs to show the state of the entire system (an activity light turned on, for example), where any component can trigger this, but the last component to become inactive turns the light off.
Couldn't you just extend the React.Component class with whatever you need, and then use that instead of the base react class? Or am I misunderstanding what react is?
> React-router has gone through a lot of version churn. I used the (at the time) still-in-beta v4 router. This is good because it's clearly a better solution than prior versions. It's bad because all the tutorials and most of the online documentation refer to the old versions. Also there were no typings for v4 (since fixed).
And to think people complain about GTK changing too frequently...
And to think people complain about GTK changing too frequently...
React is, of course, a work of a genius. But may I suggest another option in the same spirit, which is Riot.js? It is more elegant, compact and better syntactically polished, while retaining React's convenience and performance.
(I had approached React right when the infamous Babel5->Babel6 transition happened, and was seriously burned by it.)
(I had approached React right when the infamous Babel5->Babel6 transition happened, and was seriously burned by it.)
I am using riot.js too and am pretty happy so far. Actually, I never tried react, but as riot is smaller, I like the tag syntax much better and I do not feel like I miss anything, I do not know why I should try it (anybody here prefers react over riot? why?).
Before riot, I tried Backbone, Ember and Angular. While Backbone did a fine job it didn't help to structure the app and everything had to be done manually.
Ember was too opinionated for me. Yes, they have some nice concepts and bring a lot of functionality right out of the box, but when you still have problems doing basic stuff after the third project, you know it's time to move on. The only thing I sometimes miss is ember-data.
Angular looked better to me, but they lost me with the Angular2 migration. I hate it when libs break backward-compatibility and in my eyes, there were enough good alternatives so that I did not have to risk facing the same story again with some future angular version.
The beauty in riot.js is that you can easily build small html components and stack them together afterward and reuse them later. It really feels like a lib which you can plug into something else. So I am able to develop an app using riot.js with framework7 and formatjs at the moment.
Before riot, I tried Backbone, Ember and Angular. While Backbone did a fine job it didn't help to structure the app and everything had to be done manually.
Ember was too opinionated for me. Yes, they have some nice concepts and bring a lot of functionality right out of the box, but when you still have problems doing basic stuff after the third project, you know it's time to move on. The only thing I sometimes miss is ember-data.
Angular looked better to me, but they lost me with the Angular2 migration. I hate it when libs break backward-compatibility and in my eyes, there were enough good alternatives so that I did not have to risk facing the same story again with some future angular version.
The beauty in riot.js is that you can easily build small html components and stack them together afterward and reuse them later. It really feels like a lib which you can plug into something else. So I am able to develop an app using riot.js with framework7 and formatjs at the moment.
Nice comparison, please try Vuejs I have used angular 1 and react with redux in the past and Vue for me is so elegant and simple (it's also really fast), it has the component system of React and the template style of angular and you can create single file components .vue files that encapsulate html, js and css.
I always hear Angular 2 ppl talk about how awesome it is, because of TypeScript and RxJS, as if they're the main good things about it.
If you really like these two things, try CycleJS. It's basically "Angular 2 the good parts"
If you really like these two things, try CycleJS. It's basically "Angular 2 the good parts"
Personally I don't see any appeal in either Typescript or RxJS.
"Some of us dynamically generate this for various reasons. You can just copy the important script tags into your html but it still seems weird and invasive."
You can use the ng eject command to add the webpack configuration to your project root and it'll add and print a set of npm commands too.
You can use the ng eject command to add the webpack configuration to your project root and it'll add and print a set of npm commands too.
I'm the project lead for Aurelia, so I'd like to take a minute to address a few of the points from the linked post. Jeff makes some valid points, for sure. However, there is also some inaccurate information and a healthy dose of subjectivity.
* Documentation - This one tends to be highly subjective. One's happiness with documentation is often highly dependent on learning style and what you are trying to do "in the moment". Jeff describes it as a "mixed bag". However, we've had plenty of people praise Aurelia's docs as amazing or even make statements such as "this is the way all documentation should be." Do we have room for improvement? Absolutely. In fact, we're working on a completely new documentation site right now. * TypeScript Support - We have a huge community of TypeScript developers who are quite happy with our support for the language. We provide d.ts files for everything. We also have a number of our libraries that are now completely written in TypeScript. This includes our new Webpack tooling, our Validation library, our UX Component library and more. We've actually worked directly with the TypeScript team to provide scenarios for them, which resulted in new features for TypeScript and submissions to ECMA for future versions of JavaScript. * Build System - Aurelia supports multiple options, including RequireJS, SystemJS, Dojo and Webpack. We have a very diversified community. Our CLI is designed for beginners who either are completely new to SPA frameworks or don't know how to use tools like Webpack. It's designed to get them up and running quickly and easily. It has been exteremely successful in that area and we've received a ton of praise for it. If you are a Webpack developer, I would expect you to use a Webpack setup instead though. We have a Skeleton for Webpack that's based on Webpack 1.x. However, we've got a completely new set of Webpack 2.x tooling. There have been blog posts about it, there's documentation, dedicated plugins, etc. It sounds like Jeff missed this somehow. Lots of people are using it though and loving it. We're doing some work now to broaden the availability of our new Webpack setup, so hopefully future devs won't have the same discovery problem that Jeff did. * Dependency Injection - This one is is pretty accurate. Our DI is extremely powerful and extensible, but we try to stay out of your way as much as possible. You can even use DI without decorators at all, in a pure ES2015 fashion, if you like. * Component Encapsulation - Here Jeff doesn't talk about the component model at all really. He's fixated on whether or not you can put a component in one file, something that tends to be a subjective requirement. That would be fine but he missed the point that you can include your JS and HTML in the same file with Aurelia as well, by using our @inlineView decorator. We've supported this for two years, but maybe we need to talk about it more. That said, we generally don't recommend this as the default practice, because we hold the opinion that it's better for developer/designer collaboration, parallel work, and sometimes even source control, if you put these things in seperate files. If you want to do it, you can though. The Aurelia strategy is to have a lite set of opinions but to always enable developers, which is why we support both paths. One other quick point here: Jeff calls out our component naming as "magic". However, our documentation very clearly points out that, if you don't provide an explicit component name, the convention is to use the export name. This is a fundamental convention in Aurelia that is well-documented. * Routing and Fetching - Here Jeff has a couple of questions about getting access to parameters in sub components and altering the way that routes generate titles. Those are all possible and would have been a good opportunity for Jeff to engage with our very helpful community. Jeff makes one cricirtism that is very valid though. Our documentation on routing is lacking in some big areas. I don't think there's any doubt about that. It's something we're working to remedy. Perhaps this is the central reason why he thinks Aurelia's docs are a "mixed bag"? * Ecosystem - This point really frustrated me. Our community is not tiny. There are tens of thousands of companies using Aurelia all over the world. There are tons of very large, well-known brands using Aurelia. Unfortunately, we can't share these names all the time. Please understand that Google and Facebook have considerable influence over other companies that we do not have. For example, if company X uses Angular or React, they want Google/Facebook to publish that information because the Google/Facebook brand is likely bigger than theirs and they want to ride on the coat tails of the larger, more influencial company. In our case, Aurelia as a project, is almost always smaller than the dozens of Fortunate 500 companies that are using it. So, they don't have any motiviation to share that information. Because the bureaucratic legal and marketing hoops are so numerous, we end up not being able to share many things publicly. * Ecosystem Part 2 - We have tons of 3rd party modules for Aurelia. Jeff states that there are no third-party component libraries for Aurelia. That's not correct. We've had public announcements about Telerik and Syncfusion component libraries. There's also a Materialize component library and at least one very large community-based component library in addition to the collection of individual components that people have built. Aurelia itself has an official component library. It's early, for that library, true. One thing I take away from this is that we need to focus on and "highlight" even more in our official docs and site these 3rd party components, because maybe people just don't know that they exist.
Now, we realize that Aurelia is far from perfect and that we always have plenty of work to do and things to improve on. I and my team of about 30 engineers have poured countless hours, worth millions of engineering dollars into Aurelia. We don't have the brand power of Google or Facebook. Who does? So, if you write this type of comparison post, please be careful to validate the information and maybe even reach out to the project contributors for feedback. Posts like this can cast all our work in an overly-negative light, particularly for those who haven't encountered Aurelia before and don't know better. We're all working for the same thing here and want to help each other and our businesses succeed. I always take feedback like this to heart and I and my team will continue to work hard to make Aurelia better every day. We invite everyone to join our community and contribute together to making Aurelia the best platform for modern web apps.
* Documentation - This one tends to be highly subjective. One's happiness with documentation is often highly dependent on learning style and what you are trying to do "in the moment". Jeff describes it as a "mixed bag". However, we've had plenty of people praise Aurelia's docs as amazing or even make statements such as "this is the way all documentation should be." Do we have room for improvement? Absolutely. In fact, we're working on a completely new documentation site right now. * TypeScript Support - We have a huge community of TypeScript developers who are quite happy with our support for the language. We provide d.ts files for everything. We also have a number of our libraries that are now completely written in TypeScript. This includes our new Webpack tooling, our Validation library, our UX Component library and more. We've actually worked directly with the TypeScript team to provide scenarios for them, which resulted in new features for TypeScript and submissions to ECMA for future versions of JavaScript. * Build System - Aurelia supports multiple options, including RequireJS, SystemJS, Dojo and Webpack. We have a very diversified community. Our CLI is designed for beginners who either are completely new to SPA frameworks or don't know how to use tools like Webpack. It's designed to get them up and running quickly and easily. It has been exteremely successful in that area and we've received a ton of praise for it. If you are a Webpack developer, I would expect you to use a Webpack setup instead though. We have a Skeleton for Webpack that's based on Webpack 1.x. However, we've got a completely new set of Webpack 2.x tooling. There have been blog posts about it, there's documentation, dedicated plugins, etc. It sounds like Jeff missed this somehow. Lots of people are using it though and loving it. We're doing some work now to broaden the availability of our new Webpack setup, so hopefully future devs won't have the same discovery problem that Jeff did. * Dependency Injection - This one is is pretty accurate. Our DI is extremely powerful and extensible, but we try to stay out of your way as much as possible. You can even use DI without decorators at all, in a pure ES2015 fashion, if you like. * Component Encapsulation - Here Jeff doesn't talk about the component model at all really. He's fixated on whether or not you can put a component in one file, something that tends to be a subjective requirement. That would be fine but he missed the point that you can include your JS and HTML in the same file with Aurelia as well, by using our @inlineView decorator. We've supported this for two years, but maybe we need to talk about it more. That said, we generally don't recommend this as the default practice, because we hold the opinion that it's better for developer/designer collaboration, parallel work, and sometimes even source control, if you put these things in seperate files. If you want to do it, you can though. The Aurelia strategy is to have a lite set of opinions but to always enable developers, which is why we support both paths. One other quick point here: Jeff calls out our component naming as "magic". However, our documentation very clearly points out that, if you don't provide an explicit component name, the convention is to use the export name. This is a fundamental convention in Aurelia that is well-documented. * Routing and Fetching - Here Jeff has a couple of questions about getting access to parameters in sub components and altering the way that routes generate titles. Those are all possible and would have been a good opportunity for Jeff to engage with our very helpful community. Jeff makes one cricirtism that is very valid though. Our documentation on routing is lacking in some big areas. I don't think there's any doubt about that. It's something we're working to remedy. Perhaps this is the central reason why he thinks Aurelia's docs are a "mixed bag"? * Ecosystem - This point really frustrated me. Our community is not tiny. There are tens of thousands of companies using Aurelia all over the world. There are tons of very large, well-known brands using Aurelia. Unfortunately, we can't share these names all the time. Please understand that Google and Facebook have considerable influence over other companies that we do not have. For example, if company X uses Angular or React, they want Google/Facebook to publish that information because the Google/Facebook brand is likely bigger than theirs and they want to ride on the coat tails of the larger, more influencial company. In our case, Aurelia as a project, is almost always smaller than the dozens of Fortunate 500 companies that are using it. So, they don't have any motiviation to share that information. Because the bureaucratic legal and marketing hoops are so numerous, we end up not being able to share many things publicly. * Ecosystem Part 2 - We have tons of 3rd party modules for Aurelia. Jeff states that there are no third-party component libraries for Aurelia. That's not correct. We've had public announcements about Telerik and Syncfusion component libraries. There's also a Materialize component library and at least one very large community-based component library in addition to the collection of individual components that people have built. Aurelia itself has an official component library. It's early, for that library, true. One thing I take away from this is that we need to focus on and "highlight" even more in our official docs and site these 3rd party components, because maybe people just don't know that they exist.
Now, we realize that Aurelia is far from perfect and that we always have plenty of work to do and things to improve on. I and my team of about 30 engineers have poured countless hours, worth millions of engineering dollars into Aurelia. We don't have the brand power of Google or Facebook. Who does? So, if you write this type of comparison post, please be careful to validate the information and maybe even reach out to the project contributors for feedback. Posts like this can cast all our work in an overly-negative light, particularly for those who haven't encountered Aurelia before and don't know better. We're all working for the same thing here and want to help each other and our businesses succeed. I always take feedback like this to heart and I and my team will continue to work hard to make Aurelia better every day. We invite everyone to join our community and contribute together to making Aurelia the best platform for modern web apps.
Thank you for Aurelia btw... I've used both Angular 2 and Aurelia professionally now and Aurelia is hands down a better framework and it's ease of use makes up for lack of documentation (which has improved a lot over the past few months and SO answers are usually answered pretty quickly). I've not used React and would like to stay away from it since I find the JSX file to be a horrid mixing of concerns.
Here is interesting comparison of frontend frameworks popularity in job offers:
https://jobsquery.it/stats/frontend-frameworks/group
https://jobsquery.it/stats/frontend-frameworks/group
Urrgh, please stop using "opinionated" as a trendy, positive web development word. It's not even always certain that it is.
first time I hear about Aurelia.
I found Angular2 easier to start with, as I did not have to make decisions about what to use for router, DI, storage. With React (and React Native), there are many blanks to be filled, and hard to make a decision: Redux or Mobx?, which router?, who owns the style...
What about Polymer? It would be also interesting to see it compared to Angular and React.
Mithril, Mithril, Mithril
[deleted]
And we can compare them on LibHunt by CodeQuality, Popularity & Dev Activity
React VS Angular https://js.libhunt.com/project/react/vs/angular-js
React VS Aurelia https://js.libhunt.com/project/react/vs/aurelia
Angular VS Aurelia https://js.libhunt.com/project/angular-js/vs/aurelia
BONUS Vue.js VS React https://js.libhunt.com/project/vue/vs/react
It seems that Aurelia beats them all by Code Quality...
React VS Angular https://js.libhunt.com/project/react/vs/angular-js
React VS Aurelia https://js.libhunt.com/project/react/vs/aurelia
Angular VS Aurelia https://js.libhunt.com/project/angular-js/vs/aurelia
BONUS Vue.js VS React https://js.libhunt.com/project/vue/vs/react
It seems that Aurelia beats them all by Code Quality...
If you're going to flog your project, you should at least disclaim it as yours; it's only polite.
And you should actually define what "code quality" is, which in this case is apparently a really handwavy claim to cyclomatic complexity and similar metrics (which, while not entirely nonsense, don't mean much, especially at library-code levels when dealing with performance-critical code and the like).
And you should actually define what "code quality" is, which in this case is apparently a really handwavy claim to cyclomatic complexity and similar metrics (which, while not entirely nonsense, don't mean much, especially at library-code levels when dealing with performance-critical code and the like).
Aurelia beats them all by the aggregated, somewhat obscure "Code Quality" metric but is beaten by all of them in every other way. Except Ember, of course: https://js.libhunt.com/project/ember-js/vs/aurelia
No matter how accurate the metric is, a framework/library's value lies not in how perfect its code is. Nobody actually uses Aurelia (yes, that's hyperbole but even Ember beats Aurelia in every popularity metric except Downloads).
You can't simply define Aurelia into relevance, even if LibHunt backs it up. Also, who even uses LibHunt?
No matter how accurate the metric is, a framework/library's value lies not in how perfect its code is. Nobody actually uses Aurelia (yes, that's hyperbole but even Ember beats Aurelia in every popularity metric except Downloads).
You can't simply define Aurelia into relevance, even if LibHunt backs it up. Also, who even uses LibHunt?
Rather depends on how they're measuring "code quality". A very brief search didn't turn up any specific description of their metric.
If it's simply, say, "number of issues", or even something like "average age of open issues", then an actively used lib like Angular or React is likely to have "less quality" simply because more people have been using it and filing issues over time.
If it's simply, say, "number of issues", or even something like "average age of open issues", then an actively used lib like Angular or React is likely to have "less quality" simply because more people have been using it and filing issues over time.
Hey, thanks for the interest. It's much more complex. There's a link at the bottom of the pages pointing to a basic explanation - https://lumnify.com/grades/ . I hope that helps.
lumnify describes the criteria[1] but is incredibly vague about it. unless/until they give detailed reports on each project explaining how they arrived at their conclusions I think it's fair to treat these grades as pulled out of thin air. and even then it would be of very little/probably still no value. every project is different and you need to evaluate your tooling based on the situation.
1. https://lumnify.com/grades/
1. https://lumnify.com/grades/
They are not pulled out of thin air. You should contact them, and they will come with an answer. The algorithms have been tuned based on feedback from a number of Start Ups in Sydney.
they can open-source their methods/algorithms for public review if they want anyone to take their scores seriously.
Vue felt less intimidating at first, whereas React seemed to be overly complicated. Truth is, both are actually quite similar. The problem is that every single tutorial out there tells you: "React is only the V in MVC" (and so is Vue) but then goes ahead and implements all business logic in Components. I found it incredibly hard to learn about a sane (SPA?) software architecture. Some people throw in Redux and Vuex, but they actually only manage the state of the application. This is not where business logic goes.
Note: I haven't found a proper solution yet. Or let's call it this way: People dump their business logic in components and Redux and that works just fine to some degree, but they actually treat React more than the V in MVC. Just be aware.
React isn't that complicated, especially if you start out with functional stateless components, i. e. Components that only have a render function, props and no internal state. This helps to think about where state and logic should go and once you implement your first React components this way, you see that there's hardly any difference between Vue and React. Vue might let you even produce code that is more ugly than what you'd have produced with stateless components in React.
The beauty of React is that it forces you to think in a slightly different way. Vue seemed more accessible for a spaghetti code writer like I was (am?), but it wouldn't really challenge me in the same way like React does. Vue made me understand what reactive is all about, React helped me to think about state more clearly, especially if you want to slowly transition to functional programming.
Angular is often seen as a full application framework – and to some degree, that's true. But I suspect you'd gain a lot if you actually wrote your core application / business logic as if it wasn't part of Angular to make it more shareable. For example, if you want to go mobile with Angular, you could use Ionic, but it's not 100% compatible both ways and you must think of a way to structure your app so that certain parts (the model) is actually independent from the framework.
You could treat Angular more as a View-layer thing, which simply attaches a bunch of observers to your app state, which reduces the need for many APIs Angular offers and also reduces its complexity.
The OP wrote about dependency injection, which I found odd as a comparison metric. DI is a design pattern to solve a specific problem and React/Vue simply don't apply to this design pattern.
The main advantage of React over Vue and Angular is: React Native. Vue doesn't have anything close to it. Weex might be there one day, but right now, the docs are very incomplete, half in Chinese and I think it lacks a lot of components React Native already has. With Angular, the logical framework to build hybrid apps would be Ionic. Ionic is nice for specific cases: When your app is read-only!
This isn't about performance (it's solid on newer devices) – it's forms and input controls. This is where Ionic shows the ugly side of the underlying Webview: Mobile Safari simply sucks for things beyond a simple input field. Want to show a picker for the date that only shows 15 minute intervals? Good luck with that. An input field that allows decimal only? Your best bet is type=tel and neglect the decimal point separator. Or use the rather un-performant and ugly DatePicker that comes with Ionic.
But this is a thing where even average users notice a difference to native input controls. If your app is mostly read-only with nothing more than a button and a toggle as input controls, by all means, go with Ionic. Have a form in it? Make a minimal prototype with just this form and see for yourself how it plays out.
React is learn once, write everywhere, because you can't really share any component-related code between React and React Native. In React, you use HTML elements, in React Native, you use native elements.