Opinionated Comparison of React, Angular2, and Aurelia
github.com
github.com
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.
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.
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.
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 ).
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".
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/
- 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.
> 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 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."
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).
- 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.
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!
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 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.
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.
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" onClick={() => this.setState({value: 'X'})}>
{this.state.value}
</button>
);
}
}
Wrong. It's a template language, even if Facebook tells you otherwise.
return React.createElement(
button,
{ className: "square", onClick: () => this.setState({value: 'X'}) },
this.state.value
);
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.
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.
I want to write this, and have it actually be HTML:
<div>
<div>
</div>
<div>
[1]: http://sgmljs.net/docs/templating.html
Disclaimer: my project, and SGML is most certainly not a "lightweight template engine" by any measure
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.
Or could you not hear me over the sound of that axe you're grinding? :)
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.
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.
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.
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 ...
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.
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!
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.
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.
Fair cop. Not sure why I'm participating in a JavaScript framework internet discussion. I wish people would concentrate on standards, and apps.
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?
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.
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...
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/
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....
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.
>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.
Your startup either dies or lives long enough to become a hodgepodge of ten different frameworks.
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.
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.
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.
It was a huge step forward, but that was several steps back...
There were plenty of new paradigms and new headaches before the JQuery era!
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 .
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...
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?
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.
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.
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).
/s
Vue.js has an official router, and an official "redux" like data store.
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.
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.
What is the story that FP folks need to tell here, so that people don't do things like 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...
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!).
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.
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.
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.
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.
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.
Did you only read the part about the documentation?
* 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.
Here you go https://angular.io/docs/ts/latest/guide/style-guide.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.
Simplicity brings its own rewards.
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.
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 :/
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.
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...
But I would kill to see a middle ground between react and angular.
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.
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).
And to think people complain about GTK changing too frequently...
(I had approached React right when the infamous Babel5->Babel6 transition happened, and was seriously burned by it.)
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.
If you really like these two things, try CycleJS. It's basically "Angular 2 the good parts"
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.
* 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.
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...
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).
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.
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?