Angular 2 versus React
medium.com
Angular 2 versus React
1–10 of 249 posts
Re: Angular 2 versus React
#2React'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.
Re: Angular 2 versus React
#3React'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.
When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.
Re: Angular 2 versus React
#4React'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.
When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.
This is a good point, but to be fair you need to learn and implement similar solutions in an Angular-based project. You still need to implement a layering architecture that separates application/model state from view state (e.g. Flux/Redux), a module system (e.g. Webpack, Browserify), and a router (e.g. ui-router, react-router).
Re: Angular 2 versus React
#5React'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.
When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.
You get the advantage of choosing any of those libraries/tools that make up an application (e.g. choosing a router library that makes sense to you [or the team] and/or for your app). Thus, intrinsically the learning curve is much more digestible than grokking why certain parts of a monolithic framework (e.g. Angular) are designed the way they are.
Re: Angular 2 versus React
#6Earlier quoted context omitted.
When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.
This is a good point, but to be fair you need to learn and implement similar solutions in an Angular-based project. You still need to implement a layering architecture that separates application/model state from view state (e.g. Flux/Redux), a module system (e.g. Webpack, Browserify), and a router (e.g. ui-router, react-router).
All of that is included with angular and is documented quite well in angular 2 (at least with the current typescript docs)
Re: Angular 2 versus React
#7> React is a library. It’s precisely the opposite philosophy of large, comprehensive frameworks like Angular and Ember. So when you select React, you’re free to choose modern best-of-breed libraries that solve your problem best. JavaScript moves fast, and React allows you to swap out small pieces of your application for better libraries instead of waiting around and hoping your framework will innovate.
Just an aside, but who would've thought that Facebook would be the one to develop around the Unix philosophy? Yes, I know that Google is a monolith, but it became a monolith over one very specific feature and mission, whereas Facebook had to accompany many kinds of user-interaction and behavior right from conception. When Zuckerberg guest lectured CS50 (more than 10 years ago), he didn't foresee FB doing open-source:
https://youtu.be/xFFs9UgOAlE?t=17m25s
Excerpt: "There's a lot of work that goes into making stuff open source. And it's on top of whether or not you want to lose the competitive advantage...there's a lot of support and licensing and all that stuff. We found that it's been annoying"
Yes, I know FB of 10 years ago is nothing like it is today, with much different people and components...didn't React arise partly/mostly from Instagram? Either way, I was encouraged to use it early on because it was purportedly being used in Instagram production. Angular 1.x wasn't in any of the big sites (other than DoubleClick?). It's nice to see it in more of Google's sites now...but honestly, how it has currently been used has left a bad taste in my mouth. I'm thinking of the Cloud/Compute Dev console. I spun up a machine, thought I shut it off, found out I was $30 in the hole at the end of the month. No big deal, I've done that with EC2 too...but the difference is that AWS's interface, ugly as it may have been, was very easy to use to shut down a machine (right-click, Terminate). I'm ashamed to say it took me about 10 minutes to do it in the Google console. Part of it is unfamiliarity, sure...but nothing interacted the way that I, as a developer, expected it to. I finally found the button or whatever that brought up the panel to show the Terminate option -- it was on the very bottom of my widescreen monitor window...which is a huge visual gap from where the instance-icon is. Maybe it's different when you have several instances spun up and your eye is naturally drawn to the bottom...
Anyway, I know overly-enthusiastic-responsive design is not something that can be blamed inherently on a framework. But it doesn't inspire enthusiasm when it is poorly dogfooded on a developer-facing UI. I mean, it's beautiful, but in all the wrong ways, with boxes of live-updated charts showing performance/activity metrics, but in no discernable hierarchy, as if someone wrapped the page container with jquery.isotope. It's something I would show my boss to make it look like I was doing something impressive but it was not great for productivity.
In contrast...the way that React was justified in its announcement had immediate appeal. The number of UI/UX things that FB and Instagram have to constantly update because of their dataflow required React's kind of overhaul, and it was easier to trust that they would not only maintain React, but design and add features only as necessary.
Re: Angular 2 versus React
#8> You spend your time writing plain ‘ol JavaScript. That’s the future I believe in.
How about a future where you don't write any code at all? This is the beauty of Angular's markup-centric approach, it's declarative so that means less code, which means less opportunities for devs who enjoy typing to screw things up.
Jeremy Keith made a good point in his An Event Apart talk [1], where he talks about HTML slowly subsuming interactive elements (e.g. like how HTML5 adds better form type support). Angular is pushing things into this realm by helping to take code out of the picture more and more.
http://aneventapart.com/news/post/the-long-web-by-jeremy-kei...
Re: Angular 2 versus React
#9To 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 what?
Sorry, no. My 2016 isn't going to come down to me deciding between React's perverted DSL and crazy toolchain or Angular2's massive cluster$&!% of a bundle with cringe-inducing template syntax. No thanks.
I have followed this long enough. To a lot of people, adding Flux, Webpack, TypeScript, whatever, might seem like the beginning of the future of front-end development, but I see something different. I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules. This is the year of pure, well-written, and fast web apps. This is the year of framework fatigue.
Re: Angular 2 versus React
#10I 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