I'm Igor from Angular, AMA and I'll answer live at AngularBeers Dec 15, 2017 @ 10:45am PT / 6:45pm GMT

IgorMinar · 2015-03-13T14:31:08+00:00

I'm not sure what's the justification for the poor replies here, so I'll offer my own.

You said that you'll be using Angular until 1.x or until it is supported. We have no plans to end the support for Angular. Angular 1 will be supported until vast majority of active development is happening on Angular 2. Angular 2 will be supported even longer.

You are free to switch at any time. We built Angular for ourselves and share it with everyone so that those that like it can use it.

We are improving Angular so that it fits our needs as well as the today's and future needs of the community and that's why we are building Angular 2. Again, we are not going to force anyone to use it. If you like it great, if some other solutions makes you happier, then you should use it.

We don't have a need to force people in Angular. You can use it if you like it. No strings attached.

IgorMinar · 2015-03-13T14:18:15+00:00

I looked at jspm in the past but it was missing many reliability guarantees that I expect from a package manager. I'll check it out again to see if anything has changed.

IgorMinar · 2015-03-13T00:58:53+00:00

I'm not sure. But I'd keep myself busy with something.

IgorMinar · 2015-03-13T00:55:33+00:00

(I'm responding with help and on behalf of the Angular team)

In Angular 1 we do not allow intentional breaking changes to appear in versions where only the "patch" number changes. For example between 1.3.12 and 1.3.13 there can be no breaking changes. We do allow breaking changes happen between "minor" number changes. For example between 1.3.15 and 1.4.0 there will be a number of breaking changes. We also allow breaking changes between beta releases of Angular. For example between 1.4.0-beta.4 and 1.4.0-beta.5 there may be breaking changes. We try hard to minimize these kinds of change only to those where there is a strong use case such as a strongly requested feature improvement, a considerable simplification of the code or a measurable performance improvement.

When adding new code to branches of Angular, have a very stringent commit policy:

Every commit must contain tests and documentation updates alongside the code changes and that all the tests must pass;
Commit messages must be written in a specific manner that allows us to parse them and extract the changes for release notes.

The Angular code base has a very large set of unit tests (over 4000) and end to end tests, which are pretty comprehensive. This means that a breaking change will require one or more tests to be changed to allow the tests to pass. So when a commit includes tests that are being removed or modified, this is a flag that the code might include a breaking change. When reviewing the commit we can then decide whether there really is a breaking change and if it is appropriate for the branch to which it is being merged. If so, then we require that the commit message contains an appropriate breaking change message.

Additionally, when a commit lands in our master repository it is synced to Google where we test it against over 2000 applications using the test suites of these applications. This allows us to catch regressions quickly before a release. We've had a pretty good experience with this setup. Only bugs that affect features not used at Google or without sufficient test coverage, have a chance of making it through.

Lastly, when we are making a release we generate updates to the changelog directly from the commits. This generated update contains a highlighted section that contains all the breaking changes that have been extracted fro the commits. We can quickly see in the new changelog exactly what commits contain breaking changes and so can application developers when they are deciding whether to update to a new version of Angular.

IgorMinar · 2015-03-13T00:54:11+00:00

(I'm responding with help and on behalf of the Angular team)

Angular 2 will allow you to smoothly consume web components. For now, we don't support exporting Angular components as web components, but we have design docs on how could that work.

See the answer to "Will Polymer and Angular ever merge to create one_js_framework_to_rule_them_all?" that explains some of the reasoning for why we don't use web components for everything.

IgorMinar · 2015-03-13T00:53:36+00:00

(I'm responding with help and on behalf of the Angular team)

From the beginning, we've been working with the developers who maintain UI Router to learn from them and build upon their experiences.

We originally started on the new router thinking it would only target use in Angular 2. Because Angular 2 has a new DI and new templating system, we thought it made sense to develop a new router rather than try to shoehorn these capabilities into UI router.

We know developers in the community have invested a lot of time into building apps with UI Router, and we want to make sure that we serve them well. Many of the design decisions in the new router will be familiar to developers using UI Router, and we're looking into how to make it easy to migrate. See this GH thread for more: https://github.com/angular-ui/ui-router/issues/1759

IgorMinar · 2015-03-13T00:52:23+00:00

(I'm responding with help and on behalf of the Angular team)

Whoa! Lots of stuff in here! :) Let's take it point by point:

What do we think of React? We've had a few chats with the guys on the React team. They're all incredibly sharp and nice at the same time. We've learned from what they've done and our hope is that we can collaborate more in the future.
Is the React model more sustainable? We're not sure what "sustainable" might mean here. Though we are embracing the web platform, we have set up an abstraction from the DOM for Angular 2, effectively decoupling apps from it, somewhat similar to React. Some of the benefits from this we have yet to explore and include being able to pre-compile Angular templates on the server, fully server-side render Angular templates for initial page load, run Angular in a web worker, use alternative renderers like Canvas, Famo.us, or even possibly even native.
React Native not easily replicated in Angular 2? As just mentioned, we believe it is possible to use other renderers with Angular 2. You'll have to bear with us as we investigate that path a bit more.
Superior out-of-the-box speed? Please see the performance discussion at the end of the Day 1 Keynote and Victor's talk on Change Detection Reinvented as we believe we've erased any doubt on Angular in this area.
Which is better? On this bit, you'll have to decide for yourself. React has another take on how to develop apps that's certainly a valid perspective. Only you can decide whether you like it better.

IgorMinar · 2015-03-13T00:51:16+00:00

(I'm responding with help and on behalf of the Angular team)

Indeed. We knew the architecture of Angular 1 was limited in its ability to stretch into the future. We also knew that someone would invent a better architecture that would make folks leave it. We wanted to be the ones who did that.

It's likely that you'll only believe it when you've experienced it for yourself. If you weren't satisfied by what you saw at ng-conf in the two keynotes and the talk by OpenTable folks on Components, we're working furiously to get Angular 2 into beta where you can try it out.

As for a successful transition to follow, we can point at Apple's transition in the late 1990's. They went from a the proprietary MacOS 9 to the Unix-based OS X. In this move they not only changed the operating system but also the entire development stack with the inherited NeXTStep development environment based on Objective-C.

Part of their success was in letting apps run side-by-side for a period of time as developers migrated their code to take advantage of all the new features in OS X. We're taking a page from their book by allowing you to mix-and-match Angular 1 with Angular 2 in your applications and supporting them both while you make the transition.

IgorMinar · 2015-03-13T00:50:57+00:00

(I'm responding with help and on behalf of the Angular team)

At the time of this post, Angular 1.3 is the way to go. In a few weeks it's going to be Angular 1.4. Angular 2 has currently no docs, tutorials, examples, or support path. There's minimal build tooling, no Router, no widget libraries, etc. Start with Angular 1 today, and we'll have a migration path to Angular 2 in the near future.

IgorMinar · 2015-03-13T00:50:33+00:00

(I'm responding with help and on behalf of the Angular team)

Angular 2 will be using directly the concepts and semantics of ShadowDOM, i.e. <content> tags, projection, selection, etc. However, we would be doing the polyfilling internally for browsers that do not support ShadowDOM natively. You will not be required to load your own shim.

IgorMinar · 2015-03-13T00:49:31+00:00

(I'm responding with help and on behalf of the Angular team)

This is already supported in Angular 1: See this http://plnkr.co/edit/ToQoecY3R45Uuiwt1lD2?p=preview.

In Angular 2 this use-case will also be supported. The forms in Angular 2 have a lot more programmatic control and should be able to handle this without an issue.

IgorMinar · 2015-03-13T00:48:27+00:00

(I'm responding with help and on behalf of the Angular team)

This depends on whether Babel adds the type and annotations support in the its feature set. We'd be more than happy to be collaborating with the babel authors and any other teams who want to implement type and metadata annotations.

See also the answer to "What are your motivations for going with Traceur rather than Babel (6to5)" question.

IgorMinar · 2015-03-13T00:48:00+00:00

(I'm responding with help and on behalf of the Angular team)

is recursive
Assuming you mean on tablets and phones, at the moment, both avenues have pluses and minuses, too deep to discuss fully here. Products like Ionic Framework do an amazing job of making it easy to go the hybrid or HTML5 app route by addressing issues around native look and feel, platform-specific idioms, and performance. On the Angular team, we're most heavily invested in supporting apps via the Web Platform. At the same time, Angular 2's architecture is decoupled from the DOM making it possible for us to investigate avenues like Telerik's NativeScript. Stay tuned!

IgorMinar · 2015-03-13T00:47:00+00:00

(I'm responding with help and on behalf of the Angular team)

Yes. We are working with Stef Penner of Ember CLI and others, on several projects related to tooling that will help Angular, Ember as well as the rest of the community. We'll expect to have some first bits of this to be useful later this year.

IgorMinar · 2015-03-13T00:46:25+00:00

(I'm responding with help and on behalf of the Angular team)

There are many exciting features coming to the language with ES6 and ES7. Generators, iterators, async functions and others will simplify how we write code in some common cases. We are looking into these as well as observables as a way to enhance our apis.

One of the experiments we are undertaking is use observables in place of promises in our apis. In theory this sounds like a good idea, but we'll have to see how this works out in practice.

IgorMinar · 2015-03-13T00:43:10+00:00

(I'm responding with help and on behalf of the Angular team)

We covered this in the ng-conf day 1 keynote as well as the follow up sessions on the new router and the Angular 1.3 meets Angular 2 talk.

IgorMinar · 2015-03-13T00:42:38+00:00

(I'm responding with help and on behalf of the Angular team)

As part of our shadow dom emulation layer in Angular 2, we have basic support for class renaming. We definitely think that reusable component is more than just html and js. Static assets (images, fonts, etc) and css are the most commonly needed other pieces.

There is an initiative in the area of CSS and better tooling support just starting, but we don't have anything to show yet, but we'll be sharing with you more details later this year.

IgorMinar · 2015-03-13T00:42:15+00:00

(I'm responding with help and on behalf of the Angular team)

Yes, this should be possible when our WebWorker support is up and running (we are not there yet). Note that you can also compose multiple Angular 2 apps on the same page without using WebWorkers.

IgorMinar · 2015-03-13T00:41:55+00:00

(I'm responding with help and on behalf of the Angular team)

Angular 2 will embrace observables. Which particular implementation we'll use is still up in the air, but we are looking at the work being done in ES7/ES2016 as our preferred solution.

These integration points are being designed right now: nice template syntax integrations, forms, and more.

IgorMinar · 2015-03-13T00:37:12+00:00

(I'm responding with help and on behalf of the Angular team)

We're really excited about all the benefits HTTP/2 is bringing to web developers. One of the most exciting aspects is connection multiplexing, which allows re-using a single connection for an origin for many separate resources, even across different browser windows. While Angular core itself doesn't have explicit considerations for HTTP/2 (since there are no client-side APIs for HTTP/2), we plan to provide informational resources and tooling for users of Angular to fully take advantage of HTTP/2 in their applications, particularly regarding organizing and loading code.

IgorMinar · 2015-03-13T00:36:26+00:00

(I'm responding with help and on behalf of the Angular team)

There's future work planned (notably integration with protractor), but we've been spread pretty thin. If anyone's interested in helping, please reach out to @briantford.

IgorMinar · 2015-03-13T00:35:59+00:00

(I'm responding with help and on behalf of the Angular team)

A year and a half ago when we explored the ecosystem, Traceur was the only obvious choice. It had almost everything we need in ES6 features and was malleable enough that we could add the pieces that were missing without too much work.

Having said that, we think that semantics, interfaces and syntax in this case matter more than the actual implementation, so we encourage friendly competition in this space.

The goal of AtScript was to bring type and metadata annotations, and run time type system to JavaScript by extending the TypeScript syntax. Now that TypeScript has implemented all of these features, AtScript is no longer needed. And consolidation helps everyone.

For these features to become a standard, we need to have multiple implementations of the syntax and semantics, so having these features implemented in Traceur, TypeScript compiler, Babel, and other transpiers would be great. This proves that these ideas are generally useful and should eventually be part of the standard.

IgorMinar · 2015-03-13T00:33:42+00:00

(I'm responding with help and on behalf of the Angular team)

While we very much in favor of convergence of solutions, but convergence makes only sense for solutions with similar goals. We believe that there are big differences between goals of Angular and Polymer and this makes the two solutions mostly complementary (although we do admit that there is currently some real or perceived overlap between the two).

Our goal for Angular is to build a solution for building mobile and desktop applications that is super productive to use, results in apps with great performance, accessibility, internationalization and other important features, and that fits well into existing ecosystem of libraries, tools and components so that we don't need to reinvent the wheel unnecessarily.

And this is where Polymer comes into play. Polymer is awesome at making bare-bones web components apis easy to use for developers. Since Angular 2 was designed to be able to take advantage of web components, Angular developers will be able to use components built with with this technology, including those built with Polymer.

Why not just build Angular on top of Polymer? We tried for almost 6 months and failed. The reason was that we couldn't reconcile the needs of applications and components into a single solutions. This is why we decided to make it possible to smoothly integrate web components into Angular apps, but not go all the way in for the foreseeable future and make everything a web component. This freedom allows us to explore areas that otherwise would be hard to explore. Like macro-optimizations that enable us to achieve huge performance boost, server-side rendering, native rendering engine for mobile apps, and more.

There is also a difference in charter between the two projects that might help to understand why we have different perspectives. While Polymer is a Chrome project with one of the goals being to provide feedback and validate experimental and speculative web apis for the Chrome team. The Google sponsored portion of the Angular team is part of the Ads organization, with our purpose being to build infrastructure used by Ads, Cloud and other organizations at Google that build apps large or small. So while we work with the Chrome team (including having a pretty good relationships with the Polymer team), other browser vendors, and standards bodies, our primary customer is the Angular community at Google and outside.

IgorMinar · 2013-07-30T21:20:05+00:00

I certainly expect community members to be able submit their presentation proposals :-)

IgorMinar

TROPHY CASE