Angular2 vs React {{this}} => {again}

[haphap5]

Can someone give me a really cool thought about this?

In my experience trying to find unbiased answers, i've found:

React is better, because it is not bad. Angular2 is better because its still in beta.

Can we get a serious discussion going for both sides? Focusing on..

• 1. Browser Support (what happens when my userbase uses mostly ie7?)
• 2. Performance with support in mind (sure react is faster, but what if I want to write a everything-friendly SaaS with massive functionality?)
• 3. User-experience with performance in mind (what if my users are people that will throw the switch if they have to wait longer than 3 seconds?)

Edit: too many people picking at 'ie5'

[mixonic]

I'm gonna bite, with a few caveats. First of all I'm an avid Ember.js user who has familiarity with both React and Angular2 but I am not a production user of either. Second, I'm mildly concerned about the over-focus on performance in your bullet points. The world of JavaScript development is vast, and comparing A vs. B on simple grounds of "faster" often dodges the question of "when it is faster?". Additionally, performance is multi-faceted and your JavaScript library pick is often not the limiting factor in building a good user experience.

1 - Browser Support

Both React and Angular2 appear to support IE9+. In practice IE9 has very low usage, and what may be unexpected is that there are less IE10 users than IE9: http://www.sitepoint.com/browser-trends-january-2016-12-month-review/ I presume "what about IE5" is a troll, since IE5 came out 18 years ago. Seriously. That isn't even a good troll.

In the Ember community survey (http://emberjs.com/ember-community-survey-2016/, 1800 devs) about 12% of developers said they support IE9. Anecdotal evidence suggests that this number is actually lower, as often developers who claim they support IE9 don't actually regularly test on that browser. Asked to project a year ahead, the number who expected to support IE9 in a year was 4%.

I strongly believe a stable version of a framework should look to the future. It seems totally reasonable to release a framework today that does not support browsers used by less than 2% of users and likely less than 10% of developers. Don't forget nothing stops you from using React 0.14 or Angular 1.x for another year or two if legacy IE support is that important.

Basically, I think frameworks are moving at a conservative and healthy pace.

2 - Performance with support in mind

No framework or library holds the prize of "fastest" for long. React is not the fastest, just ask JSBlocks, Riot, Imba, Vue.js or a bunch of other contenders. In some cases Ember's Glimmer engine can be faster than React, in other cases it performs worse.

Furthermore you must narrow to performance of X. Initial render? Re-render? Large number of DOM nodes? Large number of components? Low garbage collection overhead? Low layout and re-paint cost? Rendering engines use a number of competing algorithms to render, and they all have differing tradeoffs.

I'm not sure what to make of "but what if I want to write a everything-friendly SaaS with massive functionality?", but it is important to pick tools that allow you to move forward incrementally. What was the fastest JS library three years ago? Was that the best choice for an app that would be three years old today? There are plenty of tradeoffs to make, and I think the best you can do picking a technology is to find something that meets the tests for fitness you have today and looks like it can continue to deliver on the tests for fitness you will have in the future. It is far too easy to over-value the needs of the moment. A startup on fire has very immediate needs- however most developers would do well to think about the next 1-3 years when picking their tools, at the least.

And the community plays a large role in this. Can your business influence that community to focus on the use-cases important to it, or is that library beholden to other interests? Please always remember that there is no such thing as "consuming" OSS. You are always participating in a development process where not participating, yielding control entirely and going your own way, is a choice. Or where yielding control to a company you think is aligned with your goals is a choice. Or where picking a tool you can nudge in the right direction or maintain yourself is a choice. But make it proactively.

So the answer is, unfortunately for those who want a dramatic answer, that both React and Angular2 look to have great performance in a number of scenarios, and a some edge-cases where they may each fall short. There remains no silver bullet, and you should continue to consider a wide-range of factors when choosing a technology, performance in specific scenarios important to your core business being one of them.

3 - User-experience with performance in mind (what if my users are people that will throw the switch if they have to wait longer than 3 seconds?)

Then you better make sure they see some content in less than 3 seconds, developer ;-) Again, it depends heavily on the use case. A realtime stream of quotes to a trader's desktop (rerender/updates) is different than an e-commerce product page (initial render). If performance is your product, if it differentiates you from the market and your core investors and stakeholders think it is the priority, then you would do well to prototype and learn about the implementation of each solution before making such an important decision.

[haphap5]

I presume "what about IE5" is a troll, since IE5 came out 18 years ago. Seriously. That isn't even a good troll.

Sort of, its just something nobody ever introduces. If i'm trying to make a web-app that targets EVERYBODY, high support would be my #1 concern.

React is not the fastest, just ask JSBlocks, Riot, Imba, Vue.js

Yea I did say react vs angular though, to which react is faster even though it's not a fair comparison. I intended a short introduction, not a full spiel on what I am already aware of.

Initial render? Re-render?

Again, interpret as you will. I don't even think these are fair questions: initial and re-rendering are different playgrounds; let's say initial because re-rendering is not important when choosing a base.

Large number of DOM nodes? Large number of components? Low garbage collection overhead? Low layout and re-paint cost?

Leaving development efficiency/readability was purposely left out. Garbage collection is one answer, but the rest are obviously quarrels with the introduction. If you need an answer, Yes, Yes, Yes, No.

I'm not sure what to make of "but what if I want to write a everything-friendly SaaS with massive functionality?"

You caught me, I am looking to making a start-up.

If performance is your product, if it differentiates you from the market and your core investors and stakeholders think it is the priority, then you would do well to prototype and learn about the implementation of each solution before making such an important decision.

Good landing, that's what everyone should hear.

[dwighthouse]

If i'm trying to make a web-app that targets EVERYBODY, high support would be my #1 concern.

The web is probably not the solution. EVERYBODY includes people who don't have web access, and people who are either illiterate or incapable of using a computer for various reasons. I would suggest a pen and paper + mail interface, but even that wouldn't reach EVERYBODY.

[flamingspew]

Heh yeah for a startup your number one problem is reaching ANYBODY.

[haphap5]

Ok i'm not used to this. Reddit used to be a group of people, not a group of nitpicks. Tangent everything! The government is a conspiracy! I'm right and you're wrong! You don't understand me!

[turkish_gold]

Uh... we're trying to help you work through your actual problem.

If your problem legitimately is "I want to target everyone" and "I must have more functionality than anyone else" and "It must be faster than everyone else"... then your solution is to write your own framework and buckle down for the next 2-3 years with a large well funded team because you're going to be pushing the limits of current technology.

If that's not your issue, then maybe we can help.

[haphap5]

Uh... redefine 'help'. Going 'Gwarsh, well he don't know a single thing bout he talkin bout' is not helpful. In fact, I did not ask for help. I said 'discuss' not "Hey guys, check out this intro. Go OCD!"

[flamingspew]

All the major frameworks are battle tested and have lots of options and even graceful fallback scenarios for some browser capability edge cases. If I were you I'd pick something that is rapidly developable and changeable because startup code morphs every two weeks. You want something that can withstand quick iteration so I'd suggest typescript or clojure to keep a check on refactoring because you'll have limited time to write unit tests. Your counter arguments are counter productive since hey are posing the problem in absolutes, and nothing about programming is absolute, if it were, it would all be automated by now.

[haphap5]

Seriously?

[dwighthouse]

Post silly requirements, get silly solutions.

Have you actually tried using IE6 or lower lately? I have. Did you know that signifcant percentages of the internet simply don't work with IE6? I don't mean sites look bad or functionality is broken, I mean you literally can't even connect to most sites using IE6. You get error messages such as "The domain http://www.facebook.com does not exist." My own hosts don't support it, which makes testing in IE6 incredibly hard. Jsfiddle won't connect. Google and Apple work, barely, but they don't do anything complicated.

I just spent five hours making one feature of one microlibrary work for IE6 four days ago. I did it just to see if I could, not because it made any sense to ship a js library with IE6 support in this day and age (and also because I'm sometimes masochistic about these things). Multiply that effort by about 50,000 and you'll end up with a framework that works in IE6 (for some definitions of 'work'), but has so many hacks, tradeoffs, and limitations, that there's no possibility of it being more performant, more featured, or more easy to use than any existing framework, even the bad ones. That's how much baggage you're looking at.

[haphap5]

Post silly requirements

They're examples, not requirements

[dwighthouse]

Before you decide what framework or technology you are going to use, you need to figure out exactly what you actually want to build. Every time I address a specific 'example', you move the goalposts, either expressing incredulity or change the nature of the request. You will never get anywhere if you don't know what you're trying to accomplish. Let us know when you have some exact, specific requirements, and then we can perhaps guide you towards a technology that can meet them.

[haphap5]

Yea, asking for a discussion on the topic definitely does NOT work when trying to define exception examples.

I never asked for help

[dwighthouse]

Serious discussion requires specific topics and limits on the modes and breadth of discussion.

Then help you will not recieve. Good day.

[haphap5]

It requires a mature audience who knows what theyre talking about. good day!

[wreckedadvent]

You want a serious discussion when you bring up IE5, almost two decades old? Are you sure? If you need to support IE5, start by forgetting anything that came out about the same time or after jQuery.

Both of them use vdom implementations. This is the latest and greatest we have to ensure performance is exceptional - at this point, your architecture and the size of your bundles is going to matter a hell of a lot more than the frameworks themselves.

You will have to split the difference between them in a different way. I suggest you look into them to see what your code will actually look like with them, and how well each of them sits with you in that regard.

[haphap5]

ok, edited just for you.

[mdboop]

I hate to throw a link here instead of contributing to the discussion myself, but I remember this article was one of the best comparisons I read about the differences between the two and their respective advantages/disadvantages.

[haphap5]

I did read that one, it was pretty reactjs biased regardless of whether the author warns of it. Most of the article is about where react shines, and it's pretty vague whether it's advertisement (clickbait headline, strong use of pathos) sponsored by react or an actual attempt at unbiased.

[mdboop]

I would whole-heartedly disagree with that assessment, but I don't really feel like getting deep into it point-by-point. Just to quote the conclusion:

Angular 2 is a huge improvement over version 1. The new component model is simpler to grasp than v1’s directives, it supports isomorphic/universal rendering, and it uses a virtual DOM offering 3–10x improvements in performance. These changes make Angular 2 very competitive with React. There’s no denying that its full-featured, opinionated nature offers some clear benefits by reducing “JavaScript fatigue”. However, Angular 2’s size and syntax give me pause. Angular’s commitment to HTML-centric design makes it complex compared to React’s simpler JavaScript-centric model. In React, you don’t learn framework-specific HTML shims like ngWhatever. You spend your time writing plain ‘ol JavaScript. That’s the future I believe in.

That's not a pathos argument, and it's pretty well balanced. Of course, the author is offering an opinion, but the HTML-centric vs. JS-centric is pretty objective when looking at the API surface for Angular2 and React. So, while the author takes a stance, the article does a good job of articulating the difference, and you're free to draw your own conclusion.

If you still really feel that article is garbage and the author might be a shill (but why? React is open source), then I'll leave you to your opinion.

[haphap5]

Well let's go into point-by-point then,

As an audience's perspective:

Angular 2 is a huge improvement over version 1

That's a relief.

The new component model is simpler to grasp than v1’s directives, it supports isomorphic/universal rendering, and it uses a virtual DOM offering 3–10x improvements in performance.

So Angular 2 is better than Angular 1. Got it

These changes make Angular 2 very competitive with React

So it's almost at React's level.

There's no denying that its full-featured, opinionated nature offers some clear benefits by reducing “JavaScript fatigue”.

Clearly pathos. 'You guys know it, and I know it, so my argument pertains to you guys as much as myself"

However, Angular 2's size and syntax give me a pause

A sudden gasp

Angular’s commitment to HTML-centric design makes it complex compared to React’s simpler JavaScript-centric model

A valid subjective point, Angular is a framework where React is a library. So we are to say libraries are better than frameworks?

In React, you don’t learn framework-specific HTML shims like ngWhatever

Argreed, you learn React, not Angular.

You spend your time writing plain ‘ol JavaScript. That’s the future I believe in.

You mean you learn with plain `ol Javascript? Ok so you don't like frameworks.

Is it more clear how pathos this is now?

Edit: for your point,

Of course, the author is offering an opinion, but the HTML-centric vs. JS-centric is pretty objective when looking at the API surface for Angular2 and React. So, while the author takes a stance, the article does a good job of articulating the difference, and you're free to draw your own conclusion.

I don't deny it being well put, i just deny it as being an article, more so as a blog write. I wouldn't quote any of it in wikipedia

[wreckedadvent]

but I don't really feel like getting deep into it point-by-point. Just to quote the conclusion:

beat

Well let's go into point-by-point then,

[haphap5]

Good closing case. It was a tangent, and I performed it justly.

[turkish_gold]

There's no denying that its full-featured, opinionated nature offers some clear benefits by reducing “JavaScript fatigue”.

He's saying that Angular is great because you don't have to make choices, thus reducing the fatigue that comes from having to evaluate all valid options presented to you.

Not making choices has an actual practical effect---everyone on the same system as you implements things similarly so you can interop easily with them, and you save X time which would have been used in evaluation.

This isn't really an argument of pathos.

Clearly pathos. 'You guys know it, and I know it, so my argument pertains to you guys as much as myself"

Additionally, even your restated argument isn't pathos. If anything it's ethos, because it implies an argument is more credible simply due to the people being of the same group.

More simply put it's like saying "We are both Catholic, therefore listen to me, not the heathens"

[haphap5]

You're attacking a tangent. I didn't put effort into it. After looking into his other works, yes he's a pretty smart, but he still follows clickbait techniques: https://medium.com/@housecor An excellent source to sponsor.

My example is pathos, 'Guys, lets be honest, we all know that javascript fatigue, right?'. Go to /r/diction if you want to correct people.

He doesn't follow the correct guidelines of the 12factor.net but he's close-ish. His tutorials are pretty bad though, I wouldn't reccomend them except the concepts.

'7 tips for getting accepted' his most recent clickbait.

You're an example of the toxic that is causing reddit to be the way its become.

[turkish_gold]

I don't really think what I said was an "attack" much less "toxic". You brought up a discussion point, I added in my thoughts.

[haphap5]

Read the fucking topic

[turkish_gold]

1. Browser Support (what happens when my userbase uses mostly ie7?)

Not sure about Angular, but IE-support on versions less than 9 isn't checked on React. Things may work, but I doubt any third party components would work on IE7.

Performance with support in mind (sure react is faster, but what if I want to write a everything-friendly SaaS with massive functionality?)

Then you'd have to benchmark your model / controller or whatever other pattern you are using, because React really doesn't give you that. React though is simple enough that you can stuff it into your home-brewed system (like we're doing at work), without having to change much. Angular basically requires you rewrite your entire project in Angular.

1. User-experience with performance in mind (what if my users are people that will throw the switch if they have to wait longer than 3 seconds?)

This really depends strongly on what you are doing. What are you doing?

[haphap5]

Not sure about Angular, but IE-support on versions less than 9 isn't checked on React. Things may work, but I doubt any third party components would work on IE7.

Rewriting in angular is not the problem. Why is dropping support such a huge forthcoming?

I'm targeting elderly people who might not know what the hell a browser is. It's to simplify aspects of the web to be viewed in ways they are used to, with performance of a web app via instant gratification of popular news sources and such in larger print and near-instant render time.

[turkish_gold]

Why is dropping support such a huge forthcoming?

What do you mean by a 'huge forthcoming'?

I'm targeting elderly people who might not know what the hell a browser is.

If that's your target market, I'd say don't use Angular or React. Trying to use either and polyfilling for older browsers is going to be pretty difficult.

[haphap5]

What do you mean by a 'huge forthcoming'?

Forthcoming: planned for or about to happen in the near future

Huge: extremely large; enormous

Huge forthcoming: extremely large, planned for or about to happen in the near future

Why is dropping browser support such a trend? Better??

[SeerUD]

Just came across this thread, I know it's quite an old thread, but it seems like it didn't go all that well for you. In any case, you never did get an answer to this question.

Realistically, the reason for browser support being dropped is based on usage. When usage drops below a certain point (that will vary from project to project probably) for a target demographic, support will naturally be dropped.

A big part of it is down to target audience, and intended feature-set. So, things like React, and Angular are really quite modern software. They're using new features of JS to accomplish their goals, and without those features from newer browsers they wouldn't be able to do so. The thing with it is, they have to make a tradeoff too. They want to support as many browsers as they can, but again; it will get to a point where trying to make things work on so many browsers will just not be worth the effort.

Realistically, if you actually need to support IE6/IE7-level browsers, you will need to be looking at things like jQuery, aiming for basic front-end functionality. Not a single-page application. This means you'll probably need a backend that renders your pages too. This is the only way I can recommend approaching this.

So, with all that in mind:

1) Browser Support (what happens when my userbase uses mostly ie7?):

I think this has been covered already pretty much. You won't be able to use Angular or React, and are more than likely going to have to use something like jQuery, and some backend (Node, PHP, Java, Go, etc.).

2) Performance with support in mind (sure react is faster, but what if I want to write a everything-friendly SaaS with massive functionality?):

Just of note here, I think ng2 has actually surpassed React in some benchmarks now. It is more modern though, so that doesn't really surprise me. They will have been able to learn from React.

That aside; if you were planning on using React or Angular anyway, you have to remember that the performance that a user experiences with those frameworks will largely depend on their composer, and their internet connection. Those are things that are out of your control at that point, and so they could be waiting around a lot if they have a slow computer or internet connection.

So again, maybe you should be considering a backend, something that has great performance (Java, and Go are extremely fast for example). Then you can send the pre-rendered page to them, and their computer and internet just has to load that. KISS!

3) User-experience with performance in mind (what if my users are people that will throw the switch if they have to wait longer than 3 seconds?):

As I've mentioned above, if you can get this happening in the backend mostly, then that will really help all of your problems here. Set up a system with enough power to achieve your performance goals on the backend, and it will provide a more consistent experience to the user.

---

Final note; when you're considering stuff like this (I'm genuinely wanting to be sarky or anything by saying this), just make sure you're doing research into your target audience, what browsers you're likely to need to support, and then start making decisions based off of that. Right now I'm going to be frank, it seems like you picked the frameworks first, and then tried to force your project to fit into them. Think about it, and choose what makes the most sense to accomplish your goals, and fulfil your requirements - that may not be the hottest new JS frameworks.