Live data from Hacker News

React vs. Angular 2

docs.google.com

81–87 of 87 posts

Re: React vs. Angular 2

#81
post #73
post #47

Earlier quoted context omitted.

I'd suggest starting with the React docs: https://facebook.github.io/react/docs/why-react.html And once you understand React you can dive straight into the Redux docs: http://redux.js.org/index.html I found it useful to actually read the Redux docs page-by-page (at least the introduction and basics) but it also links to some tutorials. I actually had to read the basics and advanced sections several times before it fu…

what will be the "best C" then? any recommendations?

Usually some router -- typically react-router -- and a tiny bit of glue code. That's where the MVC analogy breaks down, to be honest.

Re: React vs. Angular 2

#82
post #19

Earlier quoted context omitted.

> React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. Not just that. Facebook uses it for their flagship website (and as React Native for their mobile apps). So does Instagram. So does Netflix. If you have the React developer tools installed you can literally go to facebook.com or netflix.com and…

The new Grubhub UI is built around Angular... and it shows around the edges in the types of quirkiness and bugs that show up around state/workflow. I don't fault the devs ag grubhub for this, but the types of problems I typically see around Angular are pretty typical. Personally, I really appreciate React+Redux... it seems to be the distillation of a lot of ideas. Also, good or bad, React has actually removed feature…

React killed their JSX transpiler after Babel added support for JSX. Angular merely merged AtScript into TypeScript.

React had CommonJS module support from the get go. Angular1 was incredibly awkward to use with a real module system, Angular2 is only marginally better.

Ugh.

Re: React vs. Angular 2

#83

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

React will be short-lived because of Web Components, not because of Elm. Either that, or React will evolve to be a Web Components framework. The days of proprietary component silos are numbered, IMO.

Here a discussion on React github about WebComponents: https://github.com/facebook/react/issues/5052

Re: React vs. Angular 2

#84
post #25

What is this FRP thing JS developers talking about? What I should read to learn more about it?

It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams. Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.

I don't think it's so much that it requires an interest in academia, but that it requires a shift in thinking towards abstractions that still aren't mainstream, relative to OOP (in its various forms) and unadorned events/listeners. Principally, that shift is toward higher-order functions. Yes, those same HOF abstractions are popular subjects for academic research and teaching, but they're not inherently academic subjects.

Re: React vs. Angular 2

#85
post #33
post #20

Earlier quoted context omitted.

The team I'm apart of started a project 2 months ago. We chose React and Redux over Ember, Angular, et al. A main decision factor was that we needed the server to render our initial HTML, neither Angular nor Ember can achieve this easily, we'd most likely have to lean on a third-party service. Angular looked particularly unattractive with Angular 1 being as good as dead and we didn't feel confident starting with Angu…

The problem is that the surface of Angular is incredibly complex. With React, you have components, which are just things (classes or functions) that convert a set of properties to a subtree of more components (ideally mostly ones that directly represent DOM elements) and do so deterministically and reproducibly. With Redux you just have objects ("actions") representing changes to your application state and functions…

This is a very noob question. I started with React. Its just great. While I was working on the "component" thinking, I just thought react does provides "states" concept in which we can store the component's state. Which is ( for me ) looks like React does provides the model too (what I'm thinking right now is setState as a model and render as view of React lib). Probably my thought process is wrong over here. Am I wrong here?

But if one can store the component state in React setState, why one should look for "Redux" or any Flux libs?

Re: React vs. Angular 2

#86
I am hesitant to spend time learning on react because of this:

" SomeCallMeTim: I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance. The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development. I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3] Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :) [1] https://www.pandastrike.com/posts/20150311-react-bad-idea [2] https://github.com/Matt-Esch/virtual-dom [3] https://www.nativescript.org/ "

Re: React vs. Angular 2

#87
post #25

Earlier quoted context omitted.

It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams. Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.

I don't think it's so much that it requires an interest in academia, but that it requires a shift in thinking towards abstractions that still aren't mainstream, relative to OOP (in its various forms) and unadorned events/listeners. Principally, that shift is toward higher-order functions. Yes, those same HOF abstractions are popular subjects for academic research and teaching, but they're not inherently academic subj…

True, but this paradigm shift has been pending for nearly half a century and there doesn't seem to be any progress, just periodic rediscoveries.
Post reply on HN