Hacker News new | past | comments | ask | show | jobs | submit login
Angular 2 Final Released (angular.io)
838 points by mikeryan52 on Sept 15, 2016 | hide | past | favorite | 431 comments

I use Angular 2 in production since November 19, 2015 (alpha.46). Currently I've built 3 web apps (40, 60 and 20 components each), 3 mobile apps (with Ionic 2) and my employer have plans for more apps.

Breaking changes during alpha stage were expected, so I didn't have issues with it.

Most positive things I want to highlight:

1. Components are encapsulated and truly reusable (and without dependencies hell).

2. You don't need any "bridges" anymore to use 3-rd party JS libraries inside your Angular app. Nothing need to be "angularized" - twbs, D3, all just works out of the box. Maybe it's even most important part for me.

3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.

4. Performance is great.

5. Community is friendly and have a lot of fun and patience, even to newbies.

6. TypeScript gives a lot of bonuses with zero price - you don't need to learn anything (you can just rename js to ts and it will work) and additions to JS are simple and powerful.

7. Cool abilities like AOT-compilation, server-side rendering and tree-shaking.

Congrats to the all devs who are using Angular, congrats to the Angular team! :)

Any chance you can do a quick cons review too? Specifically comparing to the weakness of Angular 1 like bloated complexities, issue with custom directives or scope life-cycle.


1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler.

2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs of. Add to that that there's no clean way of doing testing with Observables at the moment (integrating with the rxjs testing schedulers is very finicky). This is doubly true if you're using ngrx (which you probably should).

3. Template language. I'm one of those who don't think it's a very good idea to bring a new DSL into html. I'd much rather do it the React-way of bringing HTML into JS instead of relying on a very complex compiler to do magic behind the scenes. This becomes a bit better with the template pre-compilation, but it's still new syntax that you need to learn and keep in mind. Some of which is not intuitive nor well documented (i.e. how pipes and parentheses work together).

4. It feels unfinished. This is to be expected since it's just on it's initial release, but the sharp edges do show up quite a lot. For example we very often have to do manual subscription and unsubscription of Observables in Components. This feeling also goes for quite a few of the community addons, such as the browser-extension. While I absolutely applaud their efforts, it's far from reaching the quality of e.g. the Ember-Inspector.

5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative, with you having to fundamentally grok how parts of NG2 works to even come close to understanding why it's not working (getting this a lot with the change detection).

6. Lack of documentation. I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well). The NG2 docs are definitely better, but I feel like my mental model for reasoning about how things work was still very weak when I had finished going through the docs. There's some really huge gaps in there (testing) and a lot of the really complicated stuff that you will stumble over is only really documented in semi-old blog posts.

> 5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative,

And they said your angular 1 experience wouldn't carry over.

On 3. I've found Aurelia templates to be much better in that regard. Their templates are valid HTML and compile well. I'm not a huge fan of embedding html within the JS (even with JSX) been easier to work with separate template files and keep as much JS out of them as possible. This has helped reduce harder to debug errors that crop up when the JS inside templates fails.

I concur. Aurelia feels much more like the standard HTML that I've been working with since the 90s, only more powerful. Hence we get power without unnecessary complexity.

> 5. Sub-par debugging experience.

I've worked with AngularJS and React. After spending enough time with each framework that I'm "productive" with them and don't get constantly confused by what's going on, this is now by far the most important reason to me when adopting a framework. React(and Redux) just spoil you with an awesome debugging experience, and it's just painful for me to go back to any set of tools that takes some of that away. The rest of the points I've already "suffered" through with AngularJS, and it is my opinion that they are a rough, but surmountable cost. Having a poor debugging experience, however, just kills my willingness to work.

(For the record, AngularJS has some debugging aides - you can inspect scopes pretty easily given a DOM element. However, the watches and digest cycles, which do all the heavy-lifting, are pretty much opaque - you need to have a good understanding of how your watch expressions are compiled into watch functions and place conditional breakpoints deep within the framework in order to inspect why a certain watch is not being called/being called too many times)

> I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well).

I haven't found either of these to be the case. Is your experience recent? If so, will you expand on it? I like Angular 1(.5) quite a bit, but I'd be interested to hear more about a different perspective.

My experience with Angular documentation was similar, as well as the getting starting guide.

I remember posting an issue on stack overflow about an issue I was having on the first few pages of the guide, I realised I had misread the docs, and I answered the question myself. But that post is now my top voted question on SO, so I don't think I was alone on my experience with the Angular docs. Mind you this was 2014.

Compared with my experience with the Ember docs, the Ember docs & getting starting guide was way more readable & easier to follow. (also in 2014)

In 2014 when I started using Angular, I could not make heads or tails out of the docs and went stright to 3rd party tutorials. Today, if I know what I need and just need to remember the syntax, I will go to the official docs, but if not, I search elsewhere. I still don't think it's suited for learning.

I had the same reaction. What made it worse for me was that there was no "standard" way of doing things so different third-party tutorials would take different approaches. There was nothing I could find that suggested what the team would recommend how to approach different things.

Other libraries and frameworks have multiple ways of doing things but most times the documentation would provide an example that could be considered the way to do things.

> looking up esoteric lint-errors from the Typescript compiler.

Thought that's a lot better than hunting down bugs in production.

It's very strange to me, any one of the cons from 3-6 will make me avoid a framework. Do you think the pros of the framework outweigh these serious cons?

At the moment? No, I don't think so.

To be brutally honest I think the only reason why this is on HN frontpage is because of its name. It's quite telling that they kept the name despite it being a totally different beast with (imho) an entirely different audience. No way they'd get this much support from the webdev community otherwise.

However I do see the potential, and one should not forget that this is just the first version, straight out of the oven.

Give it some time and I'm sure it will improve.

It kind stinks because they iced the growth of angular 1 when they announced it.

Hard to test, hard to debug, poor documentation? Yeah, sounds like I don't want to be near it.

To be fair, outside of testing I have generally found the documentation to be excellent. Also, the debugging tools seem to be pretty nice. In particular, Angular Augury looks amazing: https://augury.angular.io/

However, if you dislike the approach to templating, you will definitely dislike angular. This is one of those things that is controversial, regardless of which approach they had chosen.

Solid list. Having just used Angular 2 on a side project, I'd also add that I'm not the biggest fan of passing properties between components. @Input and @Output don't seem particular intuitive nor necessary, but maybe I'm just used to React.

I haven't tried ng-2 yet but that does seem like an improvement over ng-1 where AFAIK the best way to do this was to declare some service that directives could depend on.

I felt like I was writing really bad code passing stuff around like this. My project became ugly to look at, even though it worked. This was in February and I'm hoping that either better docs will prevent this from happening to me again or maybe that some changes they made in the 7 months since fixed all that.

I dread to go look at that code...

We've converted all our node apps to typescript and I've even started messing around with replacing all our back end promises/callbacks with rxjs.

You might want to reconsider using RxJS on backend, since it is significantly slower than Bluebird promises (which you should be using instead of native V8 promises at least for now) http://bluebirdjs.com/docs/benchmarks.html

The lack of documentation about testing is a major annoyance. I really thought that they would fix that before declaring a final release of 2.0.

RXJS and it's learning curve, not just getting it to work but getting it to work idiomatically has been my biggest struggle with NG2.

Well 3 is a preference (as you've indicated), while I have nothing against transpiling I'm not a fan of having a XML DSL in my Javascript. I can't speak for angular, but I much prefer templates along with a build system that bootstraps everything.

The main con I can think of are all the extra tooling and dependencies required. However, even though angular-cli is yet another tool, it aims to solve the extra tooling problem so you don't have to know how the tools work and how to configure them. Managing third party dependencies with NPM still isn't fun and can be frusturating IMO, but it sure beats script tags.

BINGO! It smells like GWT all over again.

I love experimenting with ng-1: make a static HTML mockup; add a stub controller with a sample model and modify the HTML to insert the data and edit things as needed; add some event handlers with dummy actions. (add your REST calls later...)

All of the above can be done w/out any server or compile process - just keep reloading the page when you make changes (perhaps using something like python's SimpleHTTPServer module to serve files from your development directories). Once you get things about how you like them, start on the server side. This approach won't work for a page with a complicated workflow, but you can still prototype quite a bit for an initial learning experience.

Obtuse error logging is my biggest problem. A lot of the times you have no idea what's going wrong.

That's a general javascript problem though as soon as you involve any third party library.

Something funky going wrong when jQuery's involved? Good luck stepping through that.

This is the reason why I've been separating recent projects into two webpack bundles.

I put all libraries into a common bundle, which I blackbox in the browser debugger. This way only frames from my own code show up in the stack by default, and the debugger won't step into library code.

This also makes stack traces very easy to visually parse, as you can pretty much ignore all the ones ending in "... (common.js)".

React actually does a fabulous job of spitting out very readable error messages. It removes so many debug cycles from development that it alone is worth switching.

Anything that 'spits out' readable error messages in javascript hijacks the error stack.

Which is doubly shit.

May want to give Sentry a try for error logging: sentry.io/for/angular2

Let us know if there's anything we can be doing better :)

That's pretty slick. Thanks for sharing.

Right now, some of the Angular 2 error messages are cryptic - I find it very difficult to figure out what goes wrong in tests currently with Angular 2, the only utility of some of the error messages end up being that there is an error in Angular's compilation of a component (for example).

1) Build (compilation) system is complicated enough and all of these providers/declarations are not intuitive;

2) amount of boilerplate code for unit-tests (not e2e - everything is fine there);

3) some things were removed by performance reasons - I think would be smarter just rename them with prefix "slow". Sometimes it's more important to have some functionality than don't have it, even if your app is blazing fast.

Filter and order by pipes removed :) (for a good and documented reason, but still something I've been missing)

They were going to re-write their router for the 3rd time. The back button's broken in some angular apps now.

No thanks for the next 1 year, after Backbone, Angular 1.x, React-Redux, I am going to take a break from learning a new framework. React-Redux is simplistic with most of my coding being JS, I don't want to keep looking up documentation for ng-this and ng-that. If the framework really takes off in 12-18 months then I might consider investing some time in it.

I really really really wish they'd called it something like Bosium just to make searching for issues a lot easier. I keep coming across angular 1 solutions.

I think we should all agree and call it ng2?

Anything but Angular. ng2 works for me.

I wonder if Angular will develop into a sort of "Perl 5 vs 6" thing? Perhaps if many people just aren't ready, willing and able to make the jump to the next version.

> 3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.

This is encouraging. I always thought that looked aweful so it's nice to hear that it actually makes sense.

Having used ng2 in production for a while, I personally dislike the model behind this, mainly because it is not actually symmetric as it appears from a first look:

- input:

  <foo [x]="y"></foo>
- output:

  <foo (x)="y = $event"></foo>
To me this seems unfinished and inelegant; note also that everything is inherently mutable, but change detection will work best when the bound input values are reassigned, but if they are instead mutated at some deeper level, Angular will have trouble tracking those changes, and may behave in weird ways, which are often tricky to debug.

try [()]

Well it's a bit confusing / weird at first until you get used to it but the real confusing syntax is the mix of both for bidirectional binding, e.g. [(ngModel)], but after reading the docs it kinds of makes sense. Awesome job, love it so far.

I haven't used Angular yet. From it's description it seems to be geared for making single page apps. Or a app with a few pages because it's good a binding data to an interface.

Is this accurate? What is a good use case for Angular?

Taking the load off of your server, and making the user's PC/tablet do more work, as well as greatly simplifying the server code to focus on data flow, business logic and data integrity, rather than mixing in presentation and minor U/I workflow complications. Having much of what you give to the remote client be static/cacheable content, with minimal data such as JSON passed rather than ballooned out JSP/JSF (etc) templated HTML, helps bring down bandwidth requirements, as well as server processing.

Of course, now you have A LOT of event handling in a client app on top of your middleware / micro-services, but I feel it is a helpful separation of concerns.

I suppose in my case it helps that I would rather do more of the app in Javascript, and less in Java. YMMV, substantially - I'm pretty sure I have a minority view at work :-)

We are working on a rewrite of a largish app (for a small team, anyway) at work. We already have a second, alternate, client app for our back end for a pilot project that we can now easily tackle with the new architecture. There were very few changes required on the server, just an alternate login method to automate an initial connection to a third party app (which then runs our alternate U/I in a frame), rather than an interactive SSO form.

We have a "Few Pages App", rather than Single Page App. By design, we reload a small number of alternate pages after a longish task, just in case (e.g. - resource leaks, whether from our own mishandling, or some library) - not because of known issues, mind you, but just out of my own paranoia that I would rather plan to allow for minor errors rather than requiring perfection.

I have used Angular in multi-page application, using Angular as a better JQuery in Spring MVC application. This setup worked well combining the best of both frameworks. Angular provided two-way binding, rendering templates (in loop), dialog box interactions, better AJAX, etc. Angular based component libraries provided calendar controls, dynamic tables, etc. Spring took care of the routing pages, handling UI requests and returning JSON response from services.

I think we should not discount this style of building a web app. I've also had success with it.

You need to think hard about whether you really need a SPA for something complex, or whether you can go back to the server completely in some instances.

Did you use a templating engine at all?

I think you've basically got it.

Can someone elaborate on point 2 about 3rd party JS libraries? How does Angular 2 allow these libraries to work out of box? For example, masonry or Google Maps JavaScript SDK.

In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?

Op probably mean, that there is no Angular/ outside world barrier ( which often required using $apply function ).

>In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?

Well, there is no $scope in Angular 2, so there is no need for link function ( which was used for linking scope and DOM)

Angular uses Zone.JS for it.

Do you know of any large projects that use Angular 2? I just want see how readable the projects are.

Not sure if this helps, but trying to learn Angular2 I wrote a weather app with it using RC5. It is not the cleanest and I never used Angular 1 so I can't do a comparison.


you can refactor those nested observables using mergeMap:

  this._settingsService.settings$.mergeMap(settings => {
          this.settings = settings;
          return this._weatherService.getLatestWeather(this._location, settings);
          weather => this.weather = weather,
          error => this.errorMessage = <any>error

Thanks. Learning observables was definitely a little challenging, so I appreciate the insight.

Thanks you for sharing such a beautiful weather app.

Google AdWords - hope thats big enough.

A caveat: they are using the Dart fork (now maintained by the Dart team) which is not what this announcement is about. Not sure what the biggest Typescript app is.

As far as raw TypeScript apps, VS Code and TypeScript itself are pretty good examples.

https://github.com/Microsoft/vscode https://github.com/Microsoft/typescript

I asked around at ng-conf earlier this year, and nobody outside of the speakers were using Angular 2. I did some proper digging again a month or two ago and still couldn't find any examples of large NG2 projects in the wild.

Not very promising...

React on the other hand, I stumbled upon looking at the source of the Wall Street Journal the other day. It is everywhere now.

There is an example of an ng2 app using ngrx platform that is reasonably large -- ngrx is a redux using rxjs (more-or-less).


The Weather Channel. Lucidchart. Both in production, IIRC.

Granted, not open source, but definitely drives home the point that it is trusted in production environments.

I'd like some good examples too that aren't barebones tutorials.

I am really surprised to know that there are people that use an alpha version in production. I would never ever do that even if it was allowed, and obviously it is not allowed in my company.

alpha guys do that.

Oh, so that's what all these "alpha man" stuff on the Internet is about: folks who are manly enough to use alpha versions in production. Makes sense now.

People who only take it up at the beta stage are obviously inferior, and hence denigrated as "beta men". And then there's the detestable wimps who go only for 'stable' versions, I suppose they must be "omega men", not even worthy of a mention in discussions.

Glad to know Real Programmers[1] still exist amongst us.

[1] https://www.cs.utah.edu/~elb/folklore/mel.html

We started using it for internal web app, were satisfied by the level of quality and then switched main site to Angular 2.

What about angular CLI - ? have you found that useful in your workflow?

I have found Angular CLI productive, because it helps quickly generate components (each component has an html, ts, css, and spec.ts file with some boilerplate code). It is fairly quick to get up and running with angular-cli as compared to writing a webpack configuration file. However, since angular-cli is in beta, it lacks the flexibility that using webpack directly would offer. (P.S: Angular-CLI latest release would be using webpack internally)

their tutorial is still based on systemjs instead of webpack, not sure which loader ng2 is preferring, I hope it's the latter.

I'm waiting when they implement some more flexible (configurable) tool, and meanwhile I use angular2-seed.

As someone who uses Angular 1 currently but would pick React for their next project, I'd love to see a list of reasons why I should use Angular 2 over React.

If nothing else, Angular just stranded all their developers, while React has a huge head start on mindshare/plugins/tutorials/etc.

I like the opinionated approach of NG2 over the flexibility of React because it takes a lot of decisions off of me that i am not too interested in when building a new project. I am a full stack developer leaning more towards backend in recent years and i found setting up and finding out about best practices and "what to use" for React a bit tedious, also it changes so much. The last Flux framework i used was alt.js which was popular last year but is hardly used anymore.

I also really like Typescript and believe enforcing it is a good way to get general JS code quality up.

Of note, Facebook's create-react-app provides an "official' opinionated approach. https://facebook.github.io/react/blog/2016/07/22/create-apps...

There's even a pull request to bring typescript into the mix. https://github.com/facebookincubator/create-react-app/pull/5...

I'm just writing a first React app, and read beforehand that it was going to be difficult to choose which libraries to use, and to get them to work together, but I haven't found that to be much of an issue in practice.

create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defined path for beginners. Over time you'll have to figure out how everything works, as is always the case, but you can learn more as and when it's necessary.

The bumps were more whether to use ES5 or ES6 (but then I found an official position in favour of ES6), and whether or not you need to use flux (although that was really just learning how flux worked, which wasn't wasted time).

The only uncertainty I have now is whether TypeScript will be necessary/useful in future, and if so how to integrate it.

The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app.


Too bad flow doesn't work as well as typescript in practice. It has way more bugs, is not as tested.

It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.

Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.

this. tried flow, but it's too 'smart' for my iMac to handle. Flow reads all JS files without problems - which killed my iMac after using 6>gb ram. a partial solution was to manually set ignore on some node_modules packages. but still, really slow experience with atom/subl/etc.

Compared to this, typescript is actually dumb enough to require ts definition files to actually parse non-ts (js) files.

Having used TypeScript and also picked up recent projects where it is not being used, TS is definitely the way to go.

The issue is that TS 1.8 doesn't support async/await in the browser until v2.0, but a ts -> babel transpile does the job nicely.

TS 2.0.2 is stable enough for usage I've found, had no issues at all using it so far.

Yes, typescript betas/rc's are more stable than many products out there :p

Microsoft stuff not allowed in my stack...

Why? It's Apache 2.0 licensed...

People seem to have forgotten that MicroSoft was a gigantic threat to our industry, and still is. It owns 98% PCs world wide. What would we think if 98% of gaz stations worldwide where belonging to one company? That would be dangerous, right? Same with MS except it's worse, because PCs are eveyrwhere controlling everything. It's Big Brother in real life. Just imagine one moment how many critical decisions having world wide impact on the life of billions of people are done using Excel? What if Excel was remote controlled?

So, no, sorry, I don't eat that stuff. Bill Gates has built the most dangerous edifice and no amount of charity will save him from the Hell of digital beings.

This is garbage.

I replaced react-router with route-recognizer. The later is a simple tool your code is using, has proper documentation and stability, and do not get in the way of automated tests with jest. But react-router changed too much (i.e. removed named routes), has a lot of dependencies (browserhistory, etc), has very poor documentation, and did not allow me to do automated testing at the levels I wanted to. Moreover, it is a "framework": you're code lives inside of it, breathes through it, and that's something I dislike greatly (for such a moderate usefulness).

Agreed, react-router developers try too much to change and add new features to their baby. it has become a bit of a monster. 46KB for a minified router framework...

Good thing you don't have clients demanding IE compatibility. Bye bye ES6 :-(

Doesn't babel (ES6 --> ES5) solve this issue or is there more to it?

You're right. But I've avoided bringing transpiling or polyfill stuff into our big project at work. I'm the only dev at work who really like JS at all, anyway, so I'm trying to keep it simple for the Java-only crowd.

CRA isn't opinionated aside from the config and testing (Jest). It has no router, no Redux, etc.

It was made for demos, proof of concepts, and beginners (at the beginning, maybe not anymore). I don't know how Angular CLI works, but if it works like Ember's, then there's no comparison. Ember CLI generates models, controllers, etc. any kind of thing and it enforces a file and directory structure that makes all Ember apps look the same.

Don't have a dog in the fight-- I'm using both React and Angular2 in production. I just wanted to add that create-react-app (which was built by a few guys over a weekend or something like that?) I found to be IMMENSELY more useful than angular-cli.

I know a lot of work has been put in to angular-cli and it's been through a few iterations at this point, but I almost wish they would scrap the whole thing and fork create-react-app.

You can totally use typescript with React, in fact it's a game changer. It's actually way more beneficial than with angular, as you have properly typed components all the way down. No crappy string templates that are not checked by typescript.

True story.

But how did you get rid of the implicit anys when using JSX?

I used this compiler flag that forbids them and suddnendly nothing worked anymore. It seemed that almost everything returned any per default.

That compiler flag is wonderful, and so is the newer 'strictNullChecks'

I use these typings: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Then create my components like this:

interface Props {


interface State {


class MyComponent extends React.Component<Props, State> {


and everything is typed correctly (beside setState which is impossible to type exactly as of today)

How would you do something like this with stateless components? (Where the component is just a function that takes props)

interface IMyComponentProps { x: number; }

function MyComponent(props: IMyComponentProps): JSX.Element { return <p>{props.x}</p>; }

Maybe it was the type definition I used...

Stateless component:

  interface Props {
    bla: string
    ble: number

  export default function MyComponent({ bla, ble }: Props) {


Regarding the "Flux" frameworks, that's not a problem anymore - basically Redux (which improves on some of Flux's faults) has won. Its developer was hired by Facebook, so I guess it's kind of officially sanctioned now.

Has everyone who switched from Redux to MobX been informed that Redux won and they should switch back?

I didn't understand this. Isn't MobX the "classical" way of databinding everybody frowned upon for years? And now that React finally eased that pain with Flux and then Redux, they bring it back?

I don't think that many people switched to MobX to be honest. It's very similar to knockout observable and while it works, I don't think I would use that approach again. I suspect people like the familiar OO syntax of MobX. I can't think of advantages it has over plain old streams (most.js, flyd.js)

Who has switched? Do you have any example?

I've just finished my first major redux project and found it incredibly slow to develop with. Write an action type constant/action creator/dispatch/reducer/mapStateToProps just to show an element in response to a mouse click? I found myself cutting corners on the UI because the amount of code I'd have to write makes it seem like a huge task.

I'll be evaluating mobx for my next project, definitely, along with Relay. If I can maintain the same view-as-a-function-of-state approach of redux while writing less code, I'm sold.

That's interesting. I've only used redux for one project and you may be right. It is tedious to all those things for every little action.

I'll admit that I hadn't heard so much about MobX yet. Will re-evaluate when I have time.

Yup, this is a major strength of the front end frameworks. It can't be understated in my opinion.

I work daily on a large Angular app and a growing React app, and my React app, while being more pleasant to work with, is also much harder to keep standardised and clean. I'm also already experiencing perf issues because of not using immutableJS, which is quite annoying...

I'm currently in the same boat.

Both are similar in that they are component-oriented.

There are two important factors in my mind.

1. The ecosystem (as you mentioned). React has a clear head start here, but I expect Angular2 to make some gains over time.

2. Angular2 gives you a full framework, and as they say now, a whole platform. React is smaller and you rely on a bunch of other packages to get all the extra features you need. If you want a full solution, Angular2 gives you that.

This can be argued as a good thing or a bad thing. More flexibility with React, but also more things you need to figure out and make a decision about. With Angular2, once you buy in, you don't need to make all of those decisions.

In my particular circumstance, which is to migrate an Angular1 app to a newer framework over time (mainly for the server side rendering features), Angular2 provides a clearer path and offers some nifty features like component styles that allow a similar migration with CSS.

>> Angular2 gives you a full framework, and as they say now, a whole platform.

So did Angular 1, and then they threw it under a bus. Now developers have to either refactor for a whole new framework or get stuck with a legacy one.

Javascript ecosystem is becoming so hostile a project deprecates itself in favor of a clean rewrite and the migration path is an afterthought.

Will think twice before adopting google frameworks and tools.

Javascript ecosystem is in dire need of stability and trust.

>and then they threw it under a bus.

They didn't just do this "because." There were sound technical reasons to do so. Angular made the correct decision, in my opinion, and decided to cut its losses immediately and right the wrongs within the framework.

Well... I would argue that angular 2 is not even better than angular 1 so it will probably happen again :p It's more performant, but that's about it. It's insane, java/spring like complex for no reason.

Really? So mobile support, change detection revamp, TypeScript, the removal of $scope, and all the routing changes are all just "meh" to you?

Wellllllll... I does make me want to learn React & React Mobile if I have to largely start over, anyway.

Not saying ng-2 is not an improvement, just that it's a big change to take in.

As someone who has never used Angular but is interested in Angular 2, can you give some examples of the framework-y things it provides that React doesn't? Redux is really the only thing I find necessary for what I've developed so far, and I'm sure Angular has it's equivalent, but what else does it have?

It gives the ability to do validation with form components, using a nice XHR abstraction, and a router - all optional. It also provides a robust DI framework and set of testing tools.

All three frameworks are excellent at helping us build ambitious front-end applications; you simply can't go _wrong_ by picking one over the other. If a particular framework's trade-offs don't for any part of the app (performance for example), you can always write just that part in a different way (manual DOM manipulation).

But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose of a framework is to render a dynamic view without the programmer having to wire up every state transition with a corresponding view transition. This is done by templating content with state, mediated by the framework. And how this is done affects the entire design of the framework and apps written on them.

Angular and Ember allows state and logic inside HTML. They figure out which state variables and corresponding templates go together and re-renders them automatically. The pro is that writing a modified version of HTML without too much code lets us have a dynamic app running in no time. The con is that there is a new language to study - with its own parser, control structures, scoping, and quirks.

React on the other hand lets us specify templates as Javascript functions which are run whenever the state changes. The pro is that there is no new language abstraction to learn; it re-uses Javascript. External DSLs especially are in an uncanny valley - they're not full-blown languages but have enough quirks to be bothersome. Language abstractions forces a virtual machine (the language parser/interpreter) to evaluate the code, and it is an opaquely magical layer that makes it hard to see the entire stack of abstractions during day-to-day programming. It also forces a separation between our view (written in the templating language) with the rest of our code.

The con of this approach is simply more code to write; the programmer has to anticipate and inform the framework of any state changes. With setState this isn't as bad a trade-off as we'd imagine. And MobX meanwhile brings an Angular like state abstraction to React - it watches over observables and automatically fires re-render.

The other big difference is that React is not opinionated. It is a very much a framework alright, but it for example doesn't ship with a router, nor does it prescribe a framework for organizing the code. Ember has so far done a great job here - I often wish I could combine the Ember ethos of backwards compatibility, great documentation, and a fanatic love for the existing users of the framework, with the way React approaches templating and composing components. I haven't had the chance to look at Angular 2, but for me, Angular 1 started the front-end revolution happen, and I'm curious what they have done this time.

Have you seen yesterday's post about Cx? I'm curious what you would have to say about it.

Cx adds declarative data-binding, controllers and router on top of React and includes composable widgets and charts. It looks for a sweet spot between development speed and freedom to do whatever you want. Here's a quick example https://cx.codaxy.com/fiddle/?f=42vDn4I1.

Disclaimer: I'm the author of Cx.

First impressions: looks like Angular's two-way data binding (using custom attributes in the template itself) added to React. This should make it possible to write complex views quite fast - without writing much code, and yet we don't lose out on the component-based composition of Javascript code offered by React.

What I need time to get around to is the concept of controllers and how it works when we want to compose things together. For example, how to write a multi-select widget that exposes a clear API to the rest of the world (onChange), and encapsulates all other details within. Cx does deserve a deeper look, and I'll definitely give it a whirl some time. Also kudos for the extensive documentation you've so far written!


Here's an example of a complex lookup field in practice. https://github.com/codaxy/cx-starter-kit/blob/master/app/rou...

It's perfectly fine to add multiple bindings between lookup options and field's data. That works for multivalue fields too.

If you have any other questions I'm happy to answer in this thread https://news.ycombinator.com/item?id=12495728

Apologises if I'm miss reading this

> Angular and Ember allows state and logic inside HTML.

State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.

But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.

edit: rephrasing words

That is exactly what I meant, sorry for not being clear. State mutation definitely happen only in code everywhere, and not in templates (if we exclude two-way binding).

But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it. Loops on the other hand requires not just simple array iteration syntax, but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`).

This is my biggest complaint with adding logic to text templates; behind the apparent simplicity there is always an entire language.

> That is exactly what I meant, sorry for not being clear.

All good, I'm probably tired (Australian time).

Maybe it's my inherit bias as an Ember user, but I'd argue Ember's templating language is alot simpler than you're suggesting

> But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it.

Admittedly partials are a little weird, while I don't see them very often, it's still a fair point, however Ember templates don't deal with operator precedence as it doesn't have binary operators (entirely polish notation).

> Loops on the other hand requires not just simple array iteration syntax

Iteration doesn't have a blessed syntax, but instead utilises syntax that can be utilised by other components, and a better way to think of it is, the block inside the component is actually a function being passed to the component, which the component calls with every item of the collection.

> but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`)

It doesn't have pipes/filters, as that's easily expressed as a computed property in the js portion of a component. And I personally think scoping is pretty predictable imo.

Maybe you're just making a general remark about templates in general & i've read too far into it, then fair enough but in the case of Ember some of those don't apply, imo.

> behind the apparent simplicity there is always an entire language

Technically this is true, but I'm not sure why this matters, especially if it's trivial to learn? Because flip side of the argument, technically JSX is a different language to JS & HTML with even more complex semantics than a templating language because it carries the semantics of JS on top of it. You could make the same argument in favour of css over SASS/LESS, so I don't really see this as a big deal

I haven't worked with Ember's templating syntax, so don't have any thoughts to offer there. I was however bitten by Angular v1's templating, on which my comments were based.

SASS and LESS both add language semantics over CSS and suffer from the same problem. So does for example Jekyll's templating language. But in case of CSS, the language additions are a practical necessity - it lacks even basic abstractions, which the pre-processors provide.

So there - trade-offs.

I've written in more detail about this topic at http://www.jasimabasheer.com/posts/evolution-of-view-templat..., if you are interested.

Sure, I'll give it a read.

I recently started a new front-end-heavy project and ended up just using Angular 1 instead of React. The decider for me was the amount of tooling that React needs you to have in place just to get up and running.

React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains. And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser. Again, this all seems to want to run from a Unix command line.

I want to edit some HTML and Javascript, then reload the browser and see my changes. Angular isn't perfect, but at least it lets me do my thing without adding a bunch of extra hoops.

And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser.

I think this was true six months ago but now there is create-react-app. You might want to try it out - you won't need to whateverify your code, you just need that one tool. Also it works on Windows.


I want to edit some HTML and Javascript, then reload the browser and see my changes.

With create-react-app the browser will know you've made a change, and reload for you ;-)

npm install -g create-react-app

The fun thing watching the new world of Javascript is that overtooling is so built in to everything that nobody even realizes how many tools they're using. You can't even install this thing until you have the standard pile of javascript tooling in place. And it never occurred to them to even mention how to get said pile set up.

Once set up, this still uses all the same stuff. It just removes a few steps to produce the Big Red Button you press to run it all.

This is the problem I have with all these "easy" setups and boilerplate projects. It doesn't matter how you set up your project, unless you do it wrong, it all comes down to a one liner in the end. All these things do is hide the complexity from you with the goal of being able to "get up and running quick", which I find fairly pointless for projects that are of a significant enough size that you're considering using React or Angular for them. You're much better off learning all the tools and understanding how your project works.

But then again, the thing about the overtooling is: I can't find anything in my React stack that is unnecessary or can be removed. And really, all it is is React, Redux and Webpack. I think the complexity of front-end Javascript development is blown a little bit out of proportion.

Ah well rather than being uncessary, theres' alternatives for all of those options.

React could be replaced with Preact or Inferno.

Redux could be replaced with MobX or RxJS.

Webpack could be replaced with JSPM.

Exactly. It's "Oh, you don't like all the tooling, let's hide it all so when something breaks you have no idea where to look! HA! Isn't this FUN!"

No thanks.

> With create-react-app the browser will know you've made a change, and reload for you ;-)

Isn't that hot reloading of components which they say is unsupported?

It actually refreshes the whole page it isn't hot reloading. It's more like live reloading (who page instead of pieces of the page).

I can not share your experience at all. We are using React with Typescript for our projects at work and we have all common systems present (Linux, Windows, Mac).

Our projects compile from Typescript to ES6 and then ES6 to ES5 through babel. All of that takes place in webpack, and it was pretty easy to setup. We also all use Visual Studio Code and it's a joy to work with.

If you use something like hjs-webpack it gives you (hot-)reloading for code changes out of the box.

Visual Studio has task runner explorer now as well, it's easy to setup command line tools to run automatically, either on project open or on build.

I despair these days at the ridiculous number of command line tools you need to run, but once you've completely wasted 2 or 3 days of your life on these pointless things, cut and pasting command lines from setup instructions that give no indication what any of the flags actually mean, you can forget about them.

There were days when you just had to run an installer and then you were good to go. Or just get the latest version of the tools (and by tools I mean actual tools with a GUI and everything, gasp!) That's obviously really untrendy now.

But yeah, you can set it all up in VS to deal with the insanity for you. Good thing too, as the ASP.Net team have been drinking heavily from the command line insanity kool-aid.

Do you really want to point and click around on everything all the time? Maybe read the documentation on what various flags mean when you decide to use something.

Yes, the mouse + GUI is a lot more usable to me than typing in a CLI. The command line is from when we had terminals.

And worse still, yes, that's the case for most people. Most people prefer using mice + GUIs. Why are we going back in time? Why can't we have tools that work as both GUIs and CLIs?

CLIs are great for automation (and keyboard obsessed users).

GUIs are great for discoverability and making it obvious to users what the 'normal' usage is.

It's absolute madness to go back to the days of CLIs.

I'd disagree here. All the most productive developers I know make heavy usage of the CLI, and some of them, including me, are even developing in it with tools like vim or Emacs.

Self-selecting a bit there... Productive developer!

Have you considered that part of the problem is the stack you use causes other people to be unproductive because it's not clear what all the tools you're using are doing?

> React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains.

I've done both React projects with Python and C# apis. React is perfectly usable in VS.NET - are you aware of the Task Runner Explorer - https://blogs.msdn.microsoft.com/webdev/2016/01/06/task-runn... - hooks whatever you want into the build cycle, watches etc - once I discovered that, everything just clicked into place.

Manually reload the page? No thanks, way too slow. Using React hot loader and can't go back.

This mirrors my experience with react native. Not only did you have the react tools, but all the android tools. The abstraction leaked for me at the hello world stage where one dependency changed but I had no idea what our where without learning the entire stack.

See RiotJS

For big enterprise projects where there are many average developers, a full framework like Ember.js or Angular2 is practically easier to maintain.

Especially Ember. Probably Ember is the best choice nowadays for serious project. Great documentation and very matured.

I lost so much time with Angular 1. I don't care how much v2 is better than v1, I'm not touching it with a ten foot pole (disclaimer: switched to React, not looking back).

I'm really feeling the pain right now. Convinced previous company react was better. Even built my own app in React, now I'm at a new place that is using Angular 1.5. My god, it's so painful trying to get everything working correctly with jquery plugins. The blessed route often doesn't work, even though technically it should. I'm also getting performance issues for really simple scenarios...

The only thing in ng-1 that really bit me, speed wise, was long select/option lists. I wrote a bit to load them using jQuery instead of ng-options and now I'm good.

The thing is, angular 2 is not better. Not api wise. It's just more performant, which is cool and all, but react has a much better value proposition.

Why not choose Vue.js? It's extremely simple, fast, easy to get started with, and very similar to Angular.

I have used knockout, angular, react for a while. When I used vue.js the first time, I smiled. It made me happy.

I like vue.js, the only and biggest concern is that it is a single developer project, I'm deciding between react and ng2 now because of that concern, leaning towards react right now.

Evan has added a dozen collaborators to Vue team. so it is no longer a single developer project.

Yes, the majority of code is still written by Evan, due to speed required. but we know that vue is heading in right direction.

I like Vue.js, but there are no good UI frameworks such as Ionic that work with Vue for mobile apps.

For economical reasons. We decided between ng2, React and Vue.JS: https://docs.google.com/spreadsheets/d/1ULB2GjA3ytXAN_Sn-fEy...

React would mean to rewrite your whole application as it has a totally different basic concept. Following the ng2 migration path you're able to migrate slowly.

at my last job we did a gradual migration from Angular 1 to React. Its similar to the path to Angular 2 really. React and Angular can live side by side... All we did was build an Angular directive that can render a react component in a subtree (that's easy), and a React component that could render an Angular directive (that's a little harder, but not that bad).

With that, we could put a React component anywhere in our Angular app, and reuse Angular directives inside of React until we got around to rewriting them.

That ended up quite smooth.

Would you mind sharing the code for this?

I wanted to open source it at the time...then my employer had layoffs :)

The "React component inside of Angular directive" is fairly trivial and there's a million examples on the net. Just make a directive that calls ReactDOM.render on the element in the link function.

Angular inside of a React component is harder to google for, namely because there's so much misinformation saying its impossible.

It ended up being a variation of the discussion here: https://github.com/ngReact/ngReact/issues/80

(The code in the example isn't quite there...and its been a very long time since I did it, so I don't quite remember the tweaks I had to make).

> React would mean to rewrite your whole application

I don't see what is a problem to just drop in React into `<script>` tag and use for single part of the page, gradually refactoring stuff.

That would mean to live with a hybrid solution, more overhead and a bigger footprint. We currently deploy our JS base to web, Android and iOS (Cordova/Phonegap). It is and will remain one code base to be flexible and fast until we get "product/market fit" and until we have KPIs where we want them. This is cost effective but comes with the slowness of web-engine rendered apps. Therefore performance is big factor and we're optimizing for that. By switching to ng2 we have have a cost-effective and performant compromise.

At the moment I also moved to react, but there are some obvious advantages in angular 2:

1. as others mentioned its a fuller framework, mostly akin to using react with redux (or flux etc...) and a di framework. This also means that angular 2 third party components are probably easier to integrate.

2. Reactive Expressions, which angular2 uses in many places, is a joy to work with (though they might become maintenance hell later on I think). You can use RxJs with React of course, but it's easier when your framework is based on it

3. It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.

4. It has Ionic - which is much much faster to develop for mobile with then react-native (though obviously there are important differences). It's unlikely that an Ionic like framework for react will gain traction with react-native to compete with.

> It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.

The key with React is that you manipulate JS instead of HTML. In my experience, using JS to manipulate elements turns out to be easier and a much better experience than the conventional way of using templates.

Why JS declarative manipulation is a much better experience than using templates?

Because you have the full power of JS available to do whatever you want, however you want, to generate HTML. With a templating engine, you only have whatever the templating engine provides.

React would let you use JS-powered templates. Angular would let your use ANY (static html, JS generated, or dynamic/server generated), because its pluggable.

For me, the power offered by Razor(cshtml) is too much to abondon.

As someone who uses React currently, this would be useful to me too.

Or Vue.js, or Inferno, or...

Yeah, we have Angular 1 code in production, and I would like us to get off this train. I'm going to be evaluating Vue.js and Aurelia, and will probably push for Aurelia.

We were in the same boat back in January, and I looked at Vue and many others, but Aurelia won me over even though it was still in beta.

For anyone wanting to try react in a side project, scalajs has comprehensive react compatibility and it's just awesome.

Only downside is trying to hire Scala frontend devs.

Yeah I've been looking at this recently. I like autowire's ability to create typesafe APIs shared across the client and server. Very promising, but not simple to set up...


You don't need Autowite for that. That's pretty much basic functionality of Scala.js.

Really? From reading that guide I thought that Autowire made it easier by automatically doing the serialisation/deserialisation. How does stock scala.js do that?

Extra downside is code bloat. Scala.js on its own just maybe but combined with another major framework - forget it.

The amount of code bloat is offset by optimizing a medium-sized picture.

Maybe because Angular material components are much better than material-ui?

I've been very happy with the material-ui components for React. They cover every component I need, and it was trivial to integrate them into an existing app over time, no need to do a full conversion on day one. They also seem entirely React idiomatic, I've learned a lot about how to build reusable components myself from their API.

The problem with material-ui is that a lot of their components don't follow material design guidelines like their tables for example. It looks good, but it's not material. react-mdl is much closer to material, but incomplete due to missing components. Angular seems to have the best implementation so far, but I'm looking forward to material-design-lite v2

re:learned a lot about how to build reusable components myself from their API

material-ui's tutorials are really bad examples on this. They teach you to import from specific dir path inside material-ui. (e.g. import Pen from 'material-ui/lib/pen' or whatever)

Instead, they should recommend: import { Pen } from 'material-ui' since most of their exports are already in material-ui/src/index.js file (or some index.js file from package.json's main part)

I was put off by their TextField implementation. Their oversized <input> element doesn't play well with browsers, eg. the browser's auto-complete looks completely out of space.

I evaluated React and Angular 2 several months ago and picked React. Some of the issues I found in Angular 2:

The HTML template in Angular 2 is stored in a string. This has several disadvantages:

1. Editors can't do syntax coloring.

2. Editors can't do auto-indenting.

3. Editors can't offer "intellisense" suggestions.

4. Editors can't match tags.

You embed variables in this template string like this: '<div>{{hero.name}}</div>'.

This means:

1. Compilers can't find typos or find syntax errors at compile time.

2. If you make a typo in the variable name you don't get a compile-time or run-time error, instead the value is simply not displayed!

3. Tools can't refactor (i.e., rename) variables embedded inside the template.

4. No intellisense for the embedded expressions.

You have to learn weird syntax such as ngFor whereas in React you just use a JavaScript for loop.

In React you embed HTML inside the TypeScript and VisualStudio treats both the HTML and the TypeScript as first-class citizens. You get compile-time checks and intellisense for both the HTML and the TypeScript code! You can even put breakpoint inside the template and step through loops whereas in Angular you can't step through an ngFor.

Note that some of the above may have changed since I last looked at Angular 2.

>The HTML template in Angular 2 is stored in a string. This has several disadvantages

This is patently false. Just use "templateUrl" instead of "template". This allows you to specify a file instead.

This is the way I always did it in angular 1 as well. I don't really understand why style guides & general practice recommend embedding html in the javascript though. It's horrible.

If you're using TypeScript + templateUrl, you won't get static checking of templates. With React + TypeScript, you will.

This is literally the only thing in our Angular2 setup that I'm really missing. Besides that, I've really enjoyed working with it (by way of Ionic 2)

Seems more like a tooling issue than language issue to me. Angular2 is much more immature than React. Let the IDEs/text editors catch up.

Does Angular 2 do any compiler magic with these templates? or are the templates parsed at runtime?

we can do both. In JIT mode, we XHR for them and compile them on the fly. In AOT mode, we do that at build time and turn the templates into TS code, which we can then typecheck (thus giving you typechecking against templates) - the benefit of this is you don't have to ship the compiler code to the browser, don't pay the cost of runtime compilation, and the generated code is monomorphic and thus highly optimizable in browser VMs.

Oh cool, sounds similar to what Ember is doing with it's glimmer engine. Are you guys compiling it down to dom api, like htmlbars did? or something similar to a VM style runtime like in Ember's Glimmer 2, where templates are compiled down to a series of opcodes? Or something entirely different from those approaches?

+1 for templateUrl. It really should be the de facto way of handling markup.

1 through 3 are false - in fact, it has been advertised by JetBrains that TypeScript with WebStorm can detect string templates when using the Component decorator in Angular 2 & the template option and parse them while doing debugging & syntax highlighting, and this was months ago.

I'm sure 4 can be solved by editors, if it hasn't been already.

Which editors? JetBrains Webstorm has the same things for both Angular2 and React.


I do agree that I really really was a fan of the backticks for ES6 / react for templating. Avoiding the whole " vs ' escaping nightmare is something i've always looked forward to.

That seems like a very simple fix for them though, potentially.

edit: tone

In the page you linked the template is stored in an external html file in which case you get syntax checking for html but not the embedded expressions.

I only do backend node.js so I don't know much about the frontend stuff, but when I look at


it seems to me they in fact do support the embedded expressions?

Yep - thanks, this is a much better example than mine.

With AOT compile, templates are turned into Typescript code which is typechecked. The IDE integration isn't there yet, but it's in the works.

Also with AOT compile, breakpoints inside templates are possible, so you absolutely can step through an NgFor :)

The template vs. JSX argument is highly subjective; a lot of people go the other way because language extensions break existing plugins, require extra build tooling, and add complexity.

The same could be said about the "JavaScript vs TypeScript" argument. I can see that argument, but in my opinion, the safety nets provided by TypeScript and TSX are well worth the initial learning curve.

Angular can also use seperate template files, I actually prefer this compared to having the logic and view (and CSS...) in the same file.

What editor are you using? I'm on IntelliJIDEA 2016.2 and it supports all first 4 items. But as for the latter 4 items, I hope those features will be available in IDEs in the future with the release of Angular 2 stable.

Can you use html-loader to load templates from external html files?

Edit: You can use external html files. Just look at their tutorial[0] using html-loader at the very end.

templateUrl: './app.component.html'

[0] - https://angular.io/docs/ts/latest/guide/webpack.html

You probably missed the best option: Ember.js. It has all the best from other frameworks and it looks the only serious player out there.

But it doesn't have billions of dollars of marketing power behind it to force the kool aid down dev's throats so we are SOL!

And exactly the worst performance of them all. Coupled with the kind of spooky side effects down your pipeline that you thought long gone since the first releases of ruby on rails...

Performance? You compare 100 ms with 150 ms?

But actully, the performance is not a question anymore, with the new Glimmer Engine 2 Ember will be the fastest framework, with full backward compatibility.

I'm not saying angular is better, but "can't" might be a bit strong. Maybe "don't currently" would be more appropriate since some of those things are very possible if not already in existence.

Why would you want HTML embedded into your component? Sounds like a maintenance nightmare.

So better embed the logic into the HTML? :)

Not sure what you mean. I was just implying that it's better to use a separate HTML file for the template and reference it from the component.

Number 1 and 4 are totally false. PhpStorm does both of these.

Why not use a bundler to import the raw text from the HTML file?

Serious question : Why are SPA frameworks so popular these days? When someone asks "What should I use for web development?", It's now all about React/Angular/Ember/etc.

But when I look at how are built the sites I like and visit frequently, I'd say 95% of them are not SPA, they are classic sites where the server generate each page (sometimes with one or two Ajax requests)!

The Single Page pattern is great for desktop-like applications such as Gmail, it's obvious. But otherwise, I don't know... I think I still prefere the "feel" of classic websites.

> I think I still prefere the "feel" of classic websites.

Your hacker biases are showing.

The sites where 95% of people spend most of their time (Twitter, Facebook, Instagram, etc.) are all built as single page "applications." Users expect rich interactivity from websites these days and are usually not tolerant of UI refreshes.

The comparison is not to "desktop" applications but to mobile apps. Users expect a mobile app level of interaction. Plus, if you're building mobile apps then it's a lot easier to just reuse those same APIs for a web app.

That being said, if your site doesn't have any interactivity then it does make sense to just render it statically.

One of the key advantages of a single-page application from the User Experience perspective is perceived response time. It takes well under a single frame refresh period (~16ms) to react to some event and either change the page using data you already have, or throw a loading indicator on the screen.

The app may have been slower to load the first time (hopefully not by much) but from then on, they get the perception of instant feedback even if they have to wait a round trip for the backing data sometimes.

SPA frameworks make this sort of interaction very easy to design and reason about as a developer.

Hyperlinks are a form of interactivity. That aside, there is no reason why one cannot have many individual pages which each have their own interactivity.

If you are going to argue that this is about "hacker bias" you will have to show user studies, not poll JS developers.

And the performance of all those is just garbage in Firefox on a 3 yr old laptop and isn't that much better on mobile.

They're fantastic for forcing people to buy new hardware just to look at information :|

Well it must not be a very good 3 yr old laptop then? And firefox isn't exactly the slimmest or lightest web browser. Sucks ram just as bad as chrome used to. My 3 year old laptop can handle all of the google services just fine.

8gb RAM, great CPU. I'm playing counterstrike global offensive and civ 5 with very few problems. Lower FPS sure because the video card isn't great but it shouldn't be this bad. It was fairly decent in Win7.

Isn't that more of problem with adds or 3rd party JS?

Prevalence of API's. One common interface to query/update from. You don't have to do both server side, and client side requests. Rather do it all client side.

I've done of a few of these types, and now have moved onto mixed environments. Where most is rendered server sided, then only updates requested client side. Of course you're doing things twice for same queries.

What's with the "serious question", "genuine question", etc? Mostly I see this mannerism prefacing questions that could not reasonably be taken as a joke or provocation.

Serious question: are people so touchy these days that you have to assure them that you are not being hostile before even saying something?

I think it means "don't interpret curiosity as middlebrow dismissal".

If you look at some of the comments condemning him for not backing up his preferences with statistics it makes sense that he should preface his questions with something to provide levity. I don't know why programming communities are so touchy about their tools, particularly JavaScript frameworks. It must be a sort of buyer's satisfaction to convince themselves that they made the correct time investment.

This is a huge release for the Angular team, I'm happy for them and I don't want to sound like I'm "attacking" them with such question. Also, english is not my main language so maybe I don't understand perfectly when to use this expression or not. I see I should use it more carefully! ;-)

Someone having a different point of view online isn't that radical of a concept. Especially considering how easy it is to misinterpret the tone of someone's remark online. It just shows you're going out of your way to clarify your interested in a genuine discussion.

Fair enough.

For me it has the opposite effect, it makes everything sound less genuine. But hey, I'm just some guy, if people like it...

I find unnecessary clichéd phrases very annoying (e.g "going forward"). Maybe I'm alone in this. It's not because of pretentiousness or language puritanism, it's that it makes me feel that I'm reading something created by corporate PR or some other soulless entity with ulterior motives. My rule of thumb: if you have nothing creative to add, just be simple.

Also I think it's more intuitive to develop. You do all your logic in the "app", and the REST layer is just a glorified DB wrapper. It matches the project's inevitable phone app more closely too so you don't have two entirely different paradigms.

Of course all that goes away when your boss says you need to support JS-disabled browsers.

> Of course all that goes away when your boss says you need to support JS-disabled browsers

Well seeing as this release of angular offers some form of server side rendering, as well as Ember with fastboot, & being implementable in React or something like that. It's more approachable these days, there's some tweaking that's required, but very much doable.

Unless of course you're dealing with an interaction heavy UI.

It loads faster, you can have a richer experience, you can use less compute resources and less bandwidth. And I'd say that HN users are not typical users.

In any event, if you're making a real Web application (as opposed to just a Web site that's primarily static content) the experience is much better.

IMO building classic websites is a solved problem, while building web apps isn't.

Classic websites have CMS, things like Wordpress, and a ton of MVC frameworks that have been tweaked over the last decade, like Rails, Django, ASP.NET MVC, etc. When it wasn't a solved problem, a new one like this was popping up in the news every other week.

Now, that that's done, people are trying to do other things, like complex web apps...and so that's where the brain time is being spent.

There's honestly no need for React/Angular/etc to necessarily power a SPA, you can just use it to build smaller components. I initially got started with Angular to power a reusable video "widget" component on a WordPress site - a far cry from an SPA! It's also a great route to getting your feet wet without committing wholesale to a technology.

+1. I've made nine react apps since last year, only the two last are SPA (because I wanted to try the golang/react combo).

React is super good to take control of a small piece of the page and build a complexe widget on it (can't speak about angular, I only used it twice without getting very far).

SPA frameworks are not all-encompassing tools for buildong all web pages. Notably, trying to SEO a SPA is frustrating at best and impossible at worst.

However, in b2b use cases where SEO isn't an issue, SPA frameworks are ideal for coordinating a static-site<->dynamic-api system.

React, Angular 2, Vue 2 and some other SPA frameworks or view systems all support server-side rendering with very little coercion nowadays. That combined with google executing javascript during indexing means that SEO isn't nearly the issue it used to be.

Server-side rendering is supported in several SPA frameworks now, and SEO is not an issue if you use it.

Google's been indexing SPAs fine for quite awhile.

They're easier to develop.

Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything".

It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.

"They're easier to develop."

I don't think that's entirely true, they allow for building experiences that weren't really possible with the previous model of rendering entire pages server side on every action but they aren't easier in all respect to that. If you site is mostly static data, it's probably still easier to use the older model. SPA frameworks start to make more sense when you want to build interactive pages with components that you want to individually update etc...

But they do add complexity that can't be ignored. that's why tooling and frameworks are hugely important as they smooth out that complexity.

The biggest "easier to develop" thing for me is the ability to have the SPA separate from the server. Being able to deploy beta builds, one-off builds, etc makes it MUCH easier to diagnose production problems.

So, I guess I'm saying that it allows for much shorter iteration times, ability to experiment with solutions in the production environment without requiring complicated server solutions.

Granted, that also lets me build experiences that weren't possible, because I can experiment more and have a faster feedback loop, but for me, it's because I can DEV better.

Because today there are websites and there are are web apps. Sometimes there's a combination of both - for example a blog - it's front end (user facing) part could be rendered by the server page by page and it's backend (admin access) is a single page web app. Each is used where appropriate - website - mostly static content, SEO and web app - a lot of user interaction.

There's no such thing as a web app, just javascript apps, and every time someone ships one the world-wide web of linked hypertext becomes smaller and less useful than it might have been.

Websites vs. Web Apps.

Websites are static documents.

Web Apps use the browser as a runtime for a UI application.

You can have a lot of interactivity with plain Javascript + some Ajax requests, without the need for the application to be a single page developed using an almighty framework. Classic websites are not synonym of "static documents" in my opinion.

I have to agree with you.

HTML5, CSS3, and Javascript have matured to the point where they are very powerful and flexible. I don't always see the point of over-complicating things with frameworks.

I recently built a small three 'page' game for a trade-show booth. By using Ember, I was able to: try out a new CSS framework based on flexbox, save data to localstorage, capture images from the webcam, have 'data binding' of variables so that they updated on the page when I changed them, and deploy to surge.sh in the first hour.

All-told, it took 20 hours, 7 of which was me getting used to the intricacies of developing a full-screen "App" (no scrolling) with flexbox and implementing the designs. I'm good with vanilla JS, but there's no way I could have done all of the coding (three 'game' pages, three 'admin' pages) in less than two days.

I guess the point is, a framework that you know and are familiar with can halve the time you spend on a project. I find that to be especially true with Ember because of the CLI tools and all of the various addons.

Yes, they are very powerful and flexible. These frameworks actually payoff and simplify once your project grows beyond a particular size.

> once your project grows beyond

"Premature optimization is the root of all evil."

- Donald Knuth

Server-side rendering blurs the line here, eg you can write your page completely in react and still have the "server generate each page"

See my response to "alzoid" about separation of concerns and bandwidth/processing benefits.

Simplify server logic

Use less bandwidth

> I think I still prefere the "feel" of classic

Very detailed, proved by numbers, objective and professional argument. That's how things should work.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact