robwormald

Ugh. Thanks for the kind words :)

Angular core team here - unfortunately, this post ignores Angular 2+ entirely (its @angular/core on npm) - the numbers are only for AngularJS (1.x). We’ve reached out to the NPM team to get this corrected.

See https://npm-stat.com/charts.html?package=%40angular%2Fcore&p...

I did the Mars demo at a conference a while back - the first couple of minutes I was underwhelmed, but at some point, my brain "bought-in" - I noticed this when I crouched down to look under a virtual rock outcropping without a second thought.

Note this chart is actually showing AngularJS (1.x) only. NPM only started exposing stats for @scoped packages recently, so @angular/core (Angular 2+) only has a few months of history.

See https://npm-stat.com/charts.html?package=react&package=vue&p...

You'll be pleased to know that we're making Zones optional pretty soon here. This would mean taking control of change detection yourself, of course, but there's plenty of valid use cases where that's a reasonable idea.

FWIW, Angular's release cycle is roughly based on the same cadence as React :)

Angular core team here, we're restructuring some of our docs at the moment and this is super useful feedback. Thanks!

It's unlikely we'll ever have developers write Custom Elements directly - that said, the View Engine rewrite we just did gives us the ability to (theoretically) have our compiler output Custom Elements. We're investigating some use cases on this.

This is what the AngularJS versioning scheme was, nearly exactly. Everybody hated it. Hence, semver :)

1) the core of Angular Universal "graduated" into @angular/platform-server with 4.0 - previously it was a more experimental project. We're officially supporting a "renderToString()" API that can be used however you like.

So really, it's brand new, and we're excited to see what the community does with it.

Philosophically, pre-rendering every SPA server side isn't a silver bullet. For a ton of cases it makes a lot of sense, but we want to avoid the impression that we're positioning SSR as a replacement for making your app fast.

2) The expectation of the Material Components Web project is that everything be "wrapped" for the specific framework. Angular Material is native Angular, and we have a team dedicated to that. Polymer has a material suite as well, and most of those components can work in Angular apps too. Components for everyone!

2a) you're asking a Googler that question. We have like, 11 messaging apps. I don't know what to tell you.

3) CLI went stable today, with its 1.0 release. We'll be moving the docs over to use the CLI everywhere soon - personally, i'd use the CLI to generate a new project and then follow along the tutorials.

absolutely. we're 100% invested in Rx, and more than anything else I'd like to see the Observable type standardized.

You can already use most simple web components in Angular without issues - as far as Angular is concerned, it's just another DOM element.

We also support native (or emulated) Shadow DOM out of the box.

It gets a little more interesting when you start interleaving Angular and WebComponents, but one of the deprecations in 4.0 (regarding Angular's use of the <template> tag) is squarely aimed at making that easier in the future.

This is good to know, cheers!

The first two are pretty well covered by our friends at Ionic and NativeScript.

The last one, well, that's a bit more complicated. Let's just say that sort of thing is on the radar.

New release of CLI is running final checks in CI. Should release momentarily!

Edit: it's released! npm install @angular/cli

We've got some really cool ideas to make Rx really first class in Angular. It's already pretty deeply integrated, but with a little work, it'll be awesome.

you'll find that generally, we refer to it as "Angular" or "Angular 4.0" - officially, AngularJS is 1.x.

We'll see how it shakes out, but so far our community has been pretty awesome about it.

Most developers should be able to simply update their dependencies and rebuild. A few APIs have been deprecated, but they continue to exist and can be removed at a developer's leisure, per our versioning policy [0]

http://angularjs.blogspot.com/2016/10/versioning-and-releasi...

That's discussed in the doc (and there's some metrics). Update speed takes a (minimal) performance hit, in exchange for code size reductions.

We (and our colleagues at Google working on the web in general) find that the largest impact on performance comes from simply shipping less code.

Edit: correction: turns out our tests show we didn't take a perf hit on updates at all, and in fact ever-so-slightly improved. So win win :D

Major release every 6 months, 2 major version deprecation policy.

There was definitely some initial pushback, but we hope to demonstrate with this release that it's a) not that scary and b) good for both developers and users.

Most devs should see significant reduction (upwards of 50%) in their output builds. We think that's a reasonable trade off for a couple hours of work to upgrade.

In this release, most developers should be able to simply update their dependencies and rebuild. We're aiming for regular, planned, minimal changes, rather than Big Bang style change from AngularJS -> Angular.

Angular core team here, we're pretty excited about this release.

Main change, as noted, is the new View Engine. The design doc[0] is worth a read if you're interested in front-end at all.

Happy to answer any questions!

[0] https://docs.google.com/document/d/195L4WaDSoI_kkW094LlShH6g...

i tried the Walk On Mars hololens demo at a conference last year. It seemed very clunky at first, but a couple of minutes into the demo, I entirely unconsciously crouched down to look under a virtual rock outcropping - that was the point I knew my brain had bought it.

That's stuck with me. There's something there.

You might be looking for Smart Folders - https://support.apple.com/kb/PH22188?locale=en_US

You might find https://developers.google.com/web/updates/2015/12/background... interesting?

the other thing to note is that a lot of new APIs (and older ones which are being updated) require HTTPS - geolocation, webBT, webUSB, service workers, etc, all require HTTPS (or will, soon).

https://developers.google.com/web/updates/2015/07/interact-w... is a good primer on the API, and a links to security explainer: https://medium.com/@jyasskin/the-web-bluetooth-security-mode...

ng core team here, feel free to reach out to me on twitter if you need any help getting this done - @robwormald

ngrx creator (and ng core team member) here - you'd be surprised at the uptake on ngrx/redux in enterprise I think - a lot of the constraints / guarantees redux offers are really attractive to big teams, and pretty much every big enterprise team I've spoken to in the past few months are using or at least investigating using it.

Angular core team member here, let me see if I can clarify some of our decisions here:

It's not a secret that we promote Typescript as the first choice for Angular2 - this is a conscious decision based on both technical reasoning as well as feedback from our developer community.

I can count on one hand the number of teams I've spoken to who really want to use ES6 - the vast majority are happy using Typescript.

Typescript also allows us to do the kind of static analysis we use to do ahead-of-time template compilation, something that is significantly more difficult with ES5/6 - we've discussed making this work in the future, but for now it's a lot of engineering investment for something there just isn't the demand for.

A couple of other things I want to mention - "enterprise" gets thrown around on HN sometimes as a bit of a dirty word. We don't see it like that at all - the vast majority of Angular 1 users are exactly enterprise, and we're solving for the problems that large teams like them run into.

Now we're released and stable, I think it's a reasonable ask to add some specific docs on ES6 usage (or at least where it differs from TS), I'll bring it up at the next docs meeting.

Anecdotally, my experience talking to outside teams tells me that TS is not the complexity problem people have - the vast majority of devs coming from ES5-land have trouble with ES modules and bundling, rather than the specifics of ES/TS itself - this is part of the reason we're working hard on the angular-CLI.

As far as Google/Angular's commitment to the outside world - we have a Developer Relations team (of which I'm at member) - our only job is making non-Google developers successful with Angular. Feel free to reach out to me (@robwormald) or @stephenfluin if you've got questions or concerns. We both come from "enterprise" webdev and a big part of our job is making sure outside developers are represented in eng-team decision making.

Also reach out if this is something you care about deeply and want to contribute to the documentation - we'd love your help and I'll put you in touch with the right people.

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.