Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Angular 2 versus React

medium.com

Post reply on HN
Print view View original

161–170 of 249 posts

Re: Angular 2 versus React

#161

Post by iamstef »

voltagex_ wrote: post #134
ralmidani wrote: post #55

Earlier quoted context omitted.

I'm building an app with Ember, and I like how it abstracts away the more tedious aspects of web development without preventing me from moving to a lower level of abstraction when I need to. I've built a small app in vanilla JS, so I know what the alternative to using a framework is like. Doing XHR by hand is not easier than using Ember-Data. Writing custom JS components is not easier than extending Ember's Component…

What do you think about Ember's mobile performance problems?

First of all, let me share a wonderful (and performant) mobile app, written in ember. It uses ember-data to connect/normalize the iTunes api, and provide a slick fast mobile experience.

https://fnd.io/

Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io)

I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc.

Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought.

PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester.

As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to.

The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers.

This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth.

The important part being, all parties involved are working towards (and together) on a better faster more wonderful future.

Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer (written in TypeScript), V8 with turbofan and the team, working together to improve JavaScript in the browser for everyone.

Re: Angular 2 versus React

#162

Post by thedufer »

plexicle wrote: post #9

To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons. Why aren't we talking more about that? Polymer is a fraction of the size. It's one of several ways right now to write custom components. React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For wha…

> React's perverted DSL and crazy toolchain

JSX is very much optional, despite what the docs imply. I've had good luck with converting a DSL that I was using to spit out HTML to React components that made the transition fairly painless: https://www.npmjs.com/package/recup

Re: Angular 2 versus React

#163

Post by novaleaf »

voltagex_ wrote: post #143
moogly wrote: post #141

Earlier quoted context omitted.

Node/NPM is installed as part of Visual Studio 2015 these days, is it not? Edit: Note I'm not saying you should install VS2015 just to get Node, but it might help you convincing the powers that be that "hey, Microsoft installs these components as part of VS2015, so it's not that weird, I promise".

Yeah - at the moment we don't have VS2015, but as long as that particular node.exe is signed with an MS certificiate it'll run fine.

Microsoft doesn't sign the node executable.... it is signed though (Node Foundation)

Re: Angular 2 versus React

#164

Post by [deleted] »

plexicle wrote: post #9

To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons. Why aren't we talking more about that? Polymer is a fraction of the size. It's one of several ways right now to write custom components. React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For wha…

[deleted]

Re: Angular 2 versus React

#165

Post by jbigelow76 »

doczoidberg wrote: post #119
eyko wrote: post #89

Earlier quoted context omitted.

I believe people generally mean that Google isn't using it for any of their core products: Gmail, Search, Google+, Photos, YouTube, Google Play, Calendar, Drive, Maps... none are built with Angular.

adwords is not a google core product? the angular team works together with the adwords team

Pfft, Adwords might be responsible the lion's share of Google's 522 billion dollar market valuation, but to call it "core"? That's a bit of a stretch.

Re: Angular 2 versus React

#166

Post by JoshMnem »

spicyj wrote: post #129
JoshMnem wrote: post #117

Earlier quoted context omitted.

The last I heard, they weren't allowed to use it. If you could link to a Google product that uses React, I'd like to take a look.

I don't have links to any; they might be all internal. The current iteration of the patent grant was developed in collaboration with Google to meet their needs, so if there is any complaint they still have with it, that is news to me. Only public evidence I have of this is Firebase (owned by Google) being unwilling to use React and then happy with the new license: https://twitter.com/KanYang/status/586636624349569024

I would like to find out more specific information. It seems like the section of the license below says that you can never make any patent claim against Facebook or you lose rights to use the software. Doesn't that mean that Google could never initiate patent claims against Facebook, while Facebook could still initiate patent claims against Google? It seems strange that Google (or Apple) would do that. I am not a lawyer though, and the PATENTS file may not mean that.

> The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.

Re: Angular 2 versus React

#167

Post by iamstef »

jameslk wrote: post #53
PaybackTony wrote: post #30

This is continuing to shape up to be another one of those preference debates. I prefer the Angular approach, as its end goal is to simply make web markup what it should be: Interactive. The downside being that you're forced into Angular's opinions for better or worse. I don't prefer the more "tangled" approach of React. I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTM…

I've used Angular, React, and Handlebars (Ember's templating engine), and I can tell you, they are all the same in "tangling." They all solve this problem by emphasizing that the view portion of the code (Angular's pseudo-HTML, React's JSX, and Handlebar's limited helpers) should be used strictly for view-related logic, not domain/business logic. So there really isn't any difference between the libraries in that resp…

> Handlebars (Ember's templating engine)

Just a pedantic touchup, ember does not use Handlebars (it once, several years ago did) Now it uses something (Glimmer) which shares some syntactic similarities, but usage/implementation have diverged.

Re: Angular 2 versus React

#168

Post by Bahamut »

lewisl9029 wrote: post #110
Bahamut wrote: post #54

There are some slight inaccuracies here, such as file size reporting - Angular 2 is fat at the moment only because it is bundling the whole kitchen instead of just the one piece that is the library itself. The Angular 1 number also is off too - this link is giving me 52.8 KB for example (minified + gzipped): https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a... (all numbers I remember seeing for angular 1 w…

> I'm personally on the Angular side of the fence, I prefer the more declarative style to avoid the imperative DOM construction, but I could work with either (and have worked/am working with both) if they are done right. If by declarative , you mean artificially limiting, then I agree with you, but in my humble opinion, the React approach allows for far more declarative UIs than approaches that come before it. Templa…

React uses an imperative style, not declarative - when one uses this.items.map(item => {item.name}), this is imperative, not declarative. You are describing the DOM with imperative language - JSX cloaks what is truly an imperative nature. This is made more clear with the non-JSX equivalent. When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language.

Angular's templating is clearly declarative since one is not making a statement about how it arrives at its result, but purely describing it and leaving the implementation elsewhere. Something like {{item.name}} leaves the iteration implementation away from the view completely. Every piece here is descriptive, not something more.

It should be noted that Angular 2's DOM model uses an AST under the hood, just like React - fundamentally they are the same in the virtualization of the DOM. Angular 2's templates are not true HTML either, but is closer to HTML than React is in its syntax. It does limit what you can do, but that is the purpose of templating languages - it limits what you can do to increase readability, increase consistent patterns, and steer users away from dangerous usage. That is an argument aside from declarative vs. imperative templating, and more emotional than useful.

Now, both approaches have obvious flaws - both styles are easily (and often) abused, but both also have simple conventions to keep it clean. Imperative construction (ala React) requires one to carefully organize the control flow to avoid convoluted template construction. Declarative construction (ala Angular 1 + 2) requires one to avoid tossing too much in a singular template. What is easier to work with, that is not for me to say as an absolute, but IMO carefully organizing the control flow in template construction requires more mental overhead to avoid constructing the template in a hard to read fashion, and yet still involves the same ultimate basic strategy of having to create separate components to avoid overly complex templates, which is what one has to do with declarative template languages, but without the mental overhead of accidentally abusing control flow in its construction.

Re: Angular 2 versus React

#169

Post by spectrum1234 »

It seems like Redux + React is clearly going to win out. What am I missing?

Yes the ecosystem is constantly changing right now but the oscillations are getting smaller not bigger. In my opinion Redux is the highest level and most intuitive, just like React was for the view when it came out. It's only a matter of time.

Re: Angular 2 versus React

#170

Post by PaybackTony »

rimantas wrote: post #81
PaybackTony wrote: post #30

This is continuing to shape up to be another one of those preference debates. I prefer the Angular approach, as its end goal is to simply make web markup what it should be: Interactive. The downside being that you're forced into Angular's opinions for better or worse. I don't prefer the more "tangled" approach of React. I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTM…

> to simply make web markup what it should be: Interactive I guess I missed the memo. When did it happen that web markup suddenly got a need to be interactive?

That's a good point, I think I should of said "Dynamic" for lack of a better word. Interactive, it needn't be.
Post reply on HN