Angular 2 versus React
medium.com
medium.com
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.
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.
React works perfectly today.
> 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.
What would you call Web Components (polymer) if not a "big framework or library"? That's effectively what Shadow DOM, custom elements, &c amount to -- it's just standardized and shipped with the browser. (Yes, that's a massive advantage, but not until we have 100% working shims and/or browsers that comply 99%+ with the specs.)
EDIT: I should also say: Polymer itself is quite opinionated about how you should structure your custom components (and thus JS code) and this may be a disadvantage to some. This doesn't seem to affect Web Components per se, so that's something. Also, something like the virtual DOM will probably still be needed for speed.
You don't need a library at all if that's what you prefer.
The polyfills are there now and they are solid. Webcomponents.js is small and effective. The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.
This leads to a tangential point which I find somewhat interesting to ponder: If the polyfills are good enough... then why does this actually need to be a browser standard?
I'd really like to get to a place where we (collectively) find some sort of minimal API-type "thing" that browsers need to support such that everything else can be polyfilled. I would even go so far as to include things like future ES standards in that, such that you could just "plug in" (in the page, not the browser per se) a shim for ES2015 and it would work near-natively. I know Microsoft Research had at least one project going in this direction -- unfortunately its name escapes me at the moment.
> The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.
FWIW, that may very well be true. AFAIR all my tests were done with the paper elements.
I definitely agree that Web Components in some form is the future of application development for the web -- unless we're talking stuff that mostly just wants to use the browser as a delivery platform like WebAssembly. Of course that may change if/when WebAssembly can interface well with the GC/DOM/etc. (Well, come to think of it Web Components might also be massively useful for authoring documents sanely using custom components for higher-level semantic elements, but that's a digression.)
Just FTR as well, I have actually implemented a small application using Polymer just to get a feel for what it's like. Overall it was reasonably pleasant as Web development goes, but it's really disconcerting that all the state[1] passed down to sub-components gets represented using attributes-but-not-really-because-they're-not-primitive-types-any-more.
[1] At least, that's the idiomatic way, AFAIUI from Polymer documentation.
EDIT: I should edit while I can: I semi-believe that Web Components is sort of along the right lines wrt. what needs to be standardized (and perhaps WebAssembly + an interface to the WebComponents API can do the rest?), but frankly I probably don't have nearly enough expertise in this field to even have an opinion. So there. :)
https://www.w3.org/community/nextweb/2013/06/11/the-extensib...
(Of course, higher-level APIs still get added.)
Having said that...
- Is that the actual manifesto? I couldn't find any link to any more detailed document, but maybe it's a browser/adblock thing.
- If yes, then... I agree with nearly all of it (having just skimmed it), but it seems a bit... bland and fluffy (as opposed to concrete).
That's not exactly what I was imagining with my ever-so-specific "API/thing" nomenclature :) I was thinking more along the lines of a "universal bytecode for web", but a) not just for code, and b) one that actually works. Maybe Java 25 will get us there, who knows :)
No. Actual manifesto:
https://github.com/extensibleweb/manifesto/blob/master/READM...
Perhaps WebAssembly is close to what you think of as a "universal bytecode"?
In the long run, WebAssembly may be it. As of the promised-1.0 it's just a way/excuse to run C/C++ code on the browser's VM with some GL/Canvas mixed in there. I mean, I understand marketing a FPS-game-in-the-browser as the be-all and end-all thing, but that's not my market or end game :).
It'll be really interesting to see what happens with WebAssembly 1.1, 1.2, 2.x... Will they be the ones to surmount the insurountable obstacles?
(I've been around for quite a long time in the industry, so... having learned things and just how much the last 20% takes, I tend to temper my optimism quite a bit.)
It's a manifesto for how to approach writing standards for the web, not a standard itself.
I appreciate the point about meta-standards vs. standards. I think I'm more looking for concrete technical standards (to obviate all others before them![1]) than meta-standards. The web has advanced significantly in the last few years, perhaps even as a result of this meta-standard, but ultimately I'm skeptical that competition between entities that don't have the same goal will "succeed"[2] in any objective sense. The point me be a a bit muddled at this point, but think "principal agent problem".
[1] Because that always works! (Find your own XKCD)
[2] Yeah, I know. Everybody has a different idea of what that means.
React, Angular 2, and probably most other frameworks with templates do the same thing.
If it makes you feel any better, the key point for me is that these are not HTML, they're templates embedded in HTML via a DSL. This DSL is valid HTML, but it's necessarily interpreted and modified by the template system.
Also, it's great that these values are not primitives. One of the persistent detractions (made by a core React dev I think) against Polymer is that "everything is a string because attributes", which is just wrong. As you note, Polymer uses attributes in template to declare binding to properties in the resultant DOM, which can be of any type. I think it's great that you understand this distinction, even if you don't like it :)
Polymer improved substantially with the 1.0 release. It was basically a full rewrite so if you checked it out before then, you'll have to re-check.
Edit: The reason I like React more is the fact that Facebook uses it in a high traffic production setting.
Edit 2: I think the whole Javascript (or framework) fatigue is just a 'transition problem'. Old tools are getting replaced by new tools, causing confusion..
I did not know about YouTube Gaming, it looks very interesting.
https://play.google.com/store/apps/developer?id=itdisplayswh...
If Adwords is Angular then that's one big project on Angular (clap clap clap). However, all I ever heard was that they were planning to move to Angular2 on Dart. I wonder how that worked out.
edit: just editing to add that I´m not doubting that Google is using Angular2 in some projects, like their internal CRM (Green Tea or whatever). I simply wanted to point out that it's not used _extensively_ in their main consumer facing sites - the ones you get links to when you click on their apps dropdown menu.
Obviously doesn't include stuff in the works :)
If I was building a webapp that was going to have hundreds of millions of users, I'd think twice about grabbing an off the shelf JS library.
Exactly, same thing happened early on in Ruby/rails community.
State control. The most important thing about a React app is that you can write your code to have every bit of application state inside a single variable. It gets you hot code loading, trivial testability, and session recording/replay. I can actually test the app without having to use selenium (which I hate). These aren't really benefits from React per se but from the vdom approach. My apps are in Clojurescript and don't use the majority of React's features so replacing it with an alternative vdom implementation is on my todo list for this year.
I haven't used it in anger, but Polymer is at the top of my list if I needed to write an app to integrate with a third party or something where I didn't have app state control.
I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.
I personally despise Lisp syntax.
Typically, Mithril uses raw JS lists, function calls, and objects to create its vdom, which you have to directly manipulate. Like using react without JSX. With a lisp syntax, you might write the end of an expression as )))))), as opposed to in JS, where you might write )])]}); or something similar.
But it's not strictly parenthesis that bother me. You're right in that )]}) is actually far more annoying. I try not to nest that deep in JS if I can help it.
Arrow functions reduce the pain. Not passing array literals in function calls helps as well. Angular seems like the big culprit that injects [] into the middle of an argument list, for me anyway, and using that syntax is optional.
I've actually considered the idea of hacking a JSX compiler to spit out Mithril output.
If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.
It did seem like an obvious thing to do. I probably would have searched for and found this before doing any actual work on JSX, but I'm glad to know it exists already. :)
[edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of).
Also, thank you for the mithril blog. It is amazing.
Everybody else, if you haven't read the mithril blog[1], YOU SHOULD BE READING THE MITHRIL BLOG. Even if you never plan to use mithril, you'll probably learn something interesting.
https://developers.google.com/closure/compiler/docs/api-tuto...
Not an excuse for baroque frameworks though.
The end result is very React-like in behavior, but completely interoperable with other web components, and not require a framework at all.
Web Components hasn't been supported by all browsers (and probably still isn't) and has had some problems with grouping components and loading them. I can use React today but Web Components is something I might want to use in 2-3 years.
It took me a long time to figure that was the point and it still kind of seems you could write in good old plain javascript:
x = "some state"
if (you want to change it) { x = "some other state"
DrawThingOneThatDependsOnx()
DrawThingTwoThatDependsOnx()}
(Plus with vanilla js running up to 40x faster than React https://news.ycombinator.com/item?id=9824884 apparently)
State control is not simple when you have many moving parts. A very good solution (which both Angular and React bring to the table without destroying performance most of the time) is to remove all the moving aspects to the parts. This doesn't matter in microbenchmarks, but in real apps, having something be slightly slower but bug-free is better than fast but wrong.
function constructor(spec) {
let {member} = spec,
{other} = other_constructor(spec),
method = function () {
// accesses member, other, method, spec
};
return Object.freeze({
method,
other
});
}
All application state can be stored in a single "Atom" (i.e immutable data) and all message passing can be achieved through CSP channels.
When dealing with the DOM, 'incremental-dom' is a nice option.
Of course, separating pure functions from side-effects inducing code is key to maintaining control.
This is my approach when going "framework-less".
That particular link is a strawman argument. React isn't magically fast. Writing a 5 line shouldComponentUpdate would normalize the performance.
If you think you can do better with something else, feel free to ignore the React hype. For my part, I've been doing frontend full time more or less exclusively since 2005 and have tried dozens of libraries/frameworks in earnest. I don't know of a better way to write client side code.
I've built a small app in vanilla JS, so I know what the alternative to using a framework is like.
Doing XHR by hand is not easier than using Ember-Data.
Writing custom JS components is not easier than extending Ember's Component class.
This problem is not Ember but JavaScript in general.
Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io)
I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc.
Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought.
PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester.
As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to.
The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers.
This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth.
The important part being, all parties involved are working towards (and together) on a better faster more wonderful future.
Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer (written in TypeScript), V8 with turbofan and the team, working together to improve JavaScript in the browser for everyone.
Poylmer doesn't simplify UI development like React does, the components have to be statefully managed, and always will be because creating/destroying polymer/web components is expensive. The beauty of virtualdom is the previous state doesn't matter in deciding what the new UI should look like, or if a component should be added/removed. Simply render off the current state, which is cheap, and then the previous & current virtualdom is diff'd and applied to the real DOM.
Web components are exciting, and React can leverage it to do CSS sandboxing, though people are already effectively doing this [1]. And the cool thing with declarative programming is we can swap out implementations with more performant ones.
Also, components don't have to be stateful. An element can be viewed as a function invocation which accepts attributes, properties and children and returns DOM. An element which deterministically renders some DOM based only on those inputs is very much like a pure function.
How a custom element produces its DOM nodes are entirely up to it, and several approaches fit with a pure functional view of elements: 1) re-render and replace the entire component DOM, 2) Use a VDOM to patch the component DOM, 3) Use incremental-dom to update the component DOM, and yes 4) template systems like Polymer's can be easily used in a pure functional approach.
The key to being "stateless" isn't in abstracting away the DOM, it's in only using the inputs (attributes, properties, and children) to determine the DOM structure, and only allowing the host of an element to modify inputs so that the element behaves more like a function.
It's similar to mutable object that never modifies its own state, only has public state, and whose methods are pure. Method behavior is fully determined by state that the owner controls.
VirtualDOM is basically that caching mechanism
{{bindingVariable}}
${bindingVariable} // Just like in Javascript template strings!
<input type="text" value.bind="variable">
<input type="text" value.two-way="variable">
<input type="text" value.one-time="variable">
<div inner-html.bind="variable | markdown">
[1] - http://aurelia.io/
EDIT: Added a little more to explain my reasoning.
I am currently in the process of re-building our company website with Aurelia (previously Angular 1.X).
* A flash of unstyled content
* No text on first load for 5 seconds
* A one second delay switching between pages on the docs page.
Bring back text/plain.
That being said, React really makes it easy for those components to be tiny little things that do only one thing, that compose nicely, and that are easy to understand. There's a heuristic in programming that if a function is more than a page in length, it's probably too complicated. The same heuristic applies to React: if your component (JS, JSX & CSS together) is more than a page, it's probably too big.
Just the act of splitting apart the JS, JSX & CSS encourages the components to become much larger.
There are parallels here with languages. Perl, which garnered a reputation as a write-only language, has seen a dramatic increase in the quality, legibility and effectiveness of modules over the last decade, and this corresponds well with the lack of an influx of new programmers (but with a minimum core of users still present to implement new modules). That said, there are many, many other problems when you don't have enough new blood flowing into your ecosystem, so I don't recommend it.
<laughs>
Polymer is a whale. And after Angular, I am NOT getting on another Google-funded hype train
This is the year of the framework fatigue meme.
Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.
I've been programming since I was a kid in the 80's, after a while you learn to stand back sometimes and let the bandwagon roll on past or as I've joked in the past "these days I simply get on every third bandwagon".
You're very right, you really have to pick your battles. It's interesting since I'm doing more contract work and finding out that one shop uses Angular and another Backbone and a third React. Which one should I really learn and focus on, when nearly every shop has a totally different philosophy??
Even trying to pick the winners in these framework battles is getting exhaustive.
I'm still using knockout.js since I've used it for two years, it's maintained and each release is a big improvement in features and recently speed (massive improvements in 3.4).
Its not that react et al don't interest me but the switching costs are real and I'm not sure what they'll look like in a year.
How about, everything shifts to isomorphic rendering. Generate an interactive view stub to display on the client while the app bootstraps.
There's no justifiable reason why we should have to refresh and completely re-render the page every time the view changes.
From a 'business perspective' it's worthwhile to have front-end devs build all of the view logic (incl templating, routing, etc) on the front-end while the back-end team focused solely on building APIs, microservices, and data management infrastructure.
If back-end devs are responsible for everything incl templating, the front-end devs responsibilities are limited to... Photoshop, HTML, and CSS?
Sometimes referred to as 'micro framework' architecture in Software Development vernacular. Let the down-votes begin!!
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
I actually think frameworks are too monolithic, and we feel the pain of that, but no one has figured out how to do something more granular yet. To a large extent that's a community administration problem, not a technical one, which is why you don't see a lot of computer scientists trying to do it. Though it will require some technical chops too.
Node/NPM, and UNIX before it, are attempts in this direction. It's not really gelling yet though. The various component systems are trying, but inevitably fail because they are trapped in a single layer of the framework stack. I think we need a few more breakthroughs in social organizational strategies (things like Flickr, Uber, Bitcoin, etc) before it becomes obvious how to do it.
It's dumb that the browser renders HTML, a framework bootstraps, parses the template, then re-renders the view.
90% of the front-end frameworks exist to provide templating + some special set of features.
If we standardize a pre-render hook to plugin custom templating engines then frameworks can shift to focus only on their implementation specific strategies (ex data binding).
Anyway, I know you are a big contributer, do you mind showing me the discussion where we determined '*ngFor=' and '[(two-way)]=' was implemented to play nicely with WC? I would be interested in reading. Thanks!
The longest (heated) discussion ever covers a lot of the reasoning: https://github.com/angular/angular/issues/133
More in depth design stuff here: https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG...
Demo: ng2 + google-youtube polymer element : http://plnkr.co/edit/yh0ACeu6g5n8D7YuhJvg?p=preview
My simple question that nobody's been able to answer yet: Name any benefits of the broken Angular 2 template syntax, that couldn't easily be achieved with a non-incompatible, HTML-friendly syntax.
The "Databinding with Web Components" design document [2] makes the dubious claim that "The HTML attribute name of a databound attribute must be escaped in some way."
That is precisely what namespaces are for, so why not simply use namespaces for the purpose they were meant to be used, the same way any well designed standards compliant template languages like Genshi [3] does, instead of inventing a new, non-standard, incompatible syntax?
The entire point of the design of the XML namespace prefix syntax was so that it was compatible with XML syntax. Why do the Angular 2 designers think that was such a bad idea?
I'm not the only person to point this out and have it brushed off and ignored by the Angular 2 team.
"Regardless, it is inappropriate for the angular team to take a hard anti-xml stance." [4]
"I wonder why ngnl presentation and current docs about templates still promoting []()# as parts of new syntax, when opening post in this thread contains 'element.setAttribute('[foo]', 'exp') does not work' and, especially 'SVG requires valid XML and []()# is not valid XML.' If these problems are solved somehow and we just don't know - please let us know." [5]
"Given the lack of xml/SVG compatibility, I would say that the []()# syntax simply fails to meet the constraints, and should be eliminated altogether in favor of the prefix proposal." [6]
"Please don't break HTML syntax :( I love Angular because I can write templates for it in any templating language like SLIM or HAML or Jade (you can't do it in Ember or React, for example). Introducing non-standard characters in attributes makes templating languages unusable (as well as syntax coloring and introspection in IDE)." [7]
[1] https://news.ycombinator.com/item?id=10842902
[2] https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG...
[3] http://genshi.edgewall.org/
[4] https://github.com/angular/angular/issues/133#issuecomment-6...
[5] https://github.com/angular/angular/issues/133#issuecomment-7...
[6] https://github.com/angular/angular/issues/133#issuecomment-7...
[7] https://github.com/angular/angular/issues/133#issuecomment-6...
JSX is very much optional, despite what the docs imply. I've had good luck with converting a DSL that I was using to spit out HTML to React components that made the transition fairly painless: https://www.npmjs.com/package/recup
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).
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.
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.
Who said those who use Angular will just use Angular only as it comes upstream and won't pick and/or substitute a few libs for third party ones either?
It's the fact that Facebook has broken up react and all the surrounding architecture in a new way that is modular and logical for sharing code efficiently across various elements of a project or across projects. When I get excited about react, its because of things like Graphql coming out which is an entirely new way of interacting with your server that makes client side development significantly better.
They are creating entirely new ways of how you interact with the server side from the client side. This is why I love react and everything surrounding it. Not because it compares well to some random JS MVC that is completely tied to the DOM like angular, ember, or polymer.
And that's what React is able to do, because it's a library, not a framework.
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.
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.
Just a pedantic touchup, ember does not use Handlebars (it once, several years ago did) Now it uses something (Glimmer) which shares some syntactic similarities, but usage/implementation have diverged.
> to simply make web markup what it should be: Interactive
Therefore, Angular, to me, acts like that "dynamic markup" when writing it. It feel more natural to me at this point.
Data (JS) and presentation (HTML) are necessarily coupled. Hiding that coupling in crazy tokens and syntax in HTML is not equivalent to removing it.
And as the article points out, it's just JavaScript.
[1] Ultimately probably insignificant, overall.
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.
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/
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. :)
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.
> 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).
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.
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.
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.
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.
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.
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.
I love the fact how each component in React can be composed! Its just beauty!
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.
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.
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.
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.
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.
"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
<ul>
<li *ngFor="#hero of heroes">
{{hero.name}}
</li>
</ul>
<web-component [title]="exp1" (close)="exp2()">
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.
This is an automatic no-way for React for any major company
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.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.
Only public evidence I have of this is Firebase (owned by Google) being unwilling to use React and then happy with the new license:
> The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.
"The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors."
[1] https://code.facebook.com/posts/1639473982937255/updating-ou... [2] https://news.ycombinator.com/item?id=9356508
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
And did you try using Immutable.js ? From my understanding, it doesn't work so well with simple router.
and, using react-router from a couple weeks ago, so this is using the "old" 1.x version.
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.
Edit: Note I'm not saying you should install VS2015 just to get Node, but it might help you convincing the powers that be that "hey, Microsoft installs these components as part of VS2015, so it's not that weird, I promise".
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.
s/React/Elm/g
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
2. https://github.com/angular/angular/issues/6260
3. http://stackoverflow.com/questions/34571517/angular-2-how-to...
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...
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.
Yeah, that's what it really boils down to. Many of the principles we apply are holdovers from when we used HTML and CSS for what it was originally intended: pages with content.
The way I see it, HTML and CSS were not meant for any of these apps. But if we are going to 'abuse' these technologies, we might as well chuck out the rulebook and optimize for what apps need to do.
That said, please don't do this if what you're making is 'pages with content'!
The point I was trying to make is that JSX is significantly more convenient for coders like me, as the markup is is the trivial part and the logic is usually the complicated part. So a javascript-first approach benefits me tremendously over trying to figure out how to get my logic working around the logic-less templating systems, or over learning a html-like DSL as in the case of Angular or Vue.js.
I've even considered not using JSX at all (a bit like mithril.js). The only reason I still do is that I like the visual separation of code and markup, and that I like seeing what the the end result will look like (more or less).
So if the JSX approach is so much more convenient for coders (not all, but many), and if the types of projects where you use React tend to be too complex to involve non-coders writing html/css anyways (in my experience), why not just use JSX?
That said, I don't really have a horse in this race either, I guess, because I'll adjust my choices based on circumstances. A while back, for example, I used Ractive.js instead of React.js for a project, because Ractive.js uses mustache templates and simpler two-way binding (a bit like Knockout.js). Because of the particular circumstances and the relative lack of complexity of the app, I figured I'd optimize for what cheap(er) front-enders with less coding experience could take over from me, as I wasn't planning to stay on the project long-term.
I've wasted A LOT of time debating controller vs directive; asController syntax; service classes vs static factories vs rich models (resources); best way to deal with nested components etc. The problem is, most of the time I wasted with decisions in React was right in the beginning (deciding on how you control flow, how you build your app)... But with angular, all the pain points came late in the game when you thought you had done a helluva job designing a GREAT app, then you slowly come to realize its a tangled tag soup piece of crap.
> 2) It is simpler to organize the code (it is MVC)
If you call it MVC, then Id case it like this: mVc ... because the view portion of it is enormous! In fact, the very idea that they made the "template" do so many things is a huge reason why it could be considered a very bad flavor of MVC to begin with.
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!
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
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/deprecati...
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!).
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.
How about a future where you don't write any code at all? This is the beauty of Angular's markup-centric approach, it's declarative so that means less code, which means less opportunities for devs who enjoy typing to screw things up.
Jeremy Keith made a good point in his An Event Apart talk [1], where he talks about HTML slowly subsuming interactive elements (e.g. like how HTML5 adds better form type support). Angular is pushing things into this realm by helping to take code out of the picture more and more.
http://aneventapart.com/news/post/the-long-web-by-jeremy-kei...
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.
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.
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.
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).
<ul> { heroes.map(hero => <li key={hero.id}>{hero.name}</li> )} </ul>
It seems fairly obvious to me that both approaches are wrong.
Asterisk-ux isn't cutting it, and god knows we need a buzzword.
Just an aside, but who would've thought that Facebook would be the one to develop around the Unix philosophy? Yes, I know that Google is a monolith, but it became a monolith over one very specific feature and mission, whereas Facebook had to accompany many kinds of user-interaction and behavior right from conception. When Zuckerberg guest lectured CS50 (more than 10 years ago), he didn't foresee FB doing open-source:
https://youtu.be/xFFs9UgOAlE?t=17m25s
Excerpt: "There's a lot of work that goes into making stuff open source. And it's on top of whether or not you want to lose the competitive advantage...there's a lot of support and licensing and all that stuff. We found that it's been annoying"
Yes, I know FB of 10 years ago is nothing like it is today, with much different people and components...didn't React arise partly/mostly from Instagram? Either way, I was encouraged to use it early on because it was purportedly being used in Instagram production. Angular 1.x wasn't in any of the big sites (other than DoubleClick?). It's nice to see it in more of Google's sites now...but honestly, how it has currently been used has left a bad taste in my mouth. I'm thinking of the Cloud/Compute Dev console. I spun up a machine, thought I shut it off, found out I was $30 in the hole at the end of the month. No big deal, I've done that with EC2 too...but the difference is that AWS's interface, ugly as it may have been, was very easy to use to shut down a machine (right-click, Terminate). I'm ashamed to say it took me about 10 minutes to do it in the Google console. Part of it is unfamiliarity, sure...but nothing interacted the way that I, as a developer, expected it to. I finally found the button or whatever that brought up the panel to show the Terminate option -- it was on the very bottom of my widescreen monitor window...which is a huge visual gap from where the instance-icon is. Maybe it's different when you have several instances spun up and your eye is naturally drawn to the bottom...
Anyway, I know overly-enthusiastic-responsive design is not something that can be blamed inherently on a framework. But it doesn't inspire enthusiasm when it is poorly dogfooded on a developer-facing UI. I mean, it's beautiful, but in all the wrong ways, with boxes of live-updated charts showing performance/activity metrics, but in no discernable hierarchy, as if someone wrapped the page container with jquery.isotope. It's something I would show my boss to make it look like I was doing something impressive but it was not great for productivity.
In contrast...the way that React was justified in its announcement had immediate appeal. The number of UI/UX things that FB and Instagram have to constantly update because of their dataflow required React's kind of overhaul, and it was easier to trust that they would not only maintain React, but design and add features only as necessary.
You can make sloppy interfaces with any library or framework. Angular is no exception. Neither is React.
I love the Google cloud console (the new one especially) and find it vastly easier and faster than AWS.