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

191–200 of 249 posts

Re: Angular 2 versus React

#191

Post by samizdatum »

Bahamut wrote: post #168
lewisl9029 wrote: post #110

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…

Code written in language that allows imperative constructs != imperative code

I would say that React is far more friendly to a declarative style than Angular 1 at least. Immutable data, redux, and virtual dom all encourage this style, whereas the path of least resistance in Angular 1 is definitely imperative mutation of state. Anyway, if you're doing significant amounts of logic in your JSX/angular templates, you're Doing It Wrong.

Re: Angular 2 versus React

#192

Post by grayrest »

tim333 wrote: post #145
grayrest wrote: post #32

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…

> vanilla js running up to 40x faster than React

That particular link is a strawman argument. React isn't magically fast. Writing a 5 line shouldComponentUpdate would normalize the performance.

If you think you can do better with something else, feel free to ignore the React hype. For my part, I've been doing frontend full time more or less exclusively since 2005 and have tried dozens of libraries/frameworks in earnest. I don't know of a better way to write client side code.

Re: Angular 2 versus React

#193

Post by eruditely »

antoaravinth wrote: post #178

If anyone is new to both frameworks Angular 2 or React; I would prefer React. I have learned React in a day. I can use my existing knowledge of js in React (for, if etc), whereas in angular learning those directives is still a pain (in Angular 2 as well). I love the fact how each component in React can be composed! Its just beauty!

What other tools do you use alongside it?

Re: Angular 2 versus React

#194

Post by grayrest »

knite wrote: post #77
grayrest wrote: post #43

Earlier quoted context omitted.

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?

I ran across [1] last week. I saw another (not ractive) a month ago but I've forgotten the name.

[1] https://github.com/Lucifier129/react-lite

Re: Angular 2 versus React

#195

Post by kenOfYugen »

rtpg wrote: post #184
tim333 wrote: post #145

Earlier quoted context omitted.

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

I like Douglas Crockford's "Class Free OOP" approach for managing dependencies and composing functions:

  function constructor(spec) {
    let {member} = spec,
    {other}  = other_constructor(spec),
    method   = function () {
          // accesses member, other, method, spec
    };

    return Object.freeze({
      method,
      other
    });
  }
but prefer to use an immutable data structure instead of Object.freeze().

All application state can be stored in a single "Atom" (i.e immutable data) and all message passing can be achieved through CSP channels.

When dealing with the DOM, 'incremental-dom' is a nice option.

Of course, separating pure functions from side-effects inducing code is key to maintaining control.

This is my approach when going "framework-less".

Re: Angular 2 versus React

#196

Post by robwormald »

plexicle wrote: post #160
robwormald wrote: post #156

Earlier quoted context omitted.

FWIW, part of the reason for Angular2's 'cringe-inducing template syntax' is so that it'll play nice with Web Components / Polymer.

Hey Rob- that was probably unfairly harsh of me. I have tried to like the syntax for the last year and I've had trouble. Anyway, I know you are a big contributer, do you mind showing me the discussion where we determined '*ngFor=' and '[(two-way)]=' was implemented to play nicely with WC? I would be interested in reading. Thanks!

seriously, not offended :) you get used to it working on frameworks :D

The longest (heated) discussion ever covers a lot of the reasoning: https://github.com/angular/angular/issues/133

More in depth design stuff here: https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG...

Demo: ng2 + google-youtube polymer element : http://plnkr.co/edit/yh0ACeu6g5n8D7YuhJvg?p=preview

Re: Angular 2 versus React

#197

Post by lewisl9029 »

Bahamut wrote: post #168
lewisl9029 wrote: post #110

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…

Unfortunately, the declarative style of programming might not be exactly what you seem to think it is. Take a look at the Wikipedia page for declarative programming: https://en.wikipedia.org/wiki/Declarative_programming

"Although pure functional languages are non-imperative, they often provide a facility for describing the effect of a function as a series of steps."

"While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs. This can be used to, for example, make a function compute its result in parallel, or to perform substantial optimizations (such as deforestation) that a compiler may not be able to safely apply to a language with side effects."

Pure functional mappings is one of the textbook examples of declarative programming. It might look like you're specifying steps to get some result in the code, but that's the wrong conceptual model. You're actually specifying the resulting data you want as a set of functional transformations on top of some initial data. Exactly how the program arrives at that resulting data from the initial data (recursion/loops/inlining/whatever else) is up to the language runtime/compiler, and not something that functional programmers needs to worry about, thus why it's declarative and not imperative.

React and Angular's approaches to templating are both declarative. React's approach simply offers more expressive power by allowing the whole set of functional transformations in the JS language rather than some artificially limited subset. React's approach also allows for this declarative approach to extend to the entire application architecture by modeling entire apps as pure functional mappings between state and UI.

UPDATE:

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

This hints to a bit of a misunderstanding of what exactly JSX is. Control flow statements are not valid JSX code precisely because JSX is a purely declarative description of UI. [1]

[1] https://facebook.github.io/react/tips/if-else-in-JSX.html

Re: Angular 2 versus React

#198

Post by legutierr »

eruditely wrote: post #193
antoaravinth wrote: post #178

If anyone is new to both frameworks Angular 2 or React; I would prefer React. I have learned React in a day. I can use my existing knowledge of js in React (for, if etc), whereas in angular learning those directives is still a pain (in Angular 2 as well). I love the fact how each component in React can be composed! Its just beauty!

What other tools do you use alongside it?

Not OP but...redux and react-router, both mentioned elsewhere in the thread, and both maintained here: https://github.com/rackt

Re: Angular 2 versus React

#199

Post by woanversace »

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…

Yes, you can do it without `polymer`. But I wanna work with it. `polymer` will give more free times to do something funny more than think about, how to expand this app, how to control all states... In my opinion, walk on BigBoy's shoulder will faster, and get wider vision

Re: Angular 2 versus React

#200

Post by dev360 »

mambodog wrote: post #103
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…

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

> under-specified, incomplete, undocumented, informal framework.

Sometimes referred to as 'micro framework' architecture in Software Development vernacular. Let the down-votes begin!!

Post reply on HN