5 ms·

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 j

• 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
    That's certainly a fair statement - I found the imperative style generated from JS directly harder to debug/work with in general, but that's why I mentioned it's a bit team dependent. Each developer's experience is going to bias them towards one or the other.
• lewisl9029 11y ago
  > I'm personally on the Angular side of the fence, I prefer the more declarative style to avoid the imperative DOM construction, but I could work with either (and have worked/am working with both) if they are done right. If by declarative, you mean artificially limiting, then I agree with you, but in my humble opinion, the React approach allows for far more declarative UIs than approaches that come before it. Templates ultimately limit UI semantics to the subset designed into the template language. Modeling the DOM as a pure JS data structure gives you the entirety of the expressive power the JS programming language, and allows you to construct your UI as a pure declarative mapping between components/elements and your app state (the approach taken by Redux and many ClojureScript frameworks), with no imperative manipulation whatsoever.
  • Bahamut 11y ago
    React uses an imperative style, not declarative - when one uses this.items.map(item => <li>{item.name}</li>), this is imperative, not declarative. You are describing the DOM with imperative language - JSX cloaks what is truly an imperative nature. This is made more clear with the non-JSX equivalent. When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language. Angular's templating is clearly declarative since one is not making a statement about how it arrives at its result, but purely describing it and leaving the implementation elsewhere. Something like <ul><li *ng-for="#item of items">{{item.name}}</li></ul> leaves the iteration implementation away from the view completely. Every piece here is descriptive, not something more. It should be noted that Angular 2's DOM model uses an AST under the hood, just like React - fundamentally they are the same in the virtualization of the DOM. Angular 2's templates are not true HTML either, but is closer to HTML than React is in its syntax. It does limit what you can do, but that is the purpose of templating languages - it limits what you can do to increase readability, increase consistent patterns, and steer users away from dangerous usage. That is an argument aside from declarative vs. imperative templating, and more emotional than useful. Now, both approaches have obvious flaws - both styles are easily (and often) abused, but both also have simple conventions to keep it clean. Imperative construction (ala React) requires one to carefully organize the control flow to avoid convoluted template construction. Declarative construction (ala Angular 1 + 2) requires one to avoid tossing too much in a singular template. What is easier to work with, that is not for me to say as an absolute, but IMO carefully organizing the control flow in template construction requires more mental overhead to avoid constructing the template in a hard to read fashion, and yet still involves the same ultimate basic strategy of having to create separate components to avoid overly complex templates, which is what one has to do with declarative template languages, but without the mental overhead of accidentally abusing control flow in its construction.