Live data from Hacker News

Opinionated Comparison of React, Angular2, and Aurelia

github.com

21–30 of 169 posts

Re: Opinionated Comparison of React, Angular2, and Aurelia

#22

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.

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.

Re: Opinionated Comparison of React, Angular2, and Aurelia

#23
post #16
post #9

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.

Re: Opinionated Comparison of React, Angular2, and Aurelia

#24

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

You make it sound like no one has ever had to make a decision to choose between different frameworks.

Re: Opinionated Comparison of React, Angular2, and Aurelia

#25
post #16
post #9

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.

in other words, you don't call functions, you send messages.

Re: Opinionated Comparison of React, Angular2, and Aurelia

#26

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.

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.

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.

Re: Opinionated Comparison of React, Angular2, and Aurelia

#27

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.

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.

Re: Opinionated Comparison of React, Angular2, and Aurelia

#28

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

Re: Opinionated Comparison of React, Angular2, and Aurelia

#29
I've spend a lot of time evaluating Angular + Ionic, Vue and React. My goal is to rewrite my webapp as a SPA with complimentary mobile apps. Maximum code sharing would be nice. I'd like to add to the discussion what I learned and also add Vue for comparison.

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.

Re: Opinionated Comparison of React, Angular2, and Aurelia

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

Post reply on HN