21 ms·

Angular 2 versus React

424 points by ihsw 11y ago

onetwotree 11y ago
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.
- guftagu 11y ago
  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.
  - cjcenizal 11y ago
    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).
    - mumphster 11y ago
      All of that is included with angular and is documented quite well in angular 2 (at least with the current typescript docs)
  - albertoleal 11y ago
    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.
    - lomnakkus 11y ago
      However, that may also lead to being kind of paralyzed by the amount of choice you have. I know I'm not alone in sometimes preferring to have most of the[1] choices already made for me. (Especially when I'm not really a domain expert nor interested in trying to keep up with all the newest goings-on in the area.) [1] Ultimately probably insignificant, overall.
  - tptacek 11y ago
    You don't need Flux/Redux to use React. React without a Flux-alike is very much like Sinatra compared to Rails. If your goal is to learn React, Flux gets in the way, and you shouldn't bother. Browserify/Webpack is a giant pain and my least favorite part of this programming environment, but I'm not clear what it has to do with React. Is the concern here that React is packaged in such a way that you can't use it with a simple script inclusion, and that you must use a bundling system? Router libraries are even less essential to React than Flux. I've never used one.
    - meric 11y ago
      Webpack is used for hot reloading otherwise Gulp can suffice to provide you with a command to compress your css and jsx files. You could do it manually with the cli to begin with but I'd use a build automation tool going forward.
      - meric 11y ago
        s/compress/compile/;
  - Reedx 11y ago
    Yeah, additionally React has a serious paradox of choice problem. Which of the dozens of CSS solutions should I use? Inline styles or not? Which of the dozens of Flux libraries? Isomorphic/universal or client side? If Isomorphic, Express or Koa? Does react-router work with the choices I've made? Webpack or Browserify? It goes on and on... I love React, but the environment and best practices are unclear to say the least. Just look at how many starter kits there are and how big they tend to be: http://andrewhfarmer.com/starter-project/ http://andrewhfarmer.com/starter-project/ Can only imagine how many of the choices made are going to be deprecated in a couple months. Edit: Heh, and now that I've read the article, I see they hit on this issue. :)
    - aboutabel 11y ago
      There is also a lack of best practices, combined with constantly breaking changes. Every tutorial before the last month is already outdated, and everybody has a different way of setting up webpack / isomorphism / templating.
      - Kwastie 11y ago
        >lack of best practices How many 'best practices' do you need? What about 'higher order components'? Use proptypes in development? 'Avoid local state'? >constantly breaking changes I call bullshit, what was the last breaking change? Every large release still supports the old deprecated syntax, but with warnings. >Every tutorial before the last month is already outdated That is a big exaggeration; I wouldn't advice anyone to use 'pre es6' tutorials, but the concepts still apply. >everybody has a different way of setting up webpack / isomorphism / templating. No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.
        deboflo 11y ago
        I call bullshit on you calling bullshit on every point of this comment. > How many 'best practices' do you need? Actually, there should only be one way to do something in a framework. While not a framework, think about the Go language. Go is a very strict, almost paternal language that 'enforces' best practices in the language itself by giving you only one way to do something. Angular, on the other hand, provides numerous ways to create a service. Because of this confusion, the Angular team provides best practices. It's like saying, 'we screwed up in designing this thing, so you have to read all the documentation to find out the subtle differences in all this bullshit.' It's not the lack of best practices that concerns me, it's the abundance of them that gets shipped with a bloated framework that wasn't designed well. >Every large release?I seriously doubt it. Think of all the pain involved in removing all of the digest cycle code when switching from Angular 1.4 to Angular 2.0. > No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular. Seriously? There are no small differences between Django templates, Soy templates (client and server side), and Angular templates to name a few. They are all very different yet they do essentially the same thing. At least Soy templates can be used outside of a framework (with either JS or Java).
- kcorbitt 11y ago
  I've briefly used Angular 1 a few years ago, and have been involved in the React ecosystem for the last two years. I really like React, it gets a lot of things right and I think it has a bright future. But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. As soon as you get past a "hello world" Todo app, even trying to figure out what questions to ask to get to a scaleable app design can be tough. There are good, stable solutions to most common problems like state management (Redux) and routing (React Router), as well as a ton of other goodies like server-side rendering and hot module reloading available, but if you don't know what you're looking for you're in for a lot of contradictory and sometimes outdated advice about what tools to use for what, and the best way to wire all of them up. That said, this is an issue that the community is acutely aware of (there's been a lot of chatter on Twitter about it recently, although there's definitely still more questions than answers) and one that I think will get better with time.
  - zeppelin 11y ago
    > But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. Totally agree. Doing anything large-scale is hard, and comes with a massive learning curve. No React or Angular can save you from learning what it means to go from "hello world" to working on a project with a team of, say, 10 people.
- EvanPlaice 11y ago
  If you're just building components, the learning curve for Angular2 is no different. All in all, it takes about 20 lines of code to define a simple web component. If you're using either Angular2 or React for anything beyond trivial examples (ex, routing, AJAX, lazy loading, isomorphic rendering, etc), things become more complex.
- EugeneOZ 11y ago
  Do you count time for learning all third-party libraries needed to create an app with React?
- dmackerman 11y ago
  Yeah, the thing is you can't build a fully functioning app with just React. That's the "problem".
- ryanSrich 11y ago
  I had the complete opposite reaction. I learned a bit of React through a rails + react tutorial and I was lost pretty much the entire time. Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare. Granted the testing options of both beat out angular, but even at a surface level React just wasn't appealing.
  - freyr 11y ago
    > Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare. Can you expand on this? I find writing JSX to be a breeze. JSX is basically HTML with a few small tweaks (e.g., for => htmlFor, class => className). If you use a linter, it will catch those mistakes for you while you're learning.
  - dev360 11y ago
    I think that in order to start seeing the appeal, you have to have seen the alternative. Before angular, I was writing a lot of backbone apps, and generally, they were well organized and easy to maintain. With angular, I've found that my apps have devolved into a huge tag soup very quickly. It didn't take me long to realize that the templating syntax was a huge part of what made angular suck really bad, and its like the article says: "Angular 2 continues to put 'JS' into HTML." So to me, JSX is at the core of what makes React feel manageable, since I can use OO and encapsulation techniques of javascript to deal with complex rendering and still keep my code organized and easy to follow. The more I think about it, angular reminds me a lot of Coldfusion in its approach.
    - ry_ry 11y ago
      I used backbone a lot too, and despite their obvious differences, react feels like backbone's spiritual successor in terms of being 'Just Javascript' that solved problems, rather than a fullblown framework. For the longest time I totally saw react as replacing backbone views, but in practice that was unwieldy and the stateful, unidirectional approaches (Jesus that needs a catchy acronym!) made more sense given what I was trying to achive.
danso 11y ago
> 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 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.
jlas 11y ago
> 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-keith-an-event-apart-video http://aneventapart.com/news/post/the-long-web-by-jeremy-kei...
- jerf 11y ago
  If you're writing loops, and especially if you write loops that have conditionals inside of them, you're writing code. "Declarative" is saying "I want a list of all users", "For every user, display their name like this" is just code. I've seen a lot of template languages that claim to be declarative, I'm yet to see a production template (that is to say, not an "example") that actually looks declarative and isn't just writing code in a language with poor constructs for writing code.
  - mercer 11y ago
    Agreed. In every single project I've worked on that used mustache/handlebars, haml, or some similar 'restricted logic' approach, the long-term result consisted of view templates that contained hacks, a lot of logic hidden in helpers that were often only used in one place, or just plain convoluted solutions. Furthermore, the main argument I hear is that these logic-less template approaches benefit designers/front-enders, which doesn't make sense to me. If your project is complex enough to require Angular or React, a non-coder front-ender probably will have trouble working on it anyways. That's been my experience at least.
- jdlshore 11y ago
  I've seen no evidence that Angular results in less code than React. My experience with Angualar 1 was the opposite. Angular templates are still code... weird, fiddly, silently-failing code, at least for Angular 1.
plexicle 11y ago
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 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.
- lucidrains 11y ago
  Is there any substantial apps written in Polymer yet?
  - sehr 11y ago
    https://gaming.youtube.com https://gaming.youtube.com is probably one of the bigger ones, but of course it doesn't support mobile so you can only check it out on desktop.
  - plexicle 11y ago
    That's exactly the wrong question. The right question is: "are there any substantial apps that take advantage of native Web Components (polyfill or not)?" The answer to that is: "yes, a lot." Polymer is just one way to write the components. X-Tag is another. Pure JavaScript is another. Use one of them or use them all. No big overarching framework required.
    - elsigh 11y ago
      But it's not just about writing individual components when you build an app (you need something like a router still for instance). I say this as someone who rather likes the model Web Components espouses. Developer ecosystems matter a lot - for development, debugging and hiring. At present you have a great many more resources/communities to reach out if you go with React. When you get stuck with Web Components or polymer, and you will get stuck, you are a lot more on your own. Also, for building you are, at least presently afaik, limited to vulcanize instead of the richer set of tools out there for more typical patterns. Vulcanize is cool, but again - if you get stuck, and you will if you do something complex - you have to rely on a much smaller community to help you out.
novaleaf 11y ago
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 https://news.ycombinator.com/item?id=10837377
- silviogutierrez 11y ago
  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.
  - deleted 11y ago
    [deleted]
    - silviogutierrez 11y ago
      Huh? Immutable.js is written in Typescript, and it's advocated by Redux, so I figured it's a natural fit in the React ecosystem. At least ideologically. Actually wiring it up sounds difficult.
  - novaleaf 11y ago
    i tried Immutable, but it adds lots of tangential stuff, way too much for a React/Redux beginner (like me). and, using react-router from a couple weeks ago, so this is using the "old" 1.x version.
  - mambodog 11y ago
    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.
jerf 11y ago
Or, much shorter, Angular is creating an inner platform [1], and React is extending the platform that already exists to do more work. [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
PaybackTony 11y ago
This is continuing to shape up to be another one of those preference debates. I prefer the Angular approach, as its end goal is to simply make web markup what it should be: Interactive. The downside being that you're forced into Angular's opinions for better or worse. I don't prefer the more "tangled" approach of React. I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTML. Many people like the approach, and I can see why they do. I don't. Those are preferences. So much more goes into making an app efficient, testable and expandable. The biggest ingredient is comfort. If you and your dev team are comfortable with React, that's going to be your best option. It's not the wrong option, it's a great option. For me, it's Angular. However, I feel compelled to say that the debate should be Angular 2 v React. Having used others (... Ember....) it just doesn't make much sense to use anything outside these main 2 contenders unless you're using some of the new "cool" web components based stuff. Angular is solid. React is solid. Compare, contrast and make your decision based on how comfortable you feel with the getting started docs.
- vdnkh 11y ago
  > I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTML. Doesn't Angular mix HTML and JS too, except in the HTML file?
  - paulddraper 11y ago
    Yeah. The only difference is that React lends itself to arbitrary JS, while Angular is more limited.
  - EvanPlaice 11y ago
    > Doesn't Angular mix HTML and JS too, except in the HTML file? Angular2 doesn't. Like React it uses a HTML-like templating syntax to generate views. Nothing is mixed in Angular2, everything is defined in JS and rendered as HTML.
- jameslk 11y ago
  I've used Angular, React, and Handlebars (Ember's templating engine), and I can tell you, they are all the same in "tangling." They all solve this problem by emphasizing that the view portion of the code (Angular's pseudo-HTML, React's JSX, and Handlebar's limited helpers) should be used strictly for view-related logic, not domain/business logic. So there really isn't any difference between the libraries in that respect, except for personal taste.
fouadf 11y ago
What's your take on vue.js?
- overcast 11y ago
  I've used it for three projects so far, and I'm in love. The syntax is so clean, super easy to learn, and quick to get going. Bind to a parent element, add your data vars, methods, and add your data bindings. Done. It's certainly not as heavyweight as Angular, and that's a good thing. I played with the other big frameworks, and they were so complex for even the basics. I get 99.9% of the work done that I need to with it and should be at the top of these framework lists.
- ausjke 11y ago
  indeed it seems vue.js is the best way out.
- mercer 11y ago
  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!
- dimgl 11y ago
  I find Vue.js to be so refreshing that it's a shame everyone is so obsessed with Angular.js and React. For me it has been the best of the bunch.
- mosquito242 11y ago
  Huge fan of Vue.js. Clean, lightweight, very easy to learn, use and build powerful functionality with.
Bahamut 11y ago
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/angular.min.js https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a... (all numbers I remember seeing for angular 1 were around 120 KB IIRC). I'd suspect all the other numbers are off too, but I haven't investigated. There is a strong argument against doing what JSX does in moving the HTML to JS - you allow developers to fall into the trap of creating complex conditional DOM that is hard to read without a disciplined team (if statements all over the place with imperative DOM construction for example). Neither approach of JSX or Angular's templating (or any other similar system to either) are without its warts, and this falls into an opinion discussion without real winners excepting for however a particular team prefers their templating. One thing that wasn't discussed but that may come into play - the performance numbers out there for Angular 2 currently is extremely impressive. Optimized Angular 2 code is generally performing at about 2x the rate of other frameworks/libraries out there for UI rendering/repainting, and unoptimized Angular 2 code is performing at roughly the same parity as optimized React code (although optimized/unoptimized React code performs very similarly in many situations, which is a huge benefit of React). 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. Both are impressive libraries though, and both have strong merits - at the end of the day, it comes down to how your team works, and what they're productive with. Both libraries are bringing excellent changes to how we do things in the frontend...I just wish tooling was there in maturity, that seems to be the greater pain point currently.
- bryanlarsen 11y ago
  It's pretty easy to write "complex conditional DOM that is hard to read" in both React & Angular. But in my experience, I encounter it a lot more in Angular code bases than React code bases.
  - Bahamut 11y ago
coldtea 11y ago
>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, etc. -- so all the same things you get with Angular, just cherry picked. Third, we can just as well compare Angular (or any framework) with building something from scratch with vanilla JS too. Nobody said we have to compare them "as frameworks". We can compare them as different "ways get a web app done" (with/without framework, without framework but with x lib, etc). Fourth, we can always compare apple's to oranges. Here's a comparison: oranges have more vitamin C than apples, and are better for scurvy (haven't checked the actual vitamin C stats, but you get my point).
- ebola1717 11y ago
  Can you use Angular's components & templating outside of the rest of its MVC architecture? Despite the insistence on HN that React = React + Router + Flux, I've been using just React with plain js objects for models, and I like it exactly because it's an easier way of writing simple interactive views.
  - zeppelin 11y ago
    What if it can't? (I don't develop apps using Angular, so I really don't know the answer...) Then it's just a con for Angular, but also a pro for providing a default MVC architecture to rely on. It's a design choice that can be both good and bad.
- antris 11y ago
  > 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.
EvanPlaice 11y ago
tl;dr: The author is asserting that React > Angular2 because he's already emotionally invested in the former. React's greatest strength is also its greatest weakness. It requires devs to compose their app out of multiple de-centralized parts. See 'javascript fatigue'. If your aim is to write an isomorphic React app, you CAN"T just use 'plain old javascript' or anything that touches the DOM. If you care about SEO, this is a very important implementation detail to consider. Angular2's greatest strength is also its greatest weakness. It provides a unified API for building apps. It forces you to do things the 'angular way' which is no different from Angular1. So far Angular2 is heavily biased toward Typescript because it was written in TS and it was literally just released to beta 2 weeks ago. TS is good for devs bridging over from strongly-typed OOP languages, and TS provides better support for autocomplete in IDEs. TS is bad because it's not an 'official' standard and it may be an awkward transition for existing JS devs. TS is not required, I have been writing an Angular2 app in strictly ES6 despite the lack of documentation/support. Both: require transpilation; use observables (ie redux vs rxjs); use a HTML-like templating language for data binding; use the virtual DOM to speed up rendering; discourage mutating the DOM directly to encourage rendering on other platforms (ie mobile, isomorphic); require platform-specific shims that don't touch the DOM; etc... The underlying technologies of both are more similar than different. React favors a more decentralized architecture. Angular2 favors a more monolithic architecture. /axegrinding
- dev360 11y ago
  My understanding is that the SEO argument is becoming moot. With emphasis on the word 'generally': "We are generally able to render and understand your web pages like modern browsers." https://googlewebmastercentral.blogspot.se/2015/10/deprecating-our-ajax-crawling-scheme.html https://googlewebmastercentral.blogspot.se/2015/10/deprecati...
JStanton617 11y ago
React has a non-open license: https://github.com/facebook/react/blob/master/PATENTS https://github.com/facebook/react/blob/master/PATENTS, which basically says that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This is an automatic no-way for React for any major company
- JoshMnem 11y ago
  Yes... I'm really surprised that people aren't talking about this more seriously. They have removed the worst of it, but it still looks like it gives Facebook an advantage in any patent conflicts with any company that uses React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It appears that the PATENTS file claims that if Facebook infringes on your patents, you can't defend your patents without a risk of immediately losing the ability to use React (or other Facebook library). Maybe a lawyer would be able to make more sense of that PATENTS file. I'm surprised that Apple might be using React, since they have had big patent battles with Facebook: http://www.meetup.com/ReactJS-San-Francisco/events/227071839/ http://www.meetup.com/ReactJS-San-Francisco/events/227071839... http://www.theguardian.com/technology/2015/jul/21/facebook-google-dell-hp-ebay-samsung-apple http://www.theguardian.com/technology/2015/jul/21/facebook-g... I've heard that Google doesn't use React, but I don't know how long companies will be able to do that as Facebook libraries increasingly become dependencies of other libraries.
  - spicyj 11y ago
    Google does use React now; as far as I know they are happy with the current version of the PATENTS file.
    - etjossem 11y ago
      Citation? Which projects use it?
    - JoshMnem 11y ago
      The last I heard, they weren't allowed to use it. If you could link to a Google product that uses React, I'd like to take a look.
craigvn 11y ago
"Angular 2 continues to put “JS” into HTML. React puts “HTML” into JS." It seems fairly obvious to me that both approaches are wrong.
- iLoch 11y ago
  Have you tried either? What is your concern with mixing the two? JSX is optional, by the way. I have a problem with JS into HTML because that's pseudo-coding. JSX tags are representations of classes and class instances, which makes a lot more sense than a totally new DSL for scripting.
- housecor 11y ago
  Do you have an alternative approach to propose?
bhanu423 11y ago
I found smaller frameworks like riot.js easier to reason around and light on almost all use-cases.
rmanolis 11y ago
I prefer angular over react. 1) It is opinionated (wasting time for decisions is bad) 2) It is simpler to organize the code (it is MVC) 3) (click)="onSelect()" is simpler. You dont have to create an object with "bind" function like in react. 4) I dont want web designers mess with my code. So putting html on JS is bad decision.
- mercer 11y ago
  But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways. I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...
  - eseehausen 11y ago
    I don't have a horse in this race, but do you think that learning JSX is going to be any easier for non-coders?
    - iLoch 11y ago
      Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable. To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using. I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.
EugeneOZ 11y ago
"Yes I'm biased" was tl;dr actually. Or "I love JSX so much I can't even think about frameworks without JSX".
dimgl 11y ago
Oh my Christ, not this again. The framework fatigue is real. Why are people trying to push Angular 2 or React even? The former is still under heavy development and the latter is such a painful pill to swallow.
pdeva1 11y ago
Its the Angular 2 router that currently needs a lot more work. Currently things like passing data down to child routes [1], getting current route segments[2], checking active route etc are still not easily possible[3]. imho router is a big part of any large app and getting the details right is essential there. 1. https://github.com/angular/angular/issues/5330 https://github.com/angular/angular/issues/5330 2. https://github.com/angular/angular/issues/6260 https://github.com/angular/angular/issues/6260 3. http://stackoverflow.com/questions/34571517/angular-2-how-to-determine-active-route-with-parameters http://stackoverflow.com/questions/34571517/angular-2-how-to...
sayem_ 11y ago
IMO the standout difference between Angular and React is how you think about your application. Do you like functional programming paradigms and want to apply them in writing your components? Use React. Do you think immutability is too restrictive and love things like two-way binding? Use Angular. That being said, I'm a bit disappointed to see no mention of Aurelia although the author has mentioned other frameworks like Emberjs. I have been writing production code with Aurelia for about a month and this has been so far my best experience with any client side javascript framework. ES6 is very capable and Aurelia did it right by staying out of your way for most of the times by letting you write your components in plain ES6. All the while providing binding capability(with beautiful syntax), a very powerful router and out of the box package management support. I feel with all the commotion in framework space, more people will appreciate the simplicity of Aurelia and that camp will get bigger as time goes by.
- dev360 11y ago
  > Do you like functional programming paradigms and want to apply them in writing your components? Use React. s/React/Elm/g
scotchoverwine 11y ago
As a new web developer, where do you draw the line between a web application rendered server side and a SPA? I'm trying to develop a web app for creating invoices for a niche market but in this case I don't see huge advantages for a SPA over rendering HTML server side, the added complexity of a SPA doesn't have that big of a reward, I still plan to separate the frontend and backend, for example, writing a HTTP API that outputs json and in another process(or server) consume the json and render HTML in the frontend server (and maybe add some JS to improve interactivity). But everything this days seems about creating SPAs for new apps and that's definitely the future it seems, I'm wrong following this route or is that I'm just consuming to much SPA hype?
- mercer 11y ago
  Perhaps in the future there will be a time where an 'old-fashioned' server-side app is a bad idea, but right now I think it's still a perfectly valid approach, and even preferable in some cases. Consider whether your app will actually benefit from being an SPA. Does it negatively impact the user experience to have page refreshes? Or does it provide significant benefits to do things client side? If the answer is 'no', you might as well take what is currently still easier and more standardized, and go for server-side. But the next step is to ask these questions about parts of your app. In those cases using React or Vue or something similar for just those parts might be a good idea. And if you've already separated front- and back-end, it shouldn't be too difficult to realize (and it's a good reason to use React server-side even if that's all you use it for initially!).
- ohnomrbill 11y ago
  I've found that it makes sense to outline what actions it is convenient to view on screen at any given time, and group those things into an app (here, one JS file that is served along with some HTML by the server). So my typical applications have a handful of traditional routes serving HTML and a few small single page apps. To the extent that functionality is shared, I'll create a Clojurescript or Javascript library and reuse it. It keeps JS files small and quick to serve. I've found it to be a good balance between server-side rendering and having a massive SPA.
spectrum1234 11y ago
It seems like Redux + React is clearly going to win out. What am I missing? Yes the ecosystem is constantly changing right now but the oscillations are getting smaller not bigger. In my opinion Redux is the highest level and most intuitive, just like React was for the view when it came out. It's only a matter of time.
- marknutter 11y ago
  Why does Redux imply React? I use Redux with virtual-dom and end up with far less bloat.
  - spectrum1234 11y ago
    Interesting. Didn't know about that
Negative1 11y ago
His argument about the 'Unix Philosophy' reminds me a lot of the argument between using big web frameworks like Django vs smaller micro-frameworks like Flask. Personally, I prefer Flask for the small projects I make because of how nimble it is but it's hard to argue with the large organizations using Django for massive projects to (seemingly) good effect. Ironic since I actually do like Angular (sorry)! Overall I felt the article was preachy and extremely biased. It's as if the author was trying really hard to convince as opposed to just presenting the facts and letting the reader make a choice based on the evidence. I have concerns about ng2 but having made an effort to learn React as well I think he dramatically oversimplifies it's ease of use for large scale projects (where Angular shines, IMHO).
antoaravinth 11y ago
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!
- eruditely 11y ago
  What other tools do you use alongside it?
  - legutierr 11y ago
    Not OP but...redux and react-router, both mentioned elsewhere in the thread, and both maintained here: https://github.com/rackt https://github.com/rackt
  - antoaravinth 11y ago
    I used react-redux combo. Thats it. They both themselves are good enough for my project to get started.
pinchn 11y ago
Angular is HTML-centric whereas React is JavaScript-centric. Succint!
DonHopkins 11y ago
The foolish, totally avoidable, misguided and completely pointless mistake that Angular 2 made was using a template syntax that was almost but not quite completely unlike HTML: <ul> <li *ngFor="#hero of heroes"> {{hero.name}} </li> </ul> or: <web-component [title]="exp1" (close)="exp2()"> That is INVALID html and INVALID xml. That means you can't edit or process or generate or validate Angular templates with any of the millions of existing HTML and XML processing tools. They have completely forsaken the entire universe of existing tools, for no good reason. The Angular 2 template language gets absolutely zero benefits from arbitrarily disobeying HTML syntax. There's nothing about the broken syntax that makes it any more powerful or tangibly convenient that could be done by an HTML or XML compatible syntax. Maybe it appeals to Perl brogrammers, but the hip stylish syntactic appeal of peppering templates with unique special snowflakes of punctuation like they were so many christmas tree decorations does not outweigh the dire consequence that you can't use an off-the-shelf HTML editor to edit and preview templates, or use any of the many other existing HTML tools to do whatever they're designed to do. I've encountered Angular 2 proponents who were such blind zealots that they actually refused to see any benefits of sticking to standard syntax and enabling the use of existing tools. They would ask things like "why would you ever want to edit an Angular 2 template in an HTML editor?" or "why would you ever want to generate a template from another meta-template?" or "why wouldn't you want to write your own Angular 2 template validators and editors and processors?" or "why wouldn't you want to retrain all of your html designers who can't use the tools and syntax they're accustom to?" Yet they were still unable to name any tangible benefits of the broken Angular 2 template syntax, that couldn't be achieved with a non-incompatible HTML syntax. I'm afraid that they next thing they'll do is invent their own incompatible version of Unicode.
franciscop 11y ago
From someone with years of experience with javascript, how is this "plain 'ol javascript"? <ul> { heroes.map(hero => <li key={hero.id}>{hero.name}</li> )} </ul>
- insin 11y ago
  It clearly isn't, but it starts to feel like it once you get used to JSX syntax as sugar for nested function calls with attribute object arguments.
ry_ry 11y ago
More importantly, when is the Flux Influenced, Stateful Template Enterprise React methodology gonna get a catchy acronymn? Asterisk-ux isn't cutting it, and god knows we need a buzzword.

424 points by ihsw 11y ago

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.

guftagu 11y ago
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.
- cjcenizal 11y ago
  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).
  - mumphster 11y ago
    All of that is included with angular and is documented quite well in angular 2 (at least with the current typescript docs)
- albertoleal 11y ago
  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.
  - lomnakkus 11y ago
    However, that may also lead to being kind of paralyzed by the amount of choice you have. I know I'm not alone in sometimes preferring to have most of the[1] choices already made for me. (Especially when I'm not really a domain expert nor interested in trying to keep up with all the newest goings-on in the area.) [1] Ultimately probably insignificant, overall.
- tptacek 11y ago
  You don't need Flux/Redux to use React. React without a Flux-alike is very much like Sinatra compared to Rails. If your goal is to learn React, Flux gets in the way, and you shouldn't bother. Browserify/Webpack is a giant pain and my least favorite part of this programming environment, but I'm not clear what it has to do with React. Is the concern here that React is packaged in such a way that you can't use it with a simple script inclusion, and that you must use a bundling system? Router libraries are even less essential to React than Flux. I've never used one.
  - meric 11y ago
    Webpack is used for hot reloading otherwise Gulp can suffice to provide you with a command to compress your css and jsx files. You could do it manually with the cli to begin with but I'd use a build automation tool going forward.
    - meric 11y ago
      s/compress/compile/;
- Reedx 11y ago
  Yeah, additionally React has a serious paradox of choice problem. Which of the dozens of CSS solutions should I use? Inline styles or not? Which of the dozens of Flux libraries? Isomorphic/universal or client side? If Isomorphic, Express or Koa? Does react-router work with the choices I've made? Webpack or Browserify? It goes on and on... I love React, but the environment and best practices are unclear to say the least. Just look at how many starter kits there are and how big they tend to be: http://andrewhfarmer.com/starter-project/ http://andrewhfarmer.com/starter-project/ Can only imagine how many of the choices made are going to be deprecated in a couple months. Edit: Heh, and now that I've read the article, I see they hit on this issue. :)
  - aboutabel 11y ago
    There is also a lack of best practices, combined with constantly breaking changes. Every tutorial before the last month is already outdated, and everybody has a different way of setting up webpack / isomorphism / templating.
    - Kwastie 11y ago
      >lack of best practices How many 'best practices' do you need? What about 'higher order components'? Use proptypes in development? 'Avoid local state'? >constantly breaking changes I call bullshit, what was the last breaking change? Every large release still supports the old deprecated syntax, but with warnings. >Every tutorial before the last month is already outdated That is a big exaggeration; I wouldn't advice anyone to use 'pre es6' tutorials, but the concepts still apply. >everybody has a different way of setting up webpack / isomorphism / templating. No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.
      - deboflo 11y ago
        I call bullshit on you calling bullshit on every point of this comment. > How many 'best practices' do you need? Actually, there should only be one way to do something in a framework. While not a framework, think about the Go language. Go is a very strict, almost paternal language that 'enforces' best practices in the language itself by giving you only one way to do something. Angular, on the other hand, provides numerous ways to create a service. Because of this confusion, the Angular team provides best practices. It's like saying, 'we screwed up in designing this thing, so you have to read all the documentation to find out the subtle differences in all this bullshit.' It's not the lack of best practices that concerns me, it's the abundance of them that gets shipped with a bloated framework that wasn't designed well. >Every large release?I seriously doubt it. Think of all the pain involved in removing all of the digest cycle code when switching from Angular 1.4 to Angular 2.0. > No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular. Seriously? There are no small differences between Django templates, Soy templates (client and server side), and Angular templates to name a few. They are all very different yet they do essentially the same thing. At least Soy templates can be used outside of a framework (with either JS or Java).
kcorbitt 11y ago
I've briefly used Angular 1 a few years ago, and have been involved in the React ecosystem for the last two years. I really like React, it gets a lot of things right and I think it has a bright future. But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. As soon as you get past a "hello world" Todo app, even trying to figure out what questions to ask to get to a scaleable app design can be tough. There are good, stable solutions to most common problems like state management (Redux) and routing (React Router), as well as a ton of other goodies like server-side rendering and hot module reloading available, but if you don't know what you're looking for you're in for a lot of contradictory and sometimes outdated advice about what tools to use for what, and the best way to wire all of them up. That said, this is an issue that the community is acutely aware of (there's been a lot of chatter on Twitter about it recently, although there's definitely still more questions than answers) and one that I think will get better with time.
- zeppelin 11y ago
  > But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. Totally agree. Doing anything large-scale is hard, and comes with a massive learning curve. No React or Angular can save you from learning what it means to go from "hello world" to working on a project with a team of, say, 10 people.
EvanPlaice 11y ago
If you're just building components, the learning curve for Angular2 is no different. All in all, it takes about 20 lines of code to define a simple web component. If you're using either Angular2 or React for anything beyond trivial examples (ex, routing, AJAX, lazy loading, isomorphic rendering, etc), things become more complex.
EugeneOZ 11y ago
Do you count time for learning all third-party libraries needed to create an app with React?
dmackerman 11y ago
Yeah, the thing is you can't build a fully functioning app with just React. That's the "problem".
ryanSrich 11y ago
I had the complete opposite reaction. I learned a bit of React through a rails + react tutorial and I was lost pretty much the entire time. Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare. Granted the testing options of both beat out angular, but even at a surface level React just wasn't appealing.
- freyr 11y ago
  > Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare. Can you expand on this? I find writing JSX to be a breeze. JSX is basically HTML with a few small tweaks (e.g., for => htmlFor, class => className). If you use a linter, it will catch those mistakes for you while you're learning.
- dev360 11y ago
  I think that in order to start seeing the appeal, you have to have seen the alternative. Before angular, I was writing a lot of backbone apps, and generally, they were well organized and easy to maintain. With angular, I've found that my apps have devolved into a huge tag soup very quickly. It didn't take me long to realize that the templating syntax was a huge part of what made angular suck really bad, and its like the article says: "Angular 2 continues to put 'JS' into HTML." So to me, JSX is at the core of what makes React feel manageable, since I can use OO and encapsulation techniques of javascript to deal with complex rendering and still keep my code organized and easy to follow. The more I think about it, angular reminds me a lot of Coldfusion in its approach.
  - ry_ry 11y ago
    I used backbone a lot too, and despite their obvious differences, react feels like backbone's spiritual successor in terms of being 'Just Javascript' that solved problems, rather than a fullblown framework. For the longest time I totally saw react as replacing backbone views, but in practice that was unwieldy and the stateful, unidirectional approaches (Jesus that needs a catchy acronym!) made more sense given what I was trying to achive.

danso 11y ago

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

jlas 11y ago

> 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-keith-an-event-apart-video http://aneventapart.com/news/post/the-long-web-by-jeremy-kei...

jerf 11y ago
If you're writing loops, and especially if you write loops that have conditionals inside of them, you're writing code. "Declarative" is saying "I want a list of all users", "For every user, display their name like this" is just code. I've seen a lot of template languages that claim to be declarative, I'm yet to see a production template (that is to say, not an "example") that actually looks declarative and isn't just writing code in a language with poor constructs for writing code.
- mercer 11y ago
  Agreed. In every single project I've worked on that used mustache/handlebars, haml, or some similar 'restricted logic' approach, the long-term result consisted of view templates that contained hacks, a lot of logic hidden in helpers that were often only used in one place, or just plain convoluted solutions. Furthermore, the main argument I hear is that these logic-less template approaches benefit designers/front-enders, which doesn't make sense to me. If your project is complex enough to require Angular or React, a non-coder front-ender probably will have trouble working on it anyways. That's been my experience at least.
jdlshore 11y ago
I've seen no evidence that Angular results in less code than React. My experience with Angualar 1 was the opposite. Angular templates are still code... weird, fiddly, silently-failing code, at least for Angular 1.

plexicle 11y ago

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

lucidrains 11y ago
Is there any substantial apps written in Polymer yet?
- sehr 11y ago
  https://gaming.youtube.com https://gaming.youtube.com is probably one of the bigger ones, but of course it doesn't support mobile so you can only check it out on desktop.
- plexicle 11y ago
  That's exactly the wrong question. The right question is: "are there any substantial apps that take advantage of native Web Components (polyfill or not)?" The answer to that is: "yes, a lot." Polymer is just one way to write the components. X-Tag is another. Pure JavaScript is another. Use one of them or use them all. No big overarching framework required.
  - elsigh 11y ago
    But it's not just about writing individual components when you build an app (you need something like a router still for instance). I say this as someone who rather likes the model Web Components espouses. Developer ecosystems matter a lot - for development, debugging and hiring. At present you have a great many more resources/communities to reach out if you go with React. When you get stuck with Web Components or polymer, and you will get stuck, you are a lot more on your own. Also, for building you are, at least presently afaik, limited to vulcanize instead of the richer set of tools out there for more typical patterns. Vulcanize is cool, but again - if you get stuck, and you will if you do something complex - you have to rely on a much smaller community to help you out.

novaleaf 11y ago

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 https://news.ycombinator.com/item?id=10837377

silviogutierrez 11y ago
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.
- deleted 11y ago
  [deleted]
  - silviogutierrez 11y ago
    Huh? Immutable.js is written in Typescript, and it's advocated by Redux, so I figured it's a natural fit in the React ecosystem. At least ideologically. Actually wiring it up sounds difficult.
- novaleaf 11y ago
  i tried Immutable, but it adds lots of tangential stuff, way too much for a React/Redux beginner (like me). and, using react-router from a couple weeks ago, so this is using the "old" 1.x version.
- mambodog 11y ago
  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.

jerf 11y ago

Or, much shorter, Angular is creating an inner platform [1], and React is extending the platform that already exists to do more work. [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

PaybackTony 11y ago

This is continuing to shape up to be another one of those preference debates. I prefer the Angular approach, as its end goal is to simply make web markup what it should be: Interactive. The downside being that you're forced into Angular's opinions for better or worse. I don't prefer the more "tangled" approach of React. I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTML. Many people like the approach, and I can see why they do. I don't. Those are preferences. So much more goes into making an app efficient, testable and expandable. The biggest ingredient is comfort. If you and your dev team are comfortable with React, that's going to be your best option. It's not the wrong option, it's a great option. For me, it's Angular. However, I feel compelled to say that the debate should be Angular 2 v React. Having used others (... Ember....) it just doesn't make much sense to use anything outside these main 2 contenders unless you're using some of the new "cool" web components based stuff. Angular is solid. React is solid. Compare, contrast and make your decision based on how comfortable you feel with the getting started docs.

vdnkh 11y ago
> I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTML. Doesn't Angular mix HTML and JS too, except in the HTML file?
- paulddraper 11y ago
  Yeah. The only difference is that React lends itself to arbitrary JS, while Angular is more limited.
- EvanPlaice 11y ago
  > Doesn't Angular mix HTML and JS too, except in the HTML file? Angular2 doesn't. Like React it uses a HTML-like templating syntax to generate views. Nothing is mixed in Angular2, everything is defined in JS and rendered as HTML.
jameslk 11y ago
I've used Angular, React, and Handlebars (Ember's templating engine), and I can tell you, they are all the same in "tangling." They all solve this problem by emphasizing that the view portion of the code (Angular's pseudo-HTML, React's JSX, and Handlebar's limited helpers) should be used strictly for view-related logic, not domain/business logic. So there really isn't any difference between the libraries in that respect, except for personal taste.

fouadf 11y ago

What's your take on vue.js?

overcast 11y ago
I've used it for three projects so far, and I'm in love. The syntax is so clean, super easy to learn, and quick to get going. Bind to a parent element, add your data vars, methods, and add your data bindings. Done. It's certainly not as heavyweight as Angular, and that's a good thing. I played with the other big frameworks, and they were so complex for even the basics. I get 99.9% of the work done that I need to with it and should be at the top of these framework lists.
ausjke 11y ago
indeed it seems vue.js is the best way out.
mercer 11y ago
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!
dimgl 11y ago
I find Vue.js to be so refreshing that it's a shame everyone is so obsessed with Angular.js and React. For me it has been the best of the bunch.
mosquito242 11y ago
Huge fan of Vue.js. Clean, lightweight, very easy to learn, use and build powerful functionality with.

Bahamut 11y ago

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/angular.min.js https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a... (all numbers I remember seeing for angular 1 were around 120 KB IIRC). I'd suspect all the other numbers are off too, but I haven't investigated. There is a strong argument against doing what JSX does in moving the HTML to JS - you allow developers to fall into the trap of creating complex conditional DOM that is hard to read without a disciplined team (if statements all over the place with imperative DOM construction for example). Neither approach of JSX or Angular's templating (or any other similar system to either) are without its warts, and this falls into an opinion discussion without real winners excepting for however a particular team prefers their templating. One thing that wasn't discussed but that may come into play - the performance numbers out there for Angular 2 currently is extremely impressive. Optimized Angular 2 code is generally performing at about 2x the rate of other frameworks/libraries out there for UI rendering/repainting, and unoptimized Angular 2 code is performing at roughly the same parity as optimized React code (although optimized/unoptimized React code performs very similarly in many situations, which is a huge benefit of React). 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. Both are impressive libraries though, and both have strong merits - at the end of the day, it comes down to how your team works, and what they're productive with. Both libraries are bringing excellent changes to how we do things in the frontend...I just wish tooling was there in maturity, that seems to be the greater pain point currently.

bryanlarsen 11y ago
It's pretty easy to write "complex conditional DOM that is hard to read" in both React & Angular. But in my experience, I encounter it a lot more in Angular code bases than React code bases.
- Bahamut 11y ago

coldtea 11y ago

>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, etc. -- so all the same things you get with Angular, just cherry picked. Third, we can just as well compare Angular (or any framework) with building something from scratch with vanilla JS too. Nobody said we have to compare them "as frameworks". We can compare them as different "ways get a web app done" (with/without framework, without framework but with x lib, etc). Fourth, we can always compare apple's to oranges. Here's a comparison: oranges have more vitamin C than apples, and are better for scurvy (haven't checked the actual vitamin C stats, but you get my point).

ebola1717 11y ago
Can you use Angular's components & templating outside of the rest of its MVC architecture? Despite the insistence on HN that React = React + Router + Flux, I've been using just React with plain js objects for models, and I like it exactly because it's an easier way of writing simple interactive views.
- zeppelin 11y ago
  What if it can't? (I don't develop apps using Angular, so I really don't know the answer...) Then it's just a con for Angular, but also a pro for providing a default MVC architecture to rely on. It's a design choice that can be both good and bad.
antris 11y ago
> 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.

EvanPlaice 11y ago

tl;dr: The author is asserting that React > Angular2 because he's already emotionally invested in the former. React's greatest strength is also its greatest weakness. It requires devs to compose their app out of multiple de-centralized parts. See 'javascript fatigue'. If your aim is to write an isomorphic React app, you CAN"T just use 'plain old javascript' or anything that touches the DOM. If you care about SEO, this is a very important implementation detail to consider. Angular2's greatest strength is also its greatest weakness. It provides a unified API for building apps. It forces you to do things the 'angular way' which is no different from Angular1. So far Angular2 is heavily biased toward Typescript because it was written in TS and it was literally just released to beta 2 weeks ago. TS is good for devs bridging over from strongly-typed OOP languages, and TS provides better support for autocomplete in IDEs. TS is bad because it's not an 'official' standard and it may be an awkward transition for existing JS devs. TS is not required, I have been writing an Angular2 app in strictly ES6 despite the lack of documentation/support. Both: require transpilation; use observables (ie redux vs rxjs); use a HTML-like templating language for data binding; use the virtual DOM to speed up rendering; discourage mutating the DOM directly to encourage rendering on other platforms (ie mobile, isomorphic); require platform-specific shims that don't touch the DOM; etc... The underlying technologies of both are more similar than different. React favors a more decentralized architecture. Angular2 favors a more monolithic architecture. /axegrinding

dev360 11y ago
My understanding is that the SEO argument is becoming moot. With emphasis on the word 'generally': "We are generally able to render and understand your web pages like modern browsers." https://googlewebmastercentral.blogspot.se/2015/10/deprecating-our-ajax-crawling-scheme.html https://googlewebmastercentral.blogspot.se/2015/10/deprecati...

JStanton617 11y ago

React has a non-open license: https://github.com/facebook/react/blob/master/PATENTS https://github.com/facebook/react/blob/master/PATENTS, which basically says that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This is an automatic no-way for React for any major company

JoshMnem 11y ago
Yes... I'm really surprised that people aren't talking about this more seriously. They have removed the worst of it, but it still looks like it gives Facebook an advantage in any patent conflicts with any company that uses React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It appears that the PATENTS file claims that if Facebook infringes on your patents, you can't defend your patents without a risk of immediately losing the ability to use React (or other Facebook library). Maybe a lawyer would be able to make more sense of that PATENTS file. I'm surprised that Apple might be using React, since they have had big patent battles with Facebook: http://www.meetup.com/ReactJS-San-Francisco/events/227071839/ http://www.meetup.com/ReactJS-San-Francisco/events/227071839... http://www.theguardian.com/technology/2015/jul/21/facebook-google-dell-hp-ebay-samsung-apple http://www.theguardian.com/technology/2015/jul/21/facebook-g... I've heard that Google doesn't use React, but I don't know how long companies will be able to do that as Facebook libraries increasingly become dependencies of other libraries.
- spicyj 11y ago
  Google does use React now; as far as I know they are happy with the current version of the PATENTS file.
  - etjossem 11y ago
    Citation? Which projects use it?
  - JoshMnem 11y ago
    The last I heard, they weren't allowed to use it. If you could link to a Google product that uses React, I'd like to take a look.

craigvn 11y ago

"Angular 2 continues to put “JS” into HTML. React puts “HTML” into JS." It seems fairly obvious to me that both approaches are wrong.

iLoch 11y ago
Have you tried either? What is your concern with mixing the two? JSX is optional, by the way. I have a problem with JS into HTML because that's pseudo-coding. JSX tags are representations of classes and class instances, which makes a lot more sense than a totally new DSL for scripting.
housecor 11y ago
Do you have an alternative approach to propose?

bhanu423 11y ago

I found smaller frameworks like riot.js easier to reason around and light on almost all use-cases.

rmanolis 11y ago

I prefer angular over react. 1) It is opinionated (wasting time for decisions is bad) 2) It is simpler to organize the code (it is MVC) 3) (click)="onSelect()" is simpler. You dont have to create an object with "bind" function like in react. 4) I dont want web designers mess with my code. So putting html on JS is bad decision.

mercer 11y ago
But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways. I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...
- eseehausen 11y ago
  I don't have a horse in this race, but do you think that learning JSX is going to be any easier for non-coders?
  - iLoch 11y ago
    Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable. To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using. I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.

EugeneOZ 11y ago

"Yes I'm biased" was tl;dr actually. Or "I love JSX so much I can't even think about frameworks without JSX".

dimgl 11y ago

Oh my Christ, not this again. The framework fatigue is real. Why are people trying to push Angular 2 or React even? The former is still under heavy development and the latter is such a painful pill to swallow.

pdeva1 11y ago

Its the Angular 2 router that currently needs a lot more work. Currently things like passing data down to child routes [1], getting current route segments[2], checking active route etc are still not easily possible[3]. imho router is a big part of any large app and getting the details right is essential there. 1. https://github.com/angular/angular/issues/5330 https://github.com/angular/angular/issues/5330 2. https://github.com/angular/angular/issues/6260 https://github.com/angular/angular/issues/6260 3. http://stackoverflow.com/questions/34571517/angular-2-how-to-determine-active-route-with-parameters http://stackoverflow.com/questions/34571517/angular-2-how-to...

sayem_ 11y ago

IMO the standout difference between Angular and React is how you think about your application. Do you like functional programming paradigms and want to apply them in writing your components? Use React. Do you think immutability is too restrictive and love things like two-way binding? Use Angular. That being said, I'm a bit disappointed to see no mention of Aurelia although the author has mentioned other frameworks like Emberjs. I have been writing production code with Aurelia for about a month and this has been so far my best experience with any client side javascript framework. ES6 is very capable and Aurelia did it right by staying out of your way for most of the times by letting you write your components in plain ES6. All the while providing binding capability(with beautiful syntax), a very powerful router and out of the box package management support. I feel with all the commotion in framework space, more people will appreciate the simplicity of Aurelia and that camp will get bigger as time goes by.

dev360 11y ago
> Do you like functional programming paradigms and want to apply them in writing your components? Use React. s/React/Elm/g

scotchoverwine 11y ago

As a new web developer, where do you draw the line between a web application rendered server side and a SPA? I'm trying to develop a web app for creating invoices for a niche market but in this case I don't see huge advantages for a SPA over rendering HTML server side, the added complexity of a SPA doesn't have that big of a reward, I still plan to separate the frontend and backend, for example, writing a HTTP API that outputs json and in another process(or server) consume the json and render HTML in the frontend server (and maybe add some JS to improve interactivity). But everything this days seems about creating SPAs for new apps and that's definitely the future it seems, I'm wrong following this route or is that I'm just consuming to much SPA hype?

mercer 11y ago
Perhaps in the future there will be a time where an 'old-fashioned' server-side app is a bad idea, but right now I think it's still a perfectly valid approach, and even preferable in some cases. Consider whether your app will actually benefit from being an SPA. Does it negatively impact the user experience to have page refreshes? Or does it provide significant benefits to do things client side? If the answer is 'no', you might as well take what is currently still easier and more standardized, and go for server-side. But the next step is to ask these questions about parts of your app. In those cases using React or Vue or something similar for just those parts might be a good idea. And if you've already separated front- and back-end, it shouldn't be too difficult to realize (and it's a good reason to use React server-side even if that's all you use it for initially!).
ohnomrbill 11y ago
I've found that it makes sense to outline what actions it is convenient to view on screen at any given time, and group those things into an app (here, one JS file that is served along with some HTML by the server). So my typical applications have a handful of traditional routes serving HTML and a few small single page apps. To the extent that functionality is shared, I'll create a Clojurescript or Javascript library and reuse it. It keeps JS files small and quick to serve. I've found it to be a good balance between server-side rendering and having a massive SPA.

spectrum1234 11y ago

It seems like Redux + React is clearly going to win out. What am I missing? Yes the ecosystem is constantly changing right now but the oscillations are getting smaller not bigger. In my opinion Redux is the highest level and most intuitive, just like React was for the view when it came out. It's only a matter of time.

marknutter 11y ago
Why does Redux imply React? I use Redux with virtual-dom and end up with far less bloat.
- spectrum1234 11y ago
  Interesting. Didn't know about that

Negative1 11y ago

His argument about the 'Unix Philosophy' reminds me a lot of the argument between using big web frameworks like Django vs smaller micro-frameworks like Flask. Personally, I prefer Flask for the small projects I make because of how nimble it is but it's hard to argue with the large organizations using Django for massive projects to (seemingly) good effect. Ironic since I actually do like Angular (sorry)! Overall I felt the article was preachy and extremely biased. It's as if the author was trying really hard to convince as opposed to just presenting the facts and letting the reader make a choice based on the evidence. I have concerns about ng2 but having made an effort to learn React as well I think he dramatically oversimplifies it's ease of use for large scale projects (where Angular shines, IMHO).

antoaravinth 11y ago

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!

eruditely 11y ago
What other tools do you use alongside it?
- legutierr 11y ago
  Not OP but...redux and react-router, both mentioned elsewhere in the thread, and both maintained here: https://github.com/rackt https://github.com/rackt
- antoaravinth 11y ago
  I used react-redux combo. Thats it. They both themselves are good enough for my project to get started.

pinchn 11y ago

Angular is HTML-centric whereas React is JavaScript-centric. Succint!

DonHopkins 11y ago

The foolish, totally avoidable, misguided and completely pointless mistake that Angular 2 made was using a template syntax that was almost but not quite completely unlike HTML: <ul> <li *ngFor="#hero of heroes"> {{hero.name}} </li> </ul> or: <web-component [title]="exp1" (close)="exp2()"> That is INVALID html and INVALID xml. That means you can't edit or process or generate or validate Angular templates with any of the millions of existing HTML and XML processing tools. They have completely forsaken the entire universe of existing tools, for no good reason. The Angular 2 template language gets absolutely zero benefits from arbitrarily disobeying HTML syntax. There's nothing about the broken syntax that makes it any more powerful or tangibly convenient that could be done by an HTML or XML compatible syntax. Maybe it appeals to Perl brogrammers, but the hip stylish syntactic appeal of peppering templates with unique special snowflakes of punctuation like they were so many christmas tree decorations does not outweigh the dire consequence that you can't use an off-the-shelf HTML editor to edit and preview templates, or use any of the many other existing HTML tools to do whatever they're designed to do. I've encountered Angular 2 proponents who were such blind zealots that they actually refused to see any benefits of sticking to standard syntax and enabling the use of existing tools. They would ask things like "why would you ever want to edit an Angular 2 template in an HTML editor?" or "why would you ever want to generate a template from another meta-template?" or "why wouldn't you want to write your own Angular 2 template validators and editors and processors?" or "why wouldn't you want to retrain all of your html designers who can't use the tools and syntax they're accustom to?" Yet they were still unable to name any tangible benefits of the broken Angular 2 template syntax, that couldn't be achieved with a non-incompatible HTML syntax. I'm afraid that they next thing they'll do is invent their own incompatible version of Unicode.

franciscop 11y ago

From someone with years of experience with javascript, how is this "plain 'ol javascript"? <ul> { heroes.map(hero => <li key={hero.id}>{hero.name}</li> )} </ul>

insin 11y ago
It clearly isn't, but it starts to feel like it once you get used to JSX syntax as sugar for nested function calls with attribute object arguments.

ry_ry 11y ago

More importantly, when is the Flux Influenced, Stateful Template Enterprise React methodology gonna get a catchy acronymn? Asterisk-ux isn't cutting it, and god knows we need a buzzword.