Comment by Bahamut | Hacker News Reader

Comment by Bahamut | Hacker News Reader

There are some slight inaccuracies here, such as file size reporting - Angular 2 is fat at the moment only because it is bundling the whole kitchen instead of just the one piece that is the library itself. The Angular 1 number also is off too - this link is giving me 52.8 KB for example (minified + gzipped): https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a... (all numbers I remember seeing for angular 1 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.

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

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.

A pure functional map is imperative?

Defining UI as a functional map of the state is the one of the most declarative ways of viewing the problem, IMO. Templates are maps too. The problem with templates, historically, is that they've been used only for the initial state, and abandoned for later changes because rerendering is expensive.

Code written in language that allows imperative constructs != imperative code

I would say that React is far more friendly to a declarative style than Angular 1 at least. Immutable data, redux, and virtual dom all encourage this style, whereas the path of least resistance in Angular 1 is definitely imperative mutation of state. Anyway, if you're doing significant amounts of logic in your JSX/angular templates, you're Doing It Wrong.

Unfortunately, the declarative style of programming might not be exactly what you seem to think it is. Take a look at the Wikipedia page for declarative programming: https://en.wikipedia.org/wiki/Declarative_programming

"Although pure functional languages are non-imperative, they often provide a facility for describing the effect of a function as a series of steps."

"While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs. This can be used to, for example, make a function compute its result in parallel, or to perform substantial optimizations (such as deforestation) that a compiler may not be able to safely apply to a language with side effects."

Pure functional mappings is one of the textbook examples of declarative programming. It might look like you're specifying steps to get some result in the code, but that's the wrong conceptual model. You're actually specifying the resulting data you want as a set of functional transformations on top of some initial data. Exactly how the program arrives at that resulting data from the initial data (recursion/loops/inlining/whatever else) is up to the language runtime/compiler, and not something that functional programmers needs to worry about, thus why it's declarative and not imperative.

React and Angular's approaches to templating are both declarative. React's approach simply offers more expressive power by allowing the whole set of functional transformations in the JS language rather than some artificially limited subset. React's approach also allows for this declarative approach to extend to the entire application architecture by modeling entire apps as pure functional mappings between state and UI.

UPDATE:

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

This hints to a bit of a misunderstanding of what exactly JSX is. Control flow statements are not valid JSX code precisely because JSX is a purely declarative description of UI. [1]

[1] https://facebook.github.io/react/tips/if-else-in-JSX.html

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.

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.

Reply on news.ycombinator.com