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

101–110 of 249 posts

Re: Angular 2 versus React

#101

Post by mercer »

fouadf wrote: post #48

What's your take on vue.js?

I quite liked Vue.js, but I really don't like how it takes the Angular approach of putting 'js in your templates' (sort of). Furthermore, while I'm holding off on 'universal apps' for now, I love being able to use React server-side. If a component needs client-side functionality (sliders, navigation etc.), it's trivial for me to create one component that renders a simple server-side version and then initializes the same component client-side with all the logic it needs.

Last I checked (about two weeks ago I think) server-side rendering was not possible yet in Vue.js.

All that said I'm quite likely to use Vue.js instead of jQuery for many of the use-cases where I would use jQuery instead of React. It's quite impressive!

Re: Angular 2 versus React

#102

Post by mambodog »

silviogutierrez wrote: post #22
novaleaf wrote: post #10

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

Does this work with the new react router that was just released? And did you try using Immutable.js ? From my understanding, it doesn't work so well with simple router.

The only reason you could have a problem using Immutable.js with redux-simple-router is if you're trying to make the router's state into an Immutable.js data structure, but there is no reason to do that. redux-simple-router manages it's own part of the state, and you don't need to directly mutate it. You only read it or dispatch an action to update it.

You don't need to make the entirety of your state tree an Immutable.js structure, just the parts which are managed by the reducers you write.

Re: Angular 2 versus React

#103

Post by mambodog »

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.

Re: Angular 2 versus React

#104

Post by dmackerman »

onetwotree wrote: post #2

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.

Yeah, the thing is you can't build a fully functioning app with just React. That's the "problem".

Re: Angular 2 versus React

#105

Post by antris »

coldtea wrote: 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…

> Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.

This premise is quite silly. Not every programmer is looking to create or adopt a framework in the beginning of a project. Some people just pick and choose libraries as they see fit and as the code evolves. I've worked on more than a few React projects and none of them use a Flux library or a routing library, simply because they were not needed.

Re: Angular 2 versus React

#106

Post by lomnakkus »

spicyj wrote: post #100
lomnakkus wrote: post #92

Earlier quoted context omitted.

Thanks for pointing this out. I (as I'm sure many others) was not even aware that such a thing existed. Having said that... - Is that the actual manifesto? I couldn't find any link to any more detailed document, but maybe it's a browser/adblock thing. - If yes, then... I agree with nearly all of it (having just skimmed it), but it seems a bit... bland and fluffy (as opposed to concrete). That's not exactly what I was…

I guess this is the real thing: https://github.com/extensibleweb/manifesto/blob/master/READM... Perhaps WebAssembly is close to what you think of as a "universal bytecode"?

That's a little closer, but AFAICT it's just a bunch of added "signatories" -- again from a skim-read.

In the long run, WebAssembly may be it. As of the promised-1.0 it's just a way/excuse to run C/C++ code on the browser's VM with some GL/Canvas mixed in there. I mean, I understand marketing a FPS-game-in-the-browser as the be-all and end-all thing, but that's not my market or end game :).

It'll be really interesting to see what happens with WebAssembly 1.1, 1.2, 2.x... Will they be the ones to surmount the insurountable obstacles?

(I've been around for quite a long time in the industry, so... having learned things and just how much the last 20% takes, I tend to temper my optimism quite a bit.)

Re: Angular 2 versus React

#107

Post by spankalee »

munro wrote: post #52
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…

Polymer is a polyfill for web components, which is an imperative way to sandbox JS/CSS/DOM. It's a very useful tool. Poylmer doesn't simplify UI development like React does, the components have to be statefully managed, and always will be because creating/destroying polymer/web components is expensive. The beauty of virtualdom is the previous state doesn't matter in deciding what the new UI should look like, or if a…

To clarify, Polymer relies on web components polyfills. The polyfills are separate and usable by any other project.

Also, components don't have to be stateful. An element can be viewed as a function invocation which accepts attributes, properties and children and returns DOM. An element which deterministically renders some DOM based only on those inputs is very much like a pure function.

Re: Angular 2 versus React

#108

Post by spankalee »

grayrest wrote: post #32
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 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…

You can manage state like that with web components as well: store state in one root object, only pass state down the tree, only build DOM based on the given state, use events to communicate changes back up the tree.

The end result is very React-like in behavior, but completely interoperable with other web components, and not require a framework at all.

Re: Angular 2 versus React

#109

Post by magicalist »

lomnakkus wrote: post #106
spicyj wrote: post #100

Earlier quoted context omitted.

I guess this is the real thing: https://github.com/extensibleweb/manifesto/blob/master/READM... Perhaps WebAssembly is close to what you think of as a "universal bytecode"?

That's a little closer, but AFAICT it's just a bunch of added "signatories" -- again from a skim-read. In the long run, WebAssembly may be it. As of the promised-1.0 it's just a way/excuse to run C/C++ code on the browser's VM with some GL/Canvas mixed in there. I mean, I understand marketing a FPS-game-in-the-browser as the be-all and end-all thing, but that's not my market or end game :). It'll be really interestin…

That is it (and there's quite a bit of thought in those bullet points), but not sure what you're looking for.

It's a manifesto for how to approach writing standards for the web, not a standard itself.

Re: Angular 2 versus React

#110

Post by lewisl9029 »

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.

Templates ultimately limit UI semantics to the subset designed into the template language. Modeling the DOM as a pure JS data structure gives you the entirety of the expressive power the JS programming language, and allows you to construct your UI as a pure declarative mapping between components/elements and your app state (the approach taken by Redux and many ClojureScript frameworks), with no imperative manipulation whatsoever.

Post reply on HN