
Angular 2 docs for ES6/7 - valera_rozuvan
https://github.com/angular/angular/issues/7600
======
DigitalSea
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.

~~~
ascorbic
> 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.

~~~
Oletros
That quote is talking about documentation, not about coding

~~~
ascorbic
Which is what this story is about. You're welcome to use ES6 and transpile it.
They just don't provide docs.

------
anupshinde
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

~~~
mrspeaker
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.

------
SamUK96
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.

However...

Routing in AngularJS 2.

It is bad.

Very bad.

~~~
ralfn
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.)

~~~
spdionis
By 'dynamically typed and functional' I think he meant javascript.

Personally i wouldn't call javascript functional but...

~~~
SamUK96
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.

~~~
spdionis
Are you confusing functional programming with procedural programming?

------
ungzd
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).

~~~
kitsune_
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.

~~~
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.

------
stpapa
I don't see a problem here, we've know Typescript is core here from the
beginning.

~~~
NicoJuicy
I agree

------
nmdanny
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.

~~~
pluma
Strictly speaking, TypeScript isn't a sound type system:
[https://www.typescriptlang.org/docs/handbook/type-
compatibil...](https://www.typescriptlang.org/docs/handbook/type-
compatibility.html)

------
chad-autry
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.

You can see my beta NG2+vailla JS project here [https://github.com/chad-
autry/ng2bp](https://github.com/chad-autry/ng2bp)

------
valera_rozuvan
For those of you who are saying that TypeScript is a superset of ES6. Stop!
ES6 does not have decorators. See [https://github.com/tc39/proposal-
decorators](https://github.com/tc39/proposal-decorators) .

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...](https://github.com/loganfsmyth/babel-plugin-
transform-decorators-legacy) . The legacy plugin adds syntactic sugar on top
of ES6. This is no better than TypeScript in the first place.

------
douche
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.

~~~
wiredearp
I am sure that the clientside developers in your company will come to realize
their mistake when they see your interfaces and level of tooling.

~~~
douche
The willfull resistance to embrace practices that make development easier,
more efficient, and safer is baffling.

~~~
shados
then just get the logical conclusion and use ReasonML/Elm/PureScript/whatever
for the frontend instead.

Oh, you meant easier/more efficient/safer but only within the comfort
zone...makes sense.

~~~
douche
Baby steps, baby steps. It's a process.

------
robwormald
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.

------
49531
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. ¯\\_(ツ)_/¯

------
valera_rozuvan
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](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.

------
aichi
ES6 is next version of ES5 so whatever works for ES5 should work for ES6, no
need for special DOC for that.

~~~
VeejayRampay
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.

------
squeral
It's not a big deal. If you're using ES6 then TypeScript should be
straightforward.

------
bricss
That's duck _

~~~
pluma
I'm not sure what's going on, but the reply link on your comment appears in
italics.

Is this a formatting bug or some new HN thing I'm not aware of?

EDIT: I guess formatting bug. The comment ends with a trailing <i> in the DOM
inspector.

