Live data from Hacker News

Angular 2 versus React

medium.com

71–80 of 249 posts

Re: Angular 2 versus React

#71

React's learning curve is tiny compared to Angular. With React, you need to understand the component API, which consists of about 5 methods that one uses regularly, and the top level API, which consists of 2 (or just 1 if you use ES6 class syntax to create components). And as the article points out, it's just JavaScript.

I've briefly used Angular 1 a few years ago, and have been involved in the React ecosystem for the last two years. I really like React, it gets a lot of things right and I think it has a bright future. But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. As soon as you get past a "hello world" Todo app, even trying to figure out what questio…

> But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development.

Totally agree. Doing anything large-scale is hard, and comes with a massive learning curve. No React or Angular can save you from learning what it means to go from "hello world" to working on a project with a team of, say, 10 people.

Re: Angular 2 versus React

#72

Earlier quoted context omitted.

Well, browser compatibility is still a big problem with Polymer. A simple click-and-select-stuff-quickly-while-moving-mouse-around test can often lead to focus and/or the selection being "stuck" on Firefox -- even on simple widget demo pages. (This was a few months ago, things may have improved.) Probably on other browsers too. React works perfectly today. > I see 2016 as the year that people slowly begin to realize…

I should say, my post was more about web components and less about Polymer. Polymer is just one way to do it right now, and you're right, it is opinionated. You don't need a library at all if that's what you prefer. The polyfills are there now and they are solid. Webcomponents.js is small and effective. The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper e…

> The polyfills are there now and they are solid. Webcomponents.js is small and effective.

This leads to a tangential point which I find somewhat interesting to ponder: If the polyfills are good enough... then why does this actually need to be a browser standard?

I'd really like to get to a place where we (collectively) find some sort of minimal API-type "thing" that browsers need to support such that everything else can be polyfilled. I would even go so far as to include things like future ES standards in that, such that you could just "plug in" (in the page, not the browser per se) a shim for ES2015 and it would work near-natively. I know Microsoft Research had at least one project going in this direction -- unfortunately its name escapes me at the moment.

> The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.

FWIW, that may very well be true. AFAIR all my tests were done with the paper elements.

I definitely agree that Web Components in some form is the future of application development for the web -- unless we're talking stuff that mostly just wants to use the browser as a delivery platform like WebAssembly. Of course that may change if/when WebAssembly can interface well with the GC/DOM/etc. (Well, come to think of it Web Components might also be massively useful for authoring documents sanely using custom components for higher-level semantic elements, but that's a digression.)

Just FTR as well, I have actually implemented a small application using Polymer just to get a feel for what it's like. Overall it was reasonably pleasant as Web development goes, but it's really disconcerting that all the state[1] passed down to sub-components gets represented using attributes-but-not-really-because-they're-not-primitive-types-any-more.

[1] At least, that's the idiomatic way, AFAIUI from Polymer documentation.

EDIT: I should edit while I can: I semi-believe that Web Components is sort of along the right lines wrt. what needs to be standardized (and perhaps WebAssembly + an interface to the WebComponents API can do the rest?), but frankly I probably don't have nearly enough expertise in this field to even have an opinion. So there. :)

Re: Angular 2 versus React

#73
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…

It's pretty easy to write "complex conditional DOM that is hard to read" in both React & Angular. But in my experience, I encounter it a lot more in Angular code bases than React code bases.

That's certainly a fair statement - I found the imperative style generated from JS directly harder to debug/work with in general, but that's why I mentioned it's a bit team dependent. Each developer's experience is going to bias them towards one or the other.

Re: Angular 2 versus React

#74
post #19
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…

Why did Google create Polymer? Google isn't using it. This is almost the same 'problem' with "AngularJS by Google", it's almost never used by Google. Edit: The reason I like React more is the fact that Facebook uses it in a high traffic production setting. Edit 2: I think the whole Javascript (or framework) fatigue is just a 'transition problem'. Old tools are getting replaced by new tools, causing confusion..

Google has been using Angular 1.x for DoubleClick since 2012 (http://angularjs.blogspot.com/2012/06/doubleclick-super-powe...). I think it's fair to say that it's one of their most important products.

Re: Angular 2 versus React

#75
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…

One thing I like about both Polymer & React is that they encourage you to treat your apps as a composition of components, as opposed to each page being a wall of HTML with a few variables substituted in.

That being said, React really makes it easy for those components to be tiny little things that do only one thing, that compose nicely, and that are easy to understand. There's a heuristic in programming that if a function is more than a page in length, it's probably too complicated. The same heuristic applies to React: if your component (JS, JSX & CSS together) is more than a page, it's probably too big.

Just the act of splitting apart the JS, JSX & CSS encourages the components to become much larger.

Re: Angular 2 versus React

#76
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…

I think you're gonna like Aurelia[1]. It's badass compared to Angular 2, React & Polymer. You get this really, really nice feeling of writing pure Javascript. It's smaller than Angular, strictly follows Javascript standards which is soooo nice. No {{bindingVariable}} but instead: ${bindingVariable} // Just like in Javascript template strings! Binding? Sure: Two-way? Of course: One time? Yep: The templating is so simp…

Are there any examples using this in the wild? I couldn't find any 'Sites powered by Aurelia' page on the site. Would be interesting to see some full fledged sites (besides the project site).

Re: Angular 2 versus React

#77
post #37

Earlier quoted context omitted.

Note that mithril is much more lightweight than react, offers a similar vdom model, but has a completely different algorithm for deciding when to redraw. I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.

There are a bunch of alternative implementations. The vdom benchmark [1] is a fairly good list but I've run across at least two more that aren't tracked there. [1] http://vdom-benchmark.github.io/vdom-benchmark/

Which two?

Re: Angular 2 versus React

#78
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…

This will only happen when there isn't a significant portion of new programmers entering the field/language/type of work. As long as there are people that don't know how to write pure, well-written and fast web apps, large frameworks will have a place. This is a good thing, because the more new programmers that try to figure this stuff out themselves the more clusterfuck projects we have. Frameworks allow for an easy onboarding process, where the people that need to reach deeper to accomplish something then look how to do that, and learn as they go.

There are parallels here with languages. Perl, which garnered a reputation as a write-only language, has seen a dramatic increase in the quality, legibility and effectiveness of modules over the last decade, and this corresponds well with the lack of an influx of new programmers (but with a minimum core of users still present to implement new modules). That said, there are many, many other problems when you don't have enough new blood flowing into your ecosystem, so I don't recommend it.

Re: Angular 2 versus React

#79

React has a non-open license: https://github.com/facebook/react/blob/master/PATENTS , which basically says that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This is an automatic no-way for React for any major company

Yes... I'm really surprised that people aren't talking about this more seriously. They have removed the worst of it, but it still looks like it gives Facebook an advantage in any patent conflicts with any company that uses React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It appears that the PATENTS file claims that if Facebook infringes on your patents, you can't defend your patents without a risk of immediately losing the ability to use React (or other Facebook library). Maybe a lawyer would be able to make more sense of that PATENTS file.

I'm surprised that Apple might be using React, since they have had big patent battles with Facebook:

http://www.meetup.com/ReactJS-San-Francisco/events/227071839...

http://www.theguardian.com/technology/2015/jul/21/facebook-g...

I've heard that Google doesn't use React, but I don't know how long companies will be able to do that as Facebook libraries increasingly become dependencies of other libraries.

Re: Angular 2 versus React

#80
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…

At work we are using Polymer / Web Components since version 0.5 and have been enjoying it's structured approach. I was skeptical at first to use html tags to add data models, AJAX requests and non-visual parts of a web app. After the initial shock though it does result in more declarative code and helps our codebase stay organized. Long term, the investment in web components makes sense as they become standard and native to most web browsers.
Post reply on HN