Hacker News new | comments | ask | show | jobs | submit login
Angular 2 Beta released (angularjs.blogspot.com)
418 points by javajoshw on Dec 15, 2015 | hide | past | web | favorite | 263 comments

Congratulations to the Angular 2 team on shipping before Christmas. The estimate was originally somewhere around early 2016, so this is a huge deal for them to get this out before the year was up. Unfortunately, Angular 2 launched into beta too late. In the amount of time that Angular 2 has taken to get to beta, ReactJS has slaughtered the front-end market share (in a good way) and completely taken developers by storm with its simplistic component based approach.

Unlike React, Google does not really treat Angular as a first-class citizen because they have such split focus and conflicting React like library for web components called Polymer. They provide some resources, but nowhere near the amount of resources that Facebook throws behind React and React Native.

Now lets talk about the fact that the Angular 2 project got off to a shaky start and I know they actually rewrote various parts from scratch more than once (hence why it took so long to reach beta, approximately 2 years). That horrible templating syntax needs to be mentioned, the decision to use square and rounded brackets for binding events/data and using things like asterisks in my opinion makes Angular 2 fall into the same trap that Angular 1 did in regards to developer accessibility.

I am really loving TypeScript these days and I think the decision to support it as a first-class citizen out-of-the-box was a good one (the partnership with Microsoft definitely paid off). But with that said, I think Rob Eisenberg (of Durandal fame) beat the Angular 2 team to the punch in the small space of a year in releasing his framework Aurelia (http://aurelia.io). It is what Angular 2 should have been in my opinion. Nice syntax, convention over configuration and a breeze to use.

I usually evaluate frameworks based on the job market. In the UK there are currently 298 jobs for Angular and 109 for React (www.cwjobs.co.uk). React is up on around 40 jobs at the beginning of the year.

The reality is that you should know Angular AND you should know React. These are not mutually exclusive.

Yes, but whey you get to influence what to use you should know what you want and why. For the time being I don't recommend starting with angular unless you already know angular 1 or know that your first release won't be until the fall 2016.

It's not like angular 1 has been put down. It is still a fine framework for building product.

When you say "up around 40 jobs", do you keep a historical graph on these stats? It would be an interesting read!

I just remember looking into various frameworks at the beginning of the year and trying to evaluate if React was "worth" getting into.

I'm very pragmatic about frameworks. Yes, React might be technically better than Angular 2, but it has to be better at putting food on the table. It probably will be.

In the meantime, there are a lot of Angular 1 projects that will need migrating to Ang 2.

Will people bother to migrate though? I think they might just stick with what they have and if they do need to upgrade frameworks they may very well steer away from angular altogether.

Depends if they want to keep their devs. Not moving is not an option. You just need to be coding defensively.

Indeed allows you to search for terms historically (like a Google trends for jobs): http://www.indeed.com/jobtrends?q=angularjs%2C+angular%2C+re...

React as a term is understandably a bit polluted though.

> ReactJS has slaughtered the front-end market share (in a good way) and completely taken develo

Do you have a citation for that? I still see tons of user land projects using angular 1.

Yeah, you're right not to trust statements about projects "capturing mind share" and what is "really hot right now" (not intending to quote OP). People get into their little communities and don't realize that they are not at all representative of the larger world. To make something up, I can totally believe that React is really popular in the San Diego startup scene, but it's a mistake to extrapolate that too far in any dimension. Add to that confirmation bias on the part of people seeing these trends, and everything could be taking over at the same time.

As a counterpoint, there are a decent number of people learning it around where I am in southeast Michigan. There was a conference in Detroit, they said that they got a ton of React talk submissions. I used it at a small business print shop, admittedly they just let IT do their own thing.

I think there are probably still more Angular devs, but I'll be interested to see how it evolves in the next few years.

I don't doubt that you've found a lot of people in your area who are interested in it. But it doesn't even imply that it's more popular than Angular in SE MI, much less anywhere else. You can't offer up another anecdote and pretend that it's data.

And I'm sure you did fine work, but small business print shops are not exactly industry trend setters. What difference would it make in the bigger picture if you had chosen Handlebar for that project?

But this can be countested ad nauseum via continously moving on to the next place.

We need a service that compares how software solutions are perceived.

Sometimes you have questions on StackOverflow that compare eg Angular with React, and they usually raise a lot of good points, but they are missing several dimensions:

* the products evolve, but the SO answers often don't

* the trends change as well, so what was seen as best practice 1yr ago may not be well regarded now

* you do not have an objective representation of how many people are actually supporting each technology

I think there's definitely something to be done in that space.

This is very true. A lot of people also forget that a ton of stuff that is developed never shows up in your favorite search engine. Intranets, internal apps, and so on.

I am not talking about market share, I am more referring to sentiment in the community towards React. Just based on my observations, front-end developers love React and many more seemingly warming up to it. Considering React is still a new library, give it some time, but it does not take a trend to see that it is gaining popularity while Angular 1.x has peaked in my opinion and 2.0 will take a lot of convincing to get people to use it.

I personally use React and Node.js for a lot of the stuff I work on these days (both professionally and freelance projects). I know a lot of developers who use React, so while a Google search (not exactly scientific either in my opinion) yields low use of React, just based on the circle that I frequent, there are a lot of people using React and in 2016 we will see more people using it. The last two freelance projects I worked on (for pretty large companies) were built using React, word is travelling fast.

A lot of people are using Angular 1.x, but I know for a fact that not all of them will migrate over to 2.0 when the time comes. The learning curve might be smaller, but Angular 2 still falls into the trap of being over engineered in certain parts (like template syntax).

I completely share your sentiments. I am currently an Angular 1.X guy myself with limited knowledge of React. However given the little knowledge I have of React vs. Angular 2.X I find it more likely my team would migrate to React than Angular 2 (doubly so considering the benefits offered by React native).

This mirrors my experience. I left Angular 1.x for React and would need a huge amount of convincing to learn Angular 2.x. The killer feature of React for me is the full stack approach - react, react native, relay & graphql.

Going by NPM, I'm seeing 225K downloads per week for react and 64K per week for Angular.

Unfortunately, bower does not seem to collect download stats (I assume because downloads don't go through a Bower-controlled server), and I find it very likely that react usage is strongly correlated with NPM usage. React treats bower very much as a second-class citizen, even using a separate repo for its bower repository.

I just checked Datanyze which crawls the Alexa 1m and more to see which services & libraries websites are using. They've detected 234,003 sites using Angular and 2,069 using React.

I think Angular is more accessible than React. I don't think React will be adopted as much by non-engineers. React is usually used alongside significant tooling like babel and webpack/browserify and some flux library. It's probably more complex. You can't just drop some js script file in your HTML document and go with that.

I say that as someone who thinks React is the future of JavaScript development and there's no chance I will ever go back to separate templates so Angular of whatever version is just automatically disqualified. It would be like going back in time and I do not want to do this.

Yes you can! We are using requirejs, babel,es6 to have a react setup that runs completely in the browser. But for some reason, react makes this information really obscure.

It works really well. Including breakpoints in chrome,etc.

It might work for developing, but I don't think it works well for people actually using it, it's too slow.

which is actually my point - running it this way helps us do a lot of beta testing internally,etc. Obviously this is not a production strategy, but the way we have written code (with requirejs) is that we can switch between them.

I really hope that React makes this more public - it makes it for quick and dirty prototyping. P.S. love ES6. Performance be damned!!

Care to share your setup? I.e. minimal todo-like application with both direct development and with compilation for production site.

Give me a few hours, I'll strip some stuff out.

Don't spent to much time on it, because it will be deprecated in few years. :-)

>I think Angular is more accessible than React. I don't think React will be adopted as much by non-engineers.

Both are meant for engineers, if by that you mean developers.

For very small projects you can write react code in one or a few files without babel, webpack/browserify and similar tools. That closes the gap but I agree that angular is easier to just prototype something simple if you're not a developer.

Angular 2 also requires that level of tooling (both allow you to use ES5 and don't require tooling but most devs won't use them like that).

Angular is popular among developers who make products for the kind of person who would install the Alexa toolbar.

That comment reeks of sour grapes.

Similartech shows 13,390 websites using React and 248,280 websites using Angular

I'd love to see those numbers for Ember, Polymer, Backbone and Aurelia.

52,767 for Backbone and 599 for Ember. Datanyze don't appear to be tracking Polymer or Aurelia yet.

according to similartech 927 websites using Ember and 139,844 websites using Backbone

based on HN hiring posts, more companies ask for React than Angular experience. React growth in 2015 is absolutely stunning.


Is HN hiring posts REALLY representative of the industry as a whole? Seems more like the startup scene and often forgets about all the developers out there in corporations, agencies and other work that don't get represented here.

I can say that here in Denmark, the typical reaction to React will be "what is that?". On the other hand, Angular has the reassuring feeling of heavy corporate development which will make people earning their salary by working on management-sanctioned .NET technologies (that is, most developers) all warm and fuzzy.

I think, to a large extent, it depends on people's reaction to the word "framework".

Disclaimer: we switched to React at my company.

Usually startups pickup new tech and slow moving corporations follow later(whatever by buying these startups or by hiring ex-startup employees).

Here in Europe, I asked around to some firms like Aston Carter and Computerfutures recently. They had 0 requests from customers for React and A LOT for angular. Now these work mainly for enterprise companies which are hard to convince of a new technology. So all of these companies will transition much easier to angular 2 (just because they know the name 'angular') then to react.

As expected, since angular 1 came out much earlier, and have the same hype React has had for the last 2 years then.

But checking from HN, blog postings, job announcements, team posts, new turorials (video, books), etc, React seems to be winning now.

Yeah, the google trends don't seem to support that either:


One slight issue there is that React is much less frequently referred to as reactjs compared to Angular - even down to the official project URLs.

Obviously the Google trend search for "react" has lots of false positives, but some of the major news points it picked out include references to the right react.

Well React approach of composition has reach even others programming languages and communities and with things like redux and react-hot-loader is a game changer.

> things like redux and react-hot-loader is a game changer.

Totally not inspired by Elm and traditional FRP. I mean, I use it daily and it's great, but you have to realize that a lot of what React brings to the front is bundling some well-known paradigms together.

True, but in comparison to typical, common javascript development workflows (using tools like backbone and angular) - it is a game changer.

Really, React invented the idea of composition? Please, tell me more...

I never said that invented anything, just that its ideas have reached others communities (invented originally by it or not)

> ReactJS has slaughtered the front-end market share (in a good way)

No, it hasn't

> simplistic component based approach.


> Unlike React, Google does not really treat Angular as a first-class citizen because they have such split focus and conflicting React like library for web components called Polymer. They provide some resources, but nowhere near the amount of resources that Facebook throws behind React and React Native.

Facebook does one thing. Google does many things.

> ReactJS has slaughtered the front-end market share (in a good way) and completely taken developers by storm with its simplistic component based approach.

React has recently dominated headlines and in another few months, something else will. Meanwhile, people will keep using stuff from 3 years ago.

The comparison to React is unfair imo. Angular 1.x is being used very very widely across small and big shops. It just doesn't have the amount of hype React has. I really like what React offers as a new paradigm that leans towards component reusability, functional approaches and a cleaner data flow, but that doesn't mean this will be a solution for everyone. Angular 1.x and 2.x aren't heavy for nothing, it solves an additional set of problems that I think its worth checking out.

I'm not sure about the point about Angular being used far and wide-- it's true that angular has seen some decent adoption, but I also feel people are trying to move away from it ASAP.

For example, OkCupid (from what I've heard) based its mobile architecture on AngularJS, but then once React matured, they basically declared all their Angular legacy and promptly shifted to doing everything in React.

Even https://www.madewithangular.com/ doesn't make clear how AngularJS is being used in the few websites it showcases. Lyft uses it for its homepage, but it does not use it anywhere else. Likewise, one the homepage for healthcare.gov, one of the websites provided: does it use a lick of "ng-" anything in its HTML.

I don't disagree that Angular solves an additional set of problems, but I think the hype behind React is real, i.e. it's an actually good framework. Also, being an AngularJS developer myself, I too really dislike feeling that I've wasted my time learning yet another piece of tech that will be outmoded in the next year or so.

apart from a few projects that are experimenting with the latest stuff i have seen much more Angular being used in the wild than react in the last year. The project offers i got for react were more of the kind "we are experimenting with this for some small parts" while the big stuff was mostly built in Angular. Also React itself is pretty alpha and introduces breaking changes every now and then which makes it rather painful to update bigger projects.

Personally i love Typescript as well and i am pretty sure NG2 will get a lot of thrust behind it, now that the api is stable.

Angular 2 addresses a lot of the serious shortcomings in Angular 1.x. The Angular 2 approach to components and encapsulation feels cleaner and less complicated than the previous mess of services, factories, and directives.

Though initially skeptical of Typescript, I've found that Angular 2 really benefits from the advantages of having a coherent object model and optional type safety. Typescript never gets in the way, you can selectively use type declarations only where you want to use them. It's often helpful to leave them out while prototyping and then add them later when you want more robustness and easier debugging while you are working on writing the glue code and application logic that connects your various components.

As other posters have noted, you're still saddled with a lot of the artificial complexity and odd terminology that is pervasive in Angular 1.x. There are also bits and pieces of the library ecosystem, particularly the routing engine, that are over-engineered and painful to work with in practice. But, in general, I find version 2 much more intuitive and easier to reason about than version 1.x. Key features like data binding are much saner and behave more predictably.

I've never particularly liked Angular or React (my personal preference right now is for Vue or Polymer), but I think Angular 2 is a solid improvement over its predecessor. More significantly, I think the improvement is substantial enough to justify the team's decision to do a clean break.

I've just started working on an app using Angular 2 and Ionic 2.:

1. TypeScript - It's really nice to be able to use a typed version of JS, although it does feel like I'm writing C# sometimes! It supports lambda syntax / ES6 which is great.

2. Annotations seem a bit clunky, not really sure what the point of them is.

3. Absolutely love the functional reactive / RxJS stuff they've incorporated - it's going to make it VERY easy to write really powerful apps.

4. It's a million times easier to develop with than angular 1. $scope.apply anyone?

The RxJS support is definitely my favorite thing in Angular2. We have plans for all sorts of cool stuff built on top of Observables. Stay tuned.

Started to work on a frontend for realtime automotive networking systems in angular2. I used angular2 services which provide all (non-constant) state via Observables to the components - and I'm really pleased with the result. Totally reactive, and the implementation effort and complexity is relativly low.

> $scope.apply anyone?

...re typescript, i feel like if i'm gonna use a not-script of some sort, it might as well be clojurescript or something else that's like a really-srsly-not-js rather than js-but-prettier (coffee) or js-plus-a-paradigm-grab-bag (my totally uninformed take on type)

When people point out that Google is behind Angular, they fail to mention that the level of investment is nowhere near that of Facebook in React.

I've been loving using React. Building in components is fantastic, and it just feels like writing Javascript. That's a win in my books.

This is a pretty important point to consider.

If Google was as invested in Angular as Facebook was in React, they would probably have gone with a more gradual, methodical approach to improving the framework (like the Ember team did). And until that changes, there is very little stopping them from doing another mostly incompatible rewrite in a few years.

As it stands, Angular 2 is closer to a completely new framework roughly inspired by Angular 1.x than a new version of Angular.

This is a nice worldview but doesn't hold up to the evidence.

Google has said they have something like 10k Angular 1.x apps, so they will keep on working on Angular 1. Angular 2 happening along this support is showing that they're willing to invest in the conservative route and the "burn down the libraries" route at the same time.

By level of investment, both me and the OP meant in terms of products that are key to the company's operations, and need to be continuously supported and improved. Facebook is one such app for Facebook that uses React. Instagram is one such app for Facebook that also uses React. I honestly don't know any such app for Google that uses Angular. Until that changes, there is very little incentive for the Angular team to keep improving upon the existing solution instead of building something completely new with no regard for the people that depend on it.

The so called upgrade path they offer for Angular 1.x is a complete joke. That you can "mix Angular 2 into your existing Angular 1 application" would be a true statement with any component-oriented framework in place of Angular 2, like React, and Ember. And this was not true for Ember just a few months ago, which is living proof that gradual improvement can in fact be accomplished with any framework, but of course, throwing everything away is much easier, so the framework developers need to have strong incentives to not do so.

Google uses Angular in over 1000 internally and externally facing apps, including some on Angular2 already. They are also on the main trunk, and update on commit. The test suite for Angular at Google actually checks not only the Angular tests, but also all of the tests for all 1000+ apps at Google that use Angular, before allowing it to be deployed.

Angular 2 is the framework for Google's AdWords products. So it's core to how Google makes its money.

Also, the Google cloud platform dashboard.

Google is behind Angular, as are other large companies, but the product was made for 'Angular', an online JSON storage product by Brat Tech LLC, hosted at getangular.com. The company failed, but one of the people there got a job at Google.

The point is that - despite the common misconception - Angular isn't Google's Anointed JS Framework. There's a whole bunch of Polymer and a whole bunch of GWT inside Google.

I don't understand the point of this comment. Almost every new Google service I see is written in Angular. Why are we jumping on comparing it to React already?

Maybe let's withhold judgement until we actually use it. Just a thought.

I'm pretty sure Google has invested millions more into Angular & the ecosystem than Facebook has into React - they even have a CSM on the Angular team. Even internally the investment seems to be proving vast, as Google even has a production Angular 2 app already (during the painful alpha) & multiple teams publicly pledging to use it, which will probably grow as it becomes appropriate for Google to migrate products to Angular 2. Google has a rarified number of software products compared to Facebook - it's irrational to assume all of them will jump to their framework immediately, especially considering it was in heavy R&D the past two years & only now entering beta.

I assume he means investment as in how much they use the product. Their two top products, Facebook and Instagram heavily use React. A bunch of Google products do use Angular, but in no way are they the primary products and that probably lends to the less fluid progression.

Google AdWords is not primary enough?!

Google's Polymer [0] is probably closer to React than Angular. Angular's more of an application framework. Polymer's more of a Web Components[1] framework, which I think is closer to what React is doing.

[0]: https://www.polymer-project.org/1.0/ [1]: https://developer.mozilla.org/en-US/docs/Web/Web_Components

Long term I can see web components/polymer shims being preferred over React, but not till the major browsers catch up. Like the parent says, Facebook is deeply invested in making React work and it really shows. Angular/Polymer always seems more r&d/experimental to me, which is great but not for people who want to do production work.

it's not either/or

react.c : Activity/Fragment :: web component : View :: web : Android


All new Google's project I see use Angular. Fiber, StarWars, Cloud Platform.. all of them.

Sure but look at the critical, consumer facing stuff: gMail doesn't use Angular, FB does use React.

I'm pretty sure Doubleclick is far more 'critical' than gMail, from Google's perspective.

To be fair, ng1 wasn't good enough for such huge apps. NG2 is good enough - incredibly performant, with server-side rendering, with support of TypeScript (refactoring of huge amounts in code in IDE), with real components encapsulation and DI. And some ideas were inspired by React - such as reactive data flow ("one-way", as it called in docs).

So I think Google will do it. Google Fiber is ng2 already :)

They mentioned Adwords here, too. http://angularjs.blogspot.com/2015/11/highlights-from-angula...

I'd argue Adwords is one of the most important Google products.

Apples to Fruit Basket comparison. React is a strict view layer, though i've seen too many instances of people trying to make it a ubiquitous framework. Angular is far wider reaching library.

What exactly is your point here?

No, its not an apples to fruit basket comparison. When people talk about React they're not talking about only React, but more likely a front end app that implements React.

No one is saying "oh I love writing view layers. It's way better than actually building things".

I disagree. The distinction is worth pointing out, and he's right. Angular is more than just the view layer (directives). It provides the structure for the rest of your app. Other tech like Knockout.js is more comparable to React, as it's only solving the view layer problem.

If you're in New York, and you want to travel to London, you can either fly on a plane, or take a boat ride.

If I am trying to compare the pros and cons of flying vs sea travel, a distinction between the fact that a ship is not an airplane isn't really important.

Two vastly different approaches can attempt to solve the same problem, and they're worth considering on equal ground.

On a side note, when people mention working with React, it's safe to assume (if they're building real software) that they are using React with a framework, whether that be some implementation of Flux or Relay or something else entirely. When comparing Angular to React / Flux you've got yourself an apples to apples comparison.

Not really; a better analogy is if I'm in Kansas and I want to get to Beijing. I can fly all the way there, or I can take a car/plane/train to a boat to a car/plane/train.

Angular is the airline flight(s), React is the boat. It won't get you all the way there on its own.

I'm curious what Angular 2 is like for developers who normally write React? I hear 2 is a lot better than 1, but I'm still turned off by the amount of Angular-specific terminology, whereas most of React terminology is not necessarily React-specific.

Lets see what happens to react. I hear React is building in support for Relay, React Native, other facebook stuff. I <3 <3 <3 react, they have done an amazing job so far, as a React.js consultant and early adopter I owe my financial well-being to React, but big projects from big companies have weird incentives, Conway law, everything made by big companies inevitably goes to shit, yada yada. Maybe Relay ends up being not the best solution to the client/server query composition problem (IMO its not). Maybe people will get burned by 50-shades-of-flux (IMO the Great Flux Wars have barely started) and for the type of company that writes a ton of javascript, the framework pattern will come in vogue again (IMO). Maybe there will be an explosive patent lawsuit where Facebook decides to weaponize its "defensive" patents for whatever reason. I personally believe all of the things in this paragraph will happen in the near term.

Edit; Sorry i meant Conway's Law https://en.wikipedia.org/wiki/Conway%27s_law

In my mind at least, the so called Great Flux Wars have already been won by Redux.

I just finished my first non-trivial app built with Redux + ImmutableJS a few days ago, and it was pure bliss. Finally, we're able to build entire applications as a mapping of pure state transitions on top of immutable data in JS. Redux is by far the biggest reason why I haven't yet completely abandoned JS for ClojureScript.

Isn't Godwin's law that any online discussion will eventually lead to someone comparing something or someone to Nazi Germany if given enough time?

Yes, that's Godwin's. Not sure which "law" the original intended, but may be an example of Cunningham's Law.

[1] https://meta.wikimedia.org/wiki/Cunningham%27s_Law

Yes, it is; I'm not sure what comparison 'dustingetz was trying to make.

Never understood why people liked React so much. I don't know why, but mixing javascript and HTML just looks... gross.

I'm someone that initially hated the look of JSX (the html markup inside of Javascript thing).

But I've learned to like it. React encourages you to keep components very granular and small and so the amount of markup in each component doesn't really get in the way I find. I've also learned to appreciate how easy it is to reason about what React is going to spit out onto the page because the view is right next to the logic that dictates the various states of the view. Feels very concise.

I still don't like the idea of it, but in practice it works quite well.

..I feel the same way. I prefer creating dom with code syntax.

You can replace JSX by hand-coding with React classes - take a look at the compiled jsx and mimic that. I find it as easy to work with, and less cognitive dissonance [ a personal preference ]

I actually am looking seriously at Mithril in preference to React for my next chunk of work.

I might swing the other way if React native became stellar [ and viably crossplatform ]

It seems a bit of a Hobson's choice to me.

Q: which do you prefer - this:

  ReactDOM.render(<div><p>Hello World</p></div>)
or this?

    ReactDOM.render(React.createElement("div", null,
      React.createElement("p", null, "Hello World")
A: handlebars.

yeah, it is a bit unwieldy.. hence

A: mithril.js

> Never understood why people liked React so much. I don't know why, but mixing javascript and HTML just looks... gross.

But you never write HTML with JSX, that's the point. XML like syntax is just sugar that gets transformed into functions. This is not HTML. With angular you need to use string templates which cannot be easily validated by IDEs for instance. JSX syntax validation is straight forward because it's directly integrated in the language.

Mixing javascript into HTML is even worse. Think about it. That's angular.

Your end product has both HTML and JS so there's no way around mixing them somehow at some point. You could do it by keeping them separate and linking between them by means of CSS classes and magic strings in HTML templates. Or you can generate the HTML using JS functions. JSX just gives that latter option a pretty syntax.

If you don't like mixing logic into HTML you're free to create dumb components that only contain as much logic as you would want to put in a template. Such a component would accept properties and output a representation of the resulting HTML. A smarter component that does not generate HTML will provide the logic required for the template to function. That approach actually encouraged and is the right way to do React.

The bonus of this whole generate-HTML-representation-with-functions thing is that you pass around native JS values instead of stringified values and magic strings. Want to provide an onClick callback? Pass a callback. Not some magic string that represents a key which holds the callback in some object defined by framework-specific convention. No, you just pass a raw javascript function that will be run on click.

This might seem like a trivial distinction, but it's the difference between writing native JS vs writing magic framework code. I vastly prefer the former.

Which is why Angular mixes javascript into HTML. So much better. Right?

(at least 1.x did)

Thats the paradox you either go one way or the other. The problem with Javascript or something that turns into Javascript in HTML is it can inevitably lead to magic variables. I don't know how many times I have went in to support another developers angular code and found a variable who's origin can be traced to a scope variable which has been declared and initialized in an HTML file and all the sudden is magically being used halfway thru a routine. It's just shy of globals.

At the end of the day you go one way or the other, my preference is the template not having the ability to affect logic as it is not natural to look thru templates to find what is mutating the state of your application. I liked Dojo and I think react is a step back in that direction which in my personal opinion is the right direction for large web application.

You don't have to use JSX.

Then what do you use?

Just build the dom in JS, like so: React.createElement( string/ReactClass type, [object props], [children ...] )

I haven't used React in a while, so maybe this has changed, but can't you just do something like

    component = React.createFactory(MyReactComponentClass);
    component(props, children);

React providing a mustache-like format (like ractive.js uses) would be great - more familiar than JSX and less clumsy than createElement().

Edit response to person below (rate limit): there's no 'problem', just that mustache is still more familiar. Moving JSX into a different file doesn't change that.

JSX/createElement is not just syntax sugar though. It avoids the whole step of parsing the template. Because JSX is JS code, you can pass native JS values to it including callbacks. Whereas anything you could pass to mustache-style templates will be stringified.

So for example in case of parsed templates, to pass a callback to onClick you'd need to define a convention on how you're going to locate the callback by a given string (since you can't pass the function itself, you need to pass some "name" of that function). Whatever logic that will be, the result will not feel like React anymore because you're back to typical framework-specific template magic instead of using plain JS.

> to pass a callback to onClick

Putting behaviour in HTML is a bad idea. Leave it in JS, and have one place to go when the behaviour changes.

> Putting behaviour in HTML is a bad idea

This is not what I'm doing. JSX is JS. I'm not putting any logic "in HTML". If I were able to express what I'm doing in mustache-style syntax, it would be:

    Blah blah <a onclick="{{ callback }}">Click me</a> Blah
Where `callback` is a reference to a JS function (rather than a string holding it's name).

What's your ideal way of registering an onclick callback?

The moustache you're demonstrating there has the same problem. Add event listeners in JavaScript, not in moustache / jsx / whatever.

So, once again, JSX is JS. You're free to write the exact same thing without XML syntax. If you don't like that either, then what you're really saying is "Don't generate HTML using JS". Why not? The benefits are obvious:

* With React & ESLint you get basic checks to make sure you're not passing non-existent variables

* Your IDE understands what you're doing and lets you jump to callback definitions

* You understand what you're doing because you have one obvious place where you do templating and data binding.

* Your actual behaviour logic is still separated from your template, living in some other JS file.

On the other hand, if you add event listeners to HTML from JS the classic way, you get other problems:

* You're querying the DOM tree by CSS classes or some custom attributes. It's surely a familiar way of doing things, but also fragile and unintuitive.

* It requires your JS to know the structure of your DOM to some extent, and that structure is defined elsewhere. So it's basically the same problem as with mustache templates – passing around magic strings – but the other way around.

* Neither ESLint nor IDE will help you do it.

You could just put your JSX in a separate file and import it. "Problem" solved.

Yep, that's available and supported by a large company here: http://wix.github.io/react-templates/

We write our react components using coffeescript, it actually works pretty well.

Yes you do. Come on now.

Mixing of logic and presentation is bad for application, but so don't use <font> tag in your code, because it will be hard for _designer_ to change appearance of hardcoded page.

React mixes logic and structure, which causes no harm, because both are written and maintained by same developer.

I know. But PHP took off because they were mixing code and HTML, not despite of it. Same same, but different, I guess.

Me too. Impression, admittedly only from reading about it and looking at a few code samples, is that Angular 2 is over engineered and complected, as is 1.x, which I have worked in daily for over a year. ReactJs is much more appealing these days.

I've used and followed Angular 2 somewhat over the past year. My take is that React is better for engineers familiar with JavaScript, while Angular may be more comfortable for engineers with a preference for Java/C#. I don't mean that in a bad way; it's simply been my experience that people coming from those languages love what they see of Angular 2, and are repelled by React.

It's not hard to see why. This code[0] from Angular 2 would just be a function in React:

      name: 'tempConvert'
    // The work of the pipe is handled in the tranform method with our pipe's class
    class TempConvertPipe implements PipeTransform {
      transform(value: number, args: any[]) {
        if(value && !isNaN(value) && args[0] === 'celsius') {
          var temp = (value - 32) * 5/9;
          var places = args[1];
          return temp.toFixed(places) + ' C';       
There's also the fact that Angular is a framework, whereas React is a library. Those of us in JS land typically (but not always) prefer smaller libraries.

[0] https://auth0.com/blog/2015/09/03/angular2-series-working-wi...

let's be fair, Pipes can do a little bit more then pure functions. E.g. the async pipe which lets someone directly use Observables in the view is really helpful. And a simple function in combination with Observable.map() or Promise.then() won't bringt that functionality to React (you need to write lifecycle hooks or mixins, and in the end it would look similar to your construct.

I wonder what you guys would think of this:


It was built with concepts from Angular 1 and React in mind. But it doesn't use either.

Especially this: http://qbix.com/platform/guide/tools#dom

Here is an example app built on it: https://github.com/EGreg/Overlay/blob/master/web/js/Overlay....

I've spent a lot of time with Angular 2 (alpha)[0] and React (redux flavored).

All in all it is fairly similar, and feels pretty good. You have to remember more syntax, because of the configuration, but it isn't as conceptually difficult as Angular 1.x

The templating syntax is "weird", and it definitely adds to the list of things you have to know specific to Angular 2.

React and JSX is nice because logic is just JS, and not special template syntax (directives).

I'd be happy to build an app with Angular 2 or React for different reasons. What's hard is looking at Angular 1 now.

[0] I've given multiple Angular 2 workshops, built large scale Angular 1 apps, and build React components daily for my business (a popular web developer video tutorial site).

We use Angular 1.4 at work, but your reasons are exactly why I'd prefer React. It is mostly just Javascript without a lot of Angular specific conventions. At least Angular 2 looks nearly as good as React and work is planning on upgrading.

One of core Angular 2 things is ReactiveX :) https://github.com/ReactiveX/RxJS

I am in Germany and this link forces a redirect to angularjs.blogspot.de because of my location (which is a version of the blog in German, which I don't read).

No simple way around this, and no link I can see to go to .com instead. That's quite frustrating.

I wonder, does the .co.uk one also redirect to .de? You might find that as an already-"localised" one it doesn't redirect?


Yeah good point!

(Edit) No actually I spoke to soon. Even when the url doesn't redirect, the blog post is still in German for me! (Edit again) Must have been cached, it's in English now.

Try using this url instead: http://angularjs.blogspot.com/ncr

ncr = No Country Redirect

Previously used by google.com too, seems to be ignored now.


I am in Germany as well, and it redirects me to blogspot.de but the actual content is in english.

same for me

Try http://angularjs.blogspot.de/?hl=en

If that doesn't work, try a private tab so that it doesn't use any previously-set cookies:

Firefox: ctrl-shift-p

Chrome: ctrl-shift-n

I'm a C# developer. I have been patiently waiting for angular 2.0 with the hopes of switching my stack to TS.Node + Angular and I'm really excited about trying this!

I'm very impressed with the power Visual Studio Code offers for developing JS/TS projects. Do you do all of your development in the .NET flavour of Visual Studio?

I really wanted to start using ts in my next React app but did not find any good resources and couldn't get it off the floor. Happen to have any insight on that?

I've been working on a TS/React/Redux app for the last couple of months, trying to make use of the "latest and greatest" tools and best practices, and hope to write up a blog post over Christmas describing my experience (overall very positive) and how to set it all up, so I will be sure to post it to HN when it is done.

This would be amazing, I hope I catch it. What's your blog's url just in case?

I don't have one yet, this will be the inaugural post! But I am on twitter @tomduncalf, so if you want you can follow me and I will tweet you when it's out. This is good, it puts pressure on me to actually write it ;)

Done, pressure is on!

This happened to me. When TS came out with JSX support I immediately forked our NG 1.4 project and tried to start a port. I barely got Visual Studio working with the React TS code and quickly ran out of steam. Looks like I'll need an external build step because I could never get Visual Studio to build the React app into a single app.js file.

Yeah, sad really. It almost seems like Visual Studio Code is getting better support for it, which from the point of a paying VS user feels a bit off, I now switch between two editors to develop one app (VS and Atom), but would love to do everything in VS. Ah well, we'll probably need to wait.

Yeah gotta love the intellisense, I plan on continuing doing so until there's a better alternative.

What will be your build workflow for TS.Node? I've never really found something that works well.

I had a really painful time trying to contribute to the angular 2 project. I get the impression that the developers actively working on this are working with discussion mostly internal to Google.

It's a shame, because it does seem like both a very powerful and nice approach to building SPAs that I would love to contribute to.

@estsauver while I agree that it takes some time to get into contributing into a big project like Angular 2, it is simply not true that it is "Google only" project. I'm a regular contributor (#6 in terms of no of commits: https://github.com/angular/angular/graphs/contributors) and I don't work for Google.

Angular team is bunch of great people, real pleasure to work with. I can tell you - the initial effort to start contributing pays off _very_ fast.

The only person that actually ever replied to me on Gitter was Raganwald.

Maybe I just had an experience of trying to get help at a series of slow times, but it was really hard to get help with the build setup.

Welcome to chat, https://gitter.im/angular/angular, we often talk here with ng-team members and developers who use ng2 for their projects (like me).

Curious: could you describe why it was difficult to contribute?

Can't you just fork the project and work on your own from there?

How many Angular folks are sticking with native ES6 and babel vs TypeScript? Angular is clearly directing folks to TypeScript. I don't want to have to use TypeScript on front-end and ES6 + Babel in Node. Trying to pick one.

I've been using TypeScript for a few months now and have been so impressed with it that I am beginning to favor Angular 2 over React just because of Angular 2's TS integration.

TypeScript basically made JavaScript more powerful and a whole lot more fun for me. I feel so much better about slinging around parameters now that I know my IDE will catch type/parameter mismatches before I run the code, before I build it, even before I save the file! It simply alerts me in the IDE (I use VSCode which I also love). This is a huge time saver.

Another great thing is the intellisense, which allows me to keep on coding without looking at some API documentation or other files in the project. The intellisense even has the documentation in it - so this is a really fun and efficient way to learn new libraries and frameworks.

I didn't even know how much I missed enums in JavaScript until I started using them in TS. Also love the fact that you can revert to using the Any type if you have to and there is even support for generics as well.

All of this stuff can be had in various transpilers or IDEs, but TypeScript and VSCode just bring everything together in a very simple yet powerful way.

Welcome to the programming world, js developers.

I never jumped on the CoffeeScript bandwagon .. I know people love it, just not me. Hence unlikely I will try TypeScript.

Despite all its glaring flaws, javascript is an insanely productive language due to excellent mix of features. To improve upon that Id need to go to lisp / clojure [ but it lacks wide commercial acceptance .. not a criticism at all ]

I'm actually wary of using the newer additions to javascript language - ES6, Promises and arrow notation don't seem that much of a win to me, I'm very sceptical of new being good in language design...

whereas I really love Ramda.js as a general underscore / lodash replacement.

Productivity seems more a function of how we structure our code [ eg. keep state so we can jump back into where we were in the web app, thus iterate easily - as per the Om approach ] and thinking functionally.. rather than language syntax additions.

I don't see the need for an IDE .. they tend to come into their own when Your.ColourfulAndCompleteMethodNames are so long they need auto-completion. Thats the beauty of javascript [ and lisp etc ] we should fight to keep things small and terse.

I don't want to argue on your other points but imo the part of auto-complete that saves typing time is the least important thing in a IDE. The really useful part of auto-completion is actually exploring unfamiliar APIs.

no! :) static errors analyzing is more important - saves much, much more time.

Of course that's he best part of the IDE, i was only commenting the autocompleting part.

Es6 has destructuring and tail calls, too.

I also like cljs, mostly in a text editor.

Code quality it is the ultimate time saver. I prefer reading concise, literate source to exploring/churning APIs.

> I've been using TypeScript for a few months now and have been so impressed with it that I am beginning to favor Angular 2 over React just because of Angular 2's TS integration.

As a big fan of types myself, I hear you. Have you tried using flow with react? I wonder how they compare.

I can't tell you anything about flow (no experience and no interest), but I have no played a little bit with React & Typescript as well as Angular 2 & Typscript. Imho both configurations work quite good:

What I liked about React is that I also got type checks in JSX (compiler tells me if the types that I assign to props are correct). I don't get that kind of type checks for angular2 templates. If I assign something wrong there then it blows up at runtime.

What I disliked about React is that the ecosystem doesn't embrace typescript. For most 3rd party components that I tried there were either no type definitions available or they were broken (which is often worse - because then you can't assign props that are actually valid).

For Angular2 at least the framework is already typescript-first (so we have automatically up-to-date type definitions through the compiler), and I would hope many 3rd libraries follow that design.

It is a shame that so few React-based libraries are on DefinitelyTyped. As the project I've been building had quite a short timeline, I've just been creating "any" type definitions for libraries which don't have definitions (in an ideal world, I'd like to create and share a proper definition), which works but you lose type safety and auto-complete for these libraries. Not the end of the world but it allows more runtime errors to creep in.

On the Flow vs Typescript thing, I evaluated both for this project, and almost went with Flow primarily because at the time, I liked that Flow felt lighter weight (it is truly "opt in" unlike TS, and getting the TS setup right was quite hard work), and I was also put off by the overhead of having to write .d.ts files (now I can create an "any" definition for a library in a few seconds, but at the time found it all quite time consuming).

However, I persevered with Typescript in the end, as I felt that some of the features it offered over Flow were worth the extra effort - specifically, the editor/IDE support (Atom with Nuclide for Flow was really unstable for me and the autocomplete still didn't compare to TS) and the fact that Typescript does a full compile of your code, so will pick up on things like mis-spelled imports, which Flow didn't seem to.

Also, I found documentation for Flow (beyond the basics) to be quite lacking, and there didn't seem to be as much community around it - for example, I just couldn't work out how to get it to check React propTypes, which was a pretty important feature for me. Bit of a shame, as its type system actually seems more fully featured than Typescript's (e.g. types are non-nullable by default), but TS's type system is certainly good enough.

I'd say go Typescript at the minute if it's a reasonably large greenfield project, but Flow might suit your needs if it's something smaller (whether that's in amount of code or in team size), or if you prefer the lighter touch/opt-in approach - for example, if you want to introduce it to an existing JS code base. I would definitely say it is worth the effort to go with one or the other, I'm not looking forward to going back to writing plain JS - having the compile stage makes refactoring in particular trivial, without the overhead of having to write loads of unit tests. In TS I'll refactor constantly as I go whereas in a large JS app, it's tempting to put off refactoring as you might miss somewhere and not know until it is QA tested (or the customer spots it is broken...).

TypeScript, all the way. I work with it professionally and I couldn't be happier, especially in comparison to CoffeeScript.

I used to love CoffeeScript but, after giving ES6 (with eslint) a shot, it no longer has a special place in my heart.

I do enjoy the terseness of it (writing it is fun) but some things are just painful (reading it after the fact).

As for TS vs ES6+ -- I would go with TS but only because Angular projects have a tendency to become very large, and having a compile-time type system hold your team's hand is very comforting.

I'm using TypeScript with NodeJS. It gave me enormous power. I stopped writing half of my tests and I hardly see runtime errors anymore.

TypeScript is doing really good.

With Ionic 2, we're giving people Babel + ES6+ for our starter projects, with the option to enable typescript. I agree with you that typescript should "enhance" an app, but not dictate it from the start. We're giving people the option and will see how that goes.

I'm finding it very difficult due to the sheer number of choices. Angular 2 supports ES5, ES6, TypeScript, and Dart. It's hard enough evaluating what our upgrade path will be from Angular 1.x, let alone which language we should end up using.

I kind of have a feeling that by the time we actually need (and have the resources) to upgrade or even start mixing in Angular 2 on our project, native browser support for ES6 will be close enough to complete that we won't need a transpilation step. That might be a nice time to do the migration.

Looking forward to hearing what other devs end up using.

A lot of Angular 2 is optimized around using Typescript. A lot of the heavily-used Typescript features (eg. annotations) are on track for ES7, but not part of ES6.

We've been using TypeScript with Angular 1 projects for almost a year now and have really been enjoying it. Having it integrated directly into the framework is a great improvement for my team, at least.

When using Typescript with Angular 1 where you able to make use of TS types and type checking?

Want to give this a try :-)


Yes. You just include a "type definition file" for Angular in your project. There is a very large existing repository of type definitions for popular JS libraries in the DefinitelyTyped project.


TypeScript is fully compatible with ES6 as far as I know, so if you want to start using it either on the client side or on the server side, you can start doing that whenever you like (provided you don't mind changing file extensions, etc.)

That's a negative, it is the reverse -- MS has always maintained that TS will be a superset of ES and that they are completely open to porting TS features over to ES.

As I understand it they have most of their docs written for TypeScript but they plan to fully support ES6 and have the docs to show how to use ES6 too. I would prefer ES6, however it appears that TypeScript is a bit less verbose to write.

The big difference between TS and ES6 is dependency injection. Types can be resolved through TS types while you need to use decorators with ES6.

The problem I have with decorators is that they are not officially part of ES7 spec yet, even if there is a big chance they end up in the final spec, features like ES6 modules are a proof that things can be reworked to death before being standardized.

From my understanding the two aren't mutually exclusive. From example, couldn't you use ES6 decorators and typescript in the same project?

TyoeScript supports decorators with the --enableExperimentalDecorators flag.

ES6 does to if you use Traceur/Babel + config flag.

Video of the team announcing the Beta release. https://www.youtube.com/watch?v=WitNPCLSZr0

Anyone has the experience working with NativeScript and Angular 2? How's it compared with React Native? And is there any chance this will evolve to a viable alternative to developing native apps using web technology?

Jen from Telerik DevRel here...we are working with Google to ensure that Angular 2 works great for your NativeScript apps. Please check our blogs at nativescript.org for forthcoming info on performance comparisons and how-tos. I'd encourage you to visit our getting started guide on the above web site to see how you like NativeScript!

> Angular 2 works great for your NativeScript app

How is it going to work exactly ?

Great. It's right there in the sentence you quoted.

Great doesn't the describe the WAY it is supposed to work. I asked HOW like IN WHICH WAY.

Angular2's architecture is split in such a way that the rendering layer is separated from the application code. This allows swapping out the render layer - enables stuff like NativeScript and React Native renderers, server-side universal and running your app in a web-worker, dispatching to the main thread to render.

As a plugin for the NativeScript runtime. Check this video from Angular Connect which goes over exactly how it works. https://www.youtube.com/watch?v=4SbiiyRSIwo

How is NativeScript related to AngularJS ? is it the same team ?

No, NativeScript is a Telerik product. Angular is a Google/ Open Source project. I'm not sure how they are related, I haven't seen anyone use the two in conjunction.

There are some samples available, for instance this one: https://github.com/NativeScript/sample-ng-todomvc

Angular 2 render engine allows it to be used for the server-side rendering or in NativeScript environment.

Looks promising... But personally I dislike TS., and I know that it not required for Angular 2..., Now I prefer ES6 + babel, maybe in future I'll change my attitude to TS.

As somebody deciding between ES6 + Babel and TS for a project...What don't you like?

The incremental upgrade path is disappointing.

Step 1: Include the Angular 2 and ng-upgrade libraries with your existing application

Is anyone with a serious application actually considering this? It would have been nice to include only the pieces of Angular 2 that you actually use. Instead, we have to ship both libraries, our application code and an additional plugin down the wire? I don't see this upgrade path as a legitimate option for anyone who cares about page load times.

There is also ngForward, which is Angular 1 with Angular 2 syntax.

Excited to finally start playing around with this.

I recommend Angular CLI for new users: https://github.com/angular/angular-cli

It is based on ember CLI and helps a lot scaffolding new projects.

The only thing I haven't really seen on their 'Quick Start' and 'Guides' site is any examples that show retrieving data from an API. Are those out there and I didn't see them?

There's an optional Http client that uses RxJS Observables - see http://plnkr.co/edit/UQJpd5dA6x45T4PPZRWW for a basic demo that also uses the `async` pipe to subscribe from the view. Of course, the native fetch API works fine too.

or a bit more interesting reactive demo searching YouTube http://plnkr.co/edit/SelQZh?p=preview

I've played around with Angular 2 quite a bit the last few weeks. These are my (early) views for anyone interested:

* Templating syntax is intuitive after an hour or two

* Decorators are great! (sidenote: Warning Babel6 decided to remove them until the spec settles down)

* Typescript I'm undecided about. Its a bit of a pain to work with and tooling is still early days e.g. if you want to import a single js file/lib, you create a Type definition file (.tds) just for that. And if you don't want to document every interface in that .tds, then you can give it an "Ambient" aka "whatevs" definition. But in that case it will not be retain its semantics.

* The new component router wasn't ready for prime time 2 weeks ago. I doubt that has changed. And frankly, I feel a bit uncomfortable with how magical it is. That could change though, I know allot of effort is going into it.

* One of the best things is losing many of the hacky artifacts of Angular1 (pseudo-modules system, 9 types of component, config phases etc etc)

* IMHO the lack of opinion built into the framework will still cause allot of foot-shooting around the globe, especially compared to Ember or Aurelia.

That said, if I was going to start a large enterprise project right now, I'd SERIOUSLY consider the core being written in Angular 2 + Redux. I'd have to revisit Ember before I had that decision though, its been over two years ...

This looks pretty cool. I've just been learning about Angular 1, so I guess the thing to do is start using Angular 2 as soon as it's available and not bother with the ngForward tool?

I'm looking for tools that will help me create web apps with rich client experiences. I've read the critiques of AngularJS here and it sounds like it does have some limitations, but still a very good framework for corporate web apps with moderate user base and small # of browsers.

I use both react and angular. At work we lean toward angular because of the overhead of having to train design teams with no real JavaScript backgrounds how to work with jsx.

That being said, I use both react and angular. Angular is a full library that solves all of my problems, even if the solution isn't what I would consider ideal. React forces me to do a lot more work to get something running as it is not a framework. It is a tradeoff of time versus flexibility.

Anyone have an upgrade plan for 1.x?

I work on a rather large Angular 1.4 codebase daily and while this is good news, I'm not sure how we'd ever upgrade to be honest.

there's a very nice strategy for this - the upgrade module allows you to run ng2 components inside of ng1 apps (or vice-versa) so you can incrementally upgrade.

There's a great blog post by the Thoughtram team here : http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-...

Resources for learning Angular2?

[Shameless plug]: I've been writing a book on Angular 2 over the past few months: ng-book 2 [1]. If you want to write your first app, you can get the first chapter of our book for free.

You can of course learn Angular 2 from lots of disparate blogs on the internet. There's lots of good resources. But the goal of our book is that you'll be able to learn everything, in-order, in one place.

We've been keeping the book updated alongside Angular's development (though it will take us a few days to get up to the most recent beta). We've already updated the book over a dozen times, so I think you'll really like it.

[1]: https://www.ng-book.com/2/

I had a positive experience with ng-book for ng1. Although I've only read about half, I found it very useful.

I haven't started using ng2 yet, but if I do decide to learn it i'll be purchasing ng-book 2.

ng-book is one of the most in-depth resources that I recommend to those who want to get into angular development. I can't quite say the same for ng-book 2, as I have not yet read it, but it's definitely worth spending money on, especially when you get the updated versions on digital copy.

egghead.io could be worth checking out...

They seem well prepared for the demand in Angular2 training :


We had a look at Angular 2 at Pusher since a lot of our customers are using Angular to build app. If you want to check out a quick tutorial and see some actual working angular 2 code in action , you can go to https://blog.pusher.com/real-time-apps-angular-2/

Angular size really impressive:

angular2.min.js - 568K

Version 1.4.*

angular.min.js - 148K

File size really increased (Angular1 * 4 == Angular2), if compared with first version. Something went wrong.

It is beta still - this bundles the test utils and a bunch of other stuff that will be split off closer to RC/main release time.

As pointed out in the blog post shaving off bytes is one of the priorities before 1.0 release. We've got many tricks to play here, so expect those numbers to be much lower in the final release.

Shaving? Not enough. They need a serious regiment of diet and exercise.

What about the other dependencies?

Angular 1 is a fully fledged framework, you can use it on it's own, but 2 seems to depend on rxjs, and it's also bigger.

To me that seems like a step backwards.

Unless it has been cached (from visiting other sites), this is terrible first time user experience for those with slow connection.

Not sure why all the down votes?!

Server side rendering is mentioned in the post - for me, angular 1.x was a dead end because it did not run on the server (disregarding the confusion around services, factories etc, and all the horror in templating logic, debugging it etc) - can anyone give some insights into what this is like?

I've previously written & been part of teams for a few non-trivial 'full stack' js apps that run both on the client and server, and react's abstraction from the DOM is perfect for such things. Wondering what the 2.x approach is here.

As an aside, seems to me that the days of running JS purely in the client are coming to an end, for projects when developers can have a free hand on the tech stack.

For those of you who are using Dart, https://github.com/ng2-dart-samples has many Angular 2 demos and samples and it's pretty nice ;-)

Angular2 wants dependency injection and for that to work well it needs named interfaces and thus ends up with TypeScript as its first citizen language.

This is fair choice but it shows the background of the designers of Angular and that they in some sense really don't grok JavaScript.

Here is a blog from mr. Ruby-on-Rails explaining why DI is a stranger in the Ruby world:


With some parallels I think.

I'm rarely happy about DI containers, but why wouldn't you want inversion of control in Javascript? We've seen how the "let's just monkey-patch because software design is hard" approach works out: it doesn't.

Trying to find info on their packaging story. Last I heard the official tooling seemed to be moving off systemjs+jspm in favour of WebPack, but I don't see any clear info on this; does anyone know?

We've started experimenting with systemjs and really like it (though support is a bit limited right now, plus it not really liking PhantomJS/karma), and we want to modernize our Angular 1.x app packaging/loading/bundling, but don't really want to do needless work if we have to move to another solution for Angular 2.x.

We're playing with all manner of tooling here. Our CLI (broccoli based), Webpack, SystemJS / JSPM, Rollup, etc - we'll also be focusing on HTTP/2 as we move forward.

HTTP/2 in what sense?

AIUI, with HTTP/2's multiplexing requests over a single TCP connection, the need for bundling resources might just disappear completely.

Angular 2 is late to the party. The user base of Angular 1.x has already moved on.

I wish the success of a web framework was a bit more about the technology nature of it rather than the market adoption and hype.

I'm not sure if that's entirely accurate

Here's a chart where you can see daily download counts for react, angular, and angular2.


React does indeed have about 4x as many daily downloads, but (Angular 1 + 2)'s download counts are ~5x what they were a year ago. (iirc the ng-europe RIP Angular fiasco happened in October 2014)

I feel like many angular users are using bower and react is more likely to be used in a npm context.

Worth noting that the onboarding process for each framework is different. Getting started with react pushes you to npm. Angular 1 pushes you to CDN, so I'm not sure how useful this graph is. Interesting, nonetheless.

That's a great point. I wonder if that would change with Angular 2

I feel people using Angular 2 are people migrating from 1.x so not quite sure if is a correct estimation adding the two values. At the same times, my comment, is based on my gut feelings, nowhere close to a reliable source :)

Any suggestions for a good material UI framework that works well with Angular 2? Unfortunately, angular's material framework only works on 1.x so far.

Maybe I'm reading wrong, but Rx.js seems to be 70k minified. Seems like a giant dependency for a mobile-focused framework...

The whole angular.io documentation is telling me "well f*ck you vanilla JS user, go learn TypeScript and come back"

Well, the angular 2 beta release blog mentions that these the docs for es5/es6 are still in the works...

New Project - Angular2 OR React and why?

I probably will get down-voted seeing all pro-Google comments but what I don't like about frameworks like Angular is that it obfuscates HTML...

Uh did Angular not get the memo that people hate the new syntax and typescript?

This is how you turn the most popular javascript MVC framework to nothing.

From what I've seen, there are a lot of vocal proponents of Typescript, but not many vocal detractors. Which of those is the actual majority is hard to day.

I have a theory that many of the people who like Typescript came from a statically-typed background (Java, C#, etc) and don't like the loosely-typed world of Javascript.

More speculation: People who came to front-end development by choice are happier with Javascript than those who were transplanted from the server side and forced to convert to the One Language Of Browsers (ignoring transpilers, of course).

Don't forget people who came from desktop ui or game development and have had code completion and navigation for years and can't handle the slowness and unreliability of navigating and developing a js codebase.

People hate typescript? I think the opposite. Typescript gets more and more traction.

You also don't need to use typescript with angular 2.

If only typescript was written by facebook or google then people wouldn't hate it.

Flow was written by Facebook, yet TypeScript seems markedly more popular and well-liked. There are some who hate TypeScript because MS, and there are some who hate Flow (and React) because FB. But most of the criticism against TS has, anecdotally, been technical in nature.

Edit: by popular I didn't mean that it's merely used by more people. I've clarified that.

I'm not talking about popularity. I'm talking about indiscriminate hate because it's connected with microsoft. C# has suffered the same stigma since the beginning.

People hate Dart, written by Google, for same reason: it is better to stick to single language, for better ecosystem, than to fragment it. I, personally, just ignoring Dart, CoffeeScript, TypeScript, etc. Life is short.

We're stuck with javascript due to historical reasons, not because it's any good. I think that treating it as a bytecode, binaries, etc.. is the way to go. I.e. javascript (preferably fast subset of it) will be produced by proper tools and you'd never have to look at it again. Fragmentation is only natural.

So these languages exist precisely because life is short. Are they the perfect/stable solution? Probably not. But it's the right way to go.

We're stuck with javascript because it is good enough, so switching to an another language, e.g. Dart or VBScript, are not worth effort and consequences. JS even used at backend side. IMHO, it is better to invest into JS than to fight with it.

Wow, from +8 to -2, a lot of downvoting on this comment.

All I know is when the first angular 2.0 beta came out, it was not well received by anyone including myself because of the vast difference in syntax (simple -> complex) which is the only reason I and a lot of others picked Angular in the first place. It seems it has been tweeked a lot since then, but those problems have not been fixed. I don't think next version of angular is usable for me.

Typescript's audience is far less than Angular's audience, there should be no reason to use typescript as the official example. This kind of bundling is similar to Microsoft explorer coming with Windows.

I really love the new component creation syntax(API) and Typescript gradual typing is super useful. I can see Angular 2 being use even more than Angular 1 in the near future...

You can write your Angular 2 application code in ES5, ES6, TypeScript, Dart, or to-JS languages like CoffeeScript.

TypeScript is pretty popular and it does work really well. Writing larger applications in a team is much easier if there is tooling to assist you. With most projects, about 80% of the work is maintenance and tooling does immensely help with that.

Typescript is very popular from what I read here and there.

Angular 2, on the other hand, has so far been received very coolly.

I know typescript isn't required, I'm not sure about the new syntax tho.

The syntax is much better now. It is easier to understand and allows better tooling.

Seems like you don't understand the difference between MVVM and MVC. Also everyone I've encountered that has used typescript loves it.

Google has wanted to turn JS into a static language for ages. Now they have enough fanboys to help make real progress in that direction.


Applications are open for YC Summer 2019

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