It's the attitude of the Angular 2 team that makes me glad I decided to choose Aurelia instead. Nobody seems to realise that Angular 2 exists first and foremost to meet the needs of Google's internal Green Tea team and not the public.
This is just one of many things that should make people think twice about using Angular 2. The fact the team seemingly take input from a select handful of "Google experts" to guide the framework should be an alarm bell in itself. NG2 is a monolithic and over-engineered framework backed by a company who have proven they conflict with themselves (Polymer) and deprecate popular services on a whim (Google Reader).
I personally use TypeScript in my Aurelia applications, but I think you should allow developers to write using straight-up Javascript. We're getting to the point (or if you're writing evergreen focused web applications, you're there now) where we will be able to write Javascript without a transpiler soon (for most things).
I love TypeScript, but we can't forget what it's a subset of and some have the view that Javascript doesn't need types or interfaces.
Angular 2 strikes me as a manifestation of the inevitable tendency of all perfectly good frameworks to, just as they reach a likeable maturity, suddenly explode into a morbidly obese, suffocatingly bureaucratic J2EE-type Mother of All Frameworks, because merely working well and serving a purpose just isn't good enough.
> NG2 is a monolithic and over-engineered framework backed by a company who have proven they conflict with themselves (Polymer) and deprecate popular services on a whim (Google Reader).
It's a tiny bit of a stretch to call it a whine, but it's old when it's brought up constantly, tbh.
>Nobody seems to realise that Angular 2 exists first and foremost to meet the needs of Google's internal Green Tea team and not the public.
Isn't Google using Dart internally ? From what I've seen all their NG2 projects use the Dart version and their Material design component lib is Dart ?
So if what you were saying was true they would dump the TS/JS version and migrate the team to work on the Dart version 100% and not maintain two separate code bases (like they are now after the Dart/TS source split) and wouldn't even bother with the Material design for TS ?
Honestly I'm not even sure why Google is spending all this effort on the ng2 TS/JS as what I said above would make more business sense - I doubt that ng2 is making them any money if they aren't using it (I'm talking about the TS version).
Dart team member here. Google is using Dart heavily internally. Many, many significant apps (think Adwords, Adsense, Google Fiber, and a pile more) are shipping on AngularDart 2.0 today.
It's not accurate to say that AngularDart exists first and foremost to meet the needs of one internal team - it exists to provide a great framework for apps of this type (significant, complex web apps).
We think we're making pretty awesome progress here - we've been able to dramatically increase velocity since the source split (a couple of months ago), and have made really large improvements already in application performance and in shrinking the size of the compiled JS for AngularDart apps.
I was just saying if OP criticism about Google only caring about internal use was true Angular Dart would be the only ng2 supported by Google, not suggesting that's being developed for Google only, I'm actually a fan of both Dart and AngularDart so gj from me :)
While I'm not using TypeScript in my Aurelia application yet, I'm thinking about using it at least partially in the future. I also agree about the risk of Google not committing to Angular users. In response to that, the makers of Aurelia have asserted time and time again that they are trying to have a very different mindset and wholeheartedly cater to their users.
So I never heard of Aurelia, but now I've watched their video and explored the website. Looks cool, but... Google:Angular :: BlueSpire:Aurelia, no? So I'm betting on a small company surviving, vs Google at a whim killing off a thing they probably won't kill off unless they make a whole new v3 that is not related to v2 ?
Good point. Rob, the creator of Aurelia, left the Angular team after he decided that Angular 2 was not following standards to his liking. He has pointed out repeatedly on the blog and in interviews that Google is not committed to Angular in the sense that many companies commit to their products, whereas Blue Spire's business model is 100% dedicated to supporting Aurelia and nothing else. Google does not make money from Angular, a lot of internal stuff (most internal stuff?) at Google is not built with Angular, and Google could drop support for Angular at any time.
> I think you should allow developers to write using straight-up Javascript.
They do, just not ES6. "The examples of the docs are planned to be written in TS, ES5 and Dart". I tend to agree with their argument that if you're using ES6, why not just use TS.
After switching to TypeScript, I am not sure whether I will ever go back to JavaScript (after so many years of using JS). I don't use or like Angular2 - but I use React with TypeScript.
Even if we could use ES6 JavaScript in the browser, transpilation isn't going away completely because we need HTML, uglification, vendor-libs, etc to be brought in together before deploying to production.
WARNING: If you are starting off with React+Typescript, expect to bang your head for may be, a couple of days, to get that stuff working. However, once it does work, it saves much more time and effort
If you're going React I suggest starting out with (or at least checking out) Flow over Typescript. It's well integrated with the React ecosystem and has type soundness as a goal.
I've been learning AngularJS 2 for around 2 weeks now, and I see why they push use of Typescript. They always have. AngularJS 2 was designed from the start to be typed. To be object-orientated. At the least be object-inspired. It makes sense to be consistent. Using a non-typed and functional-structured language for a typed and object-orientated framework is pretty dumb in my eyes.
To digress a little, AngularJS 2 has been awesome, and at times can be simpler than React. The .js and .js.map file bulk with every .ts file is stupid though.
In your logic you equate statically typed and object oriented vs dynamically typed and functional.
Object oriented programming is by origin (Smalltalk) dynamically typed. Class based programming languages (which we really shouldnt consider typical for oop) tend to borrow all their modern type features from functional programming languages. (Think polymorphism, generics, interfaces, etc.)
> In your logic you equate statically typed and object oriented vs dynamically typed and functional.
Yes. JavaScript's structure is usually heavily functional and can often be non-modular. Typescript goes away from this somewhat with the construction of objects.
> Object oriented programming is by origin (Smalltalk) dynamically typed.
Really? Object orientation is all about forming your own types, so how could OOP have an origin in dynamic types?
I dunno, i've talked to and seen the code of a few JS devs and they all code very function-based (i.e. little modularity, poorly refactor-able, flow is difficult to understand, <insert another consequence of functional programming>)
Maybe that's just anecdotal though, since I know that JS supports some form of OOP.
I'm curious what you don't like about the Angular2 router. Since router 3.0 (agreed there were some false starts) I've found it to be a pleasure to work with.
I think that there's way too much bloat/boilerplate code for the simplest of auth-based routing system. Auth service, auth-guard service, routing service, etc..
Not sure if I'm just bad though, I suppose i'll keep on trying.
Have you tried ui-router for angularjs 2? Just curious.
Routing and E2E testing are my biggest concerns for transitioning our 1.x app to Angular2 -- and I haven't had time to really dig into either in detail.
Hmm, no, I haven't. I'm trying to learn the standard routing library for AJS2. It's very bulky and boilerplate-ish which I don't like.
The amount of code and files you need for a very basic login-auth feature for a page is extremely large.
I feel like, after 2 weeks, AJS2 is built for large websites for huge companies, and pointlessly complex and boilerplatey for small websites like a forum, blog, simple store/story site, etc.. I think that if you want to make hundreds of pages, AJS2 or something is your bet, but for a little thing, go with PHP 7.
Another sign that it's designed for enterprise Java camp: old Angular was very popular in such shops because of IoC and service factories. Now it requires java-like language on top of javascript, with type system designed primarily for autocomplete in IDE to work (even unlike Java in which type system is primarily intended to make runtime do less computations).
The angular core team from Google even has technical PM that handles business relationships. I've recently been to AngularConnect in London - from what I've gathered their future focus is also very much about ease of use. They try to establish angular-cli as the de facto toolchain by incorporating best practices from the community, similar to ember-cli. There are a lot of nice features with the new compiler infrastructure (AOT with lazy loading support from the router) and types obviously help here.
As a counter point, with ngrx/store being so popular in Angular2 land I doubt Angular2 is as friendly to the Enterprise as you make it sound. On top of Redux you have Rx, many people will have a hard time wrapping their heads around this.
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.
That's a common misconception about the JVM. Although the language features allow type-erasure, the JVM actually stores the types with the data and uses tracing for optimization. This keeps the compiler output smaller and allows classes to be compiled independently.
The operators are converted to methods, however methods are 'looked-up' at run-time. Not in a hash-table though, think C++ style vtables. So int + float isn't compiled to int.addFloat( float ) but to int.add( float ) and then uses polymorphism at run-time.
If you do try to eliminate all of this work at run-time, by creating type-specialized versions of every method, you have the problem that code that tries to narrow a type by either casting, or doing an instance-of check on a supertype (like Object) needs special treatment.
All these choices were made long before they implemented 'generics', so most code was doing manual narrowing and casting all over the place, including the standard API's. Type-erasure would not actually improve the performance by much since it could hardly be used.
They solved the performance problem, without actually considering the type system. Your code runs just as fast, as if you used the Object type everywhere, and just cast on the fly to what you expect it to be. Which would be equivalent to a dynamically typed language.
Typescript is a superset of ES6 anyway, proper JS documentation(e.g MDN) does have the notion of types anyway, but basing the documentation on TS means that the types are sound and consistent along the library.
To me, many of the comments seem to have it backwards.
ES6 is a superset for ES5, so given the ES5 docs you can write NG2 apps with ES6.
Typescript being a superset of ES6 means it would be a struggle to write an NG2 app in ES5 or ES6 given only the Typescript documentation. I tried during beta, it was an exercise in frustration that I finally abandoned.
Providing documentation for the lowest common denominator of ES5 should let you write in ES6 (heck, it should let you write in Typescript if you realyl wanted to!) But some of the dev's comments are a bit backwards IMO when they say use Typescript documentation for ES6.
Almost all Angular2 projects, that claim to be using ES6, are in fact using ES6 + Babel Legacy Decorator plugin https://github.com/loganfsmyth/babel-plugin-transform-decora... . The legacy plugin adds syntactic sugar on top of ES6. This is no better than TypeScript in the first place.
I say good. One of the next tasks I'm going to take, as soon as I get some free time, is to integrate TypeScript into our front-end and start adding in interfaces and parameter types. I'm usually working on the back-end, but get drafted into the UI-side once in a while. The number of stupid little errors caused by typos or not having decent intellisense is troubling. Compared to the level of tooling and safety I'm used to on the back-end, it feels like banging rocks together.
Especially when we've got a gulp build process that takes long enough to run that I want to start some XKCD chair-jousting matches between edits.
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.
I wonder why; it seems weird to insist your users either use TypeScript or mentally translate it to es6. I would think allowing community members to write es6 docs would be a good way to get more involvement. ¯\_(ツ)_/¯
I am a strong believer in Angular (1 & 2) and in JavaScript. I am using Ng1 & Ng2 on production. I even have a seed project for Ng2 that uses pure ES6 (no legacy Babel plugins). See https://github.com/valera-rozuvan/angular2-es6-seed .
I know how much it hurts when you can't find decent documentation for Ng2 with ES6.
I would think that ES6 offers more affordances in the ways you can express ideas in code. The new docs would probably offer slightly different examples taking advantages of those affordances.
This is just one of many things that should make people think twice about using Angular 2. The fact the team seemingly take input from a select handful of "Google experts" to guide the framework should be an alarm bell in itself. NG2 is a monolithic and over-engineered framework backed by a company who have proven they conflict with themselves (Polymer) and deprecate popular services on a whim (Google Reader).
I personally use TypeScript in my Aurelia applications, but I think you should allow developers to write using straight-up Javascript. We're getting to the point (or if you're writing evergreen focused web applications, you're there now) where we will be able to write Javascript without a transpiler soon (for most things).
I love TypeScript, but we can't forget what it's a subset of and some have the view that Javascript doesn't need types or interfaces.