Live data from Hacker News

Angular 2 versus React

medium.com

181–190 of 249 posts

Re: Angular 2 versus React

#181

Earlier quoted context omitted.

But still creating domnodes on each invocation. React is shielding the dom

React still eventually creates DOM nodes eventually, so I'm not sure what you mean. How a custom element produces its DOM nodes are entirely up to it, and several approaches fit with a pure functional view of elements: 1) re-render and replace the entire component DOM, 2) Use a VDOM to patch the component DOM, 3) Use incremental-dom to update the component DOM, and yes 4) template systems like Polymer's can be easily…

I think they meant that, if you build your stateless web component, you're likely going to have to either recreate DOM elements on every tick (if you're doing something like ng-repeat) or set a bunch of attributes and whatnot... unless you set up some caching mechanism

VirtualDOM is basically that caching mechanism

Re: Angular 2 versus React

#182
post #121

I went "all in" on React a few weeks ago, but one probelm I had is the complexity of the various samples/starter kits. If anyone knows basic React and uses Typescript, and want to start using Redux/ReduxSimpleRouter, you'll find this interesting: https://news.ycombinator.com/item?id=10837377

I have something similar there as well: https://github.com/Keats/flow-typescript/tree/master/typescr...

Feel free to use any parts of my guest you find interesting :)

Re: Angular 2 versus React

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

I love mitril so much. It would be soooo much better with a lisp syntax, though.

I can't tell if you're joking.

I personally despise Lisp syntax.

Re: Angular 2 versus React

#184
post #145

Earlier quoted context omitted.

> React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what? State control. The most important thing about a React app is that you can write your code to have every bit of application state inside a single variable. It gets you hot code loading, trivial testability, and session recording/replay. I can actually test the app without having to use selenium…

>State control It took me a long time to figure that was the point and it still kind of seems you could write in good old plain javascript: x = "some state" if (you want to change it) { x = "some other state" DrawThingOneThatDependsOnx() DrawThingTwoThatDependsOnx()} Rather than spending days learning the tons of bloat, tools and tech that effectively does that for you under the hood anyway? (Plus with vanilla js run…

How do you know what things depend on X? if you have Z=Y+X, do you also refresh Z?

State control is not simple when you have many moving parts. A very good solution (which both Angular and React bring to the table without destroying performance most of the time) is to remove all the moving aspects to the parts. This doesn't matter in microbenchmarks, but in real apps, having something be slightly slower but bug-free is better than fast but wrong.

Re: Angular 2 versus React

#185
post #57

> Sigh. Yes, Angular is a framework, React is a library. Some say this difference makes comparing them illogical. Not at all! Agree. This BS "oh, it's like comparing apples to oranges" knee jerk reaction should stop. For one, even if Angular is a superset, we can always compare the parts that both have: component model, templating, etc. Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, e…

When I say React, I mean just React - I already have a large complex app with persistence, routing, legacy components with multi-year investment in development etc. - I just want to be able to add performant componentized rendering to problem areas of the app.

And that's what React is able to do, because it's a library, not a framework.

Re: Angular 2 versus React

#186

Earlier quoted context omitted.

> 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 impa…

A pure functional map is imperative?

Defining UI as a functional map of the state is the one of the most declarative ways of viewing the problem, IMO. Templates are maps too. The problem with templates, historically, is that they've been used only for the initial state, and abandoned for later changes because rerendering is expensive.

Re: Angular 2 versus React

#187

Earlier quoted context omitted.

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.

Um, that was sarcasm right? You might want to add a /s then.

Re: Angular 2 versus React

#188
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 is the year of framework fatigue. This is the year of the framework fatigue meme. Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.

another option: a lot gets pushed back to the backend rendering, where it started.

Re: Angular 2 versus React

#189
post #176

Earlier quoted context omitted.

If you want just the vdom model, look at https://github.com/Matt-Esch/virtual-dom I remember at one point mithril's vdom implementation was based on virtual-dom but I can't seem to find any documentation to back this up.

Probably a coincidence. I only found out about virtual-dom after I released Mithril.

Honestly memory is such an untrustworthy thing!
Post reply on HN