
Version 6 of Angular Now Available - gldalmaso
https://blog.angular.io/version-6-of-angular-now-available-cc56b0efa7a4
======
alceta
I was joyfully expecting this upgrade and checked the release notes daily
during the RC phase. Don't let the quick 'major' version changes shock you,
upgrading 4 -> 5 was easy and I expect the same for this upgrade.

A big thanks to everyone involved in shaping this release and ensuring the
upgradability for the past major versions, including the huge effort in making
it possible to continuously migrate from AngularJS. <3

If you care for the details behind my experiences:

We have begun migrating a ~80k loc AngularJS codebase first to TypeScript in
2016, which was the preparation for the Angular upgrade starting Q1 this year.
Now we are roughly 80% migrated to Angular 5 (in the meantime we did the
upgrade from 4 to 5 in a few hours thanks to
[https://update.angular.io/](https://update.angular.io/)), the rest running
with ui-router hybrid [1] and ngUpgrade [2] and now are looking forward to
moving the rest to Angular and upgrading to 6.0.

Coming from AngularJS where many things are done without a proper reason, I
have started to embrace and even somewhat love Angular for the niceties it
brings it. When you already embraced TypeScript, it is a breeze to work with
and I cannot recommend it enough (for large-scale frontends this is).

The one pitfall I always ended up with during the migration was that AngularJS
attribute directives cannot be converted to Angular and then downgraded (In
the hybrid app, the entry component is always(?) AngularJS and up from there),
which is a large part of the remaining AngularJS code. There are a few
workarounds but they did not seem to work properly. If anyone has suggestions
on that part.

[1] [https://github.com/ui-router/angular-hybrid](https://github.com/ui-
router/angular-hybrid) [2]
[https://angular.io/guide/upgrade](https://angular.io/guide/upgrade)

~~~
tzipp
How about the story on mobile? Is there an Angular analog to React Native?

~~~
zzbzq
Called NativeScript. I can't vouch for it quality or support.

~~~
tzipp
That's what I'm wondering. I can see a lot of material vouching for the
quality of React Native, but I see very little consistently coming out for the
Angular competitors in the mobile sphere.

For what it's worth, I really like Angular for web development, but I don't
know much about the mobile side of things yet. I've just started to look into
it.

------
InTheArena
This upgrade looks absolutely fantastic. The Elements piece in particular
looks amazing, and has the potential to be a real game changer for shops that
have a diverse set of applications that they use, and need large scale re-use
of components.

At the mid-size corporation that I work at, we just standardized all
Javascript development on Angular from a mismash of a ton of technologies.
Angular seems very well suited for this role.

There was a interesting statistic recently that showed that Angular was
dominating "east coast" applications (traditional financial services, pharma,
insurance, manufacturing, established CS) while React was most popular in
"west coast" applications - primarily silicon valley, etc.

I'm glad these two technologies are here to push each other.

~~~
zygimantasdev
>At the mid-size corporation that I work at, we just standardized all
Javascript development on Angular from a mismash of a ton of technologies.
Angular seems very well suited for this role.

In my experience centralisation and fixation on specific technology leads to
stagnation quickly. IMO you should allow teams to choose their own tools. How
else will you improve?

~~~
lopatin
To quote one of Akin's laws which were on HN yesterday, "better is the enemy
of good".

It's really good when one technology is used throughout an organization to
achieve the same purpose. At some point, the technology you use is actually
good enough, and incremental improvements to "keep up with the times" are
simply distractions from the real work. And if at some point you find that
your tech has truly stagnated, at least you're stagnated together, and can
modernize together at the same time.

~~~
zygimantasdev
The problem is how will you find that your tech has stagnated? If nobody
experiments with new tech - who will teach others? How will that knowledge
come into your corp? Hiring new people to do that will not work, because: \-
People being hired will be evaluated by legacy people (different thinking will
be considered disadvantage during interviews) \- Legacy people will not listen
to new hires since they have no credibility and it "has been the way it was
always done"

~~~
lopatin
These are solvable problems. Just because a group of engineers agree on a
standard tool, doesn't mean that they are blind to the world around them, or
that they are now doomed to be single minded "legacy" people. I'm sorry if in
your experience this hasn't been the case. Maintaining a balance between using
modern technology and having a healthy "if it ain't broke, don't fix it"
attitude is certainly do-able.

But when every team is doing it's own version of the same thing, that's
another story. It can be crushing to productivity, in fact it's likely to be
the deciding factor if some types work get done at all. And, unlike your
concerns about preventing stagnation, the only way to solve that problem is to
stop doing it.

------
bob1029
Sigh.

Yet more confirmation that my team has made the correct choice in switching to
a mostly vanilla JS development stack (we still use RiotJS for one-way
template binding). I was there for the beginning of Angular and it got me
hooked on single page applications, but what I am seeing now is the antithesis
of productivity.

No one building a website for a business should be using this stuff, unless
they drank so much frontend framework kool-aid that they cant find their car
keys without an NPM command anymore. I don't care how many internal projects
at google use this framework. _Our_ business doesn't have billions of dollars
to incinerate on attempts to prove a point.

The means of successfully executing SPA and managing your UX state are not
intrinsically linked with using someone's subjective interpretation of how it
should go (aka a frontend framework). Treat the browser and the DOM like an
actual canvas and stop looking through the perspectives of others to see it.
Focus on what you want to build, not the tools you use to build it. The fact
that there are literally hundreds of angular-style frontend frameworks with
wildly different approaches should be a warning sign to developers looking for
a consistent basis upon which to build shit.

~~~
dbbk
> Focus on what you want to build, not the tools you use to build it.

This is an interesting comment to me because, by essentially building your own
framework, that onus is now completely on you. If you want to implement code
splitting or tree shaking or whatever, you have to figure that out for
yourself. That's time taken away from building product features. Whereas other
frameworks can offer this out of the box because smart people in the open
source community have figured that all out for you.

In addition, no one coming into your organisation has any continuity of
knowledge, so they have to learn all the proprietary ways your app is set up,
which is more time lost.

~~~
garraeth
I also did what the parent did. I'm using mine on several enterprise projects.
And I'd also argue that devs spend //more// time implementing updates due to
framework churn than for maintaining their own framework. After mine was
"done", it was done. There is no code churn, all the features are in, tight
code, etc,...so now I only spend time creating/expanding my products.

The discussion today about React v6 is exactly what we get to dismiss (as well
as any along the way from v2 - v5) since our framework work is done.

Granted, you're absolutely correct when you say new devs have to learn all the
proprietary ways of your framework. But even then, since the framework is such
a small percent of the overall knowledge dump for a new hire, I'd argue, that
it's not much of a concern. It'll take months to learn the systems, and maybe
a week(?) to learn the framework.

And to be fully honest, I haven't learned React/Angular/Vue (did learn
KnockoutJS back in the day), and if I need to hunt for a job, then yes I'm
behind the curve.

~~~
sangnoir
> After mine was "done", it was done. There is no code churn, all the features
> are in

Do you actually believe that? Or does your organization not believe in
software maintenance and opts to rewrite entire apps instead? In my
experience, Enterprise^w software is never "done". A common conclusion to your
story is "I've been asked to modify/refactor this app that has ben unchanged
since 2005" \- sure it's perfectly crafted, but it's in ECMAScript _3_. Also
Best practices shift over time.

------
coolspot
Beware that new @angular/cli@6.0.0 doesn't support universal node packages
that are using fs/net/stream depending on the environment

(e.g. using fs.readFile() when running in Node, while using window.fetch()
when running in a browser.)

It seems that Angular team made a decision to not have out-of-the-box support
for projects using such packages even in the future [1].

[1] [https://github.com/angular/angular-
cli/issues/9827#issuecomm...](https://github.com/angular/angular-
cli/issues/9827#issuecomment-369578814)

~~~
Yuioup
Makes perfect sense to me.

~~~
coolspot
It may sound logical, but unfortunately breaks a lot of existing angular
projects and there is no kosher way to configure it to work.

For example both Rust’s stdweb and emscripten are detecting node/browser to
load wasm file by appropriate method, they will not work in angular 6 project.

------
antonkm
Was a firm believer in Angular when it was version 2, made the switch to React
before Angular version 4. Best choice I've done for productivity.

~~~
stupidcar
I'd offer the opposite perspective: I started a recent app in React, and I
wish I'd stuck with Angular.

The core of the React render model is beautiful. It's far quicker to start
writing and using a new component in React than in Angular, and the functional
nature of React components feels good and highly productive. At first.

But the problem is, around that beautiful core, the React community has built
a mass of libraries, meta-frameworks, techniques and practices that are
decidedly _less_ beautiful. After a while, I really found myself missing
features from Angular, and struggling to replicate them by wiring together a
hodge-podge React++ framework. Instead of being productive, I was wasting an
inordinate amount of time trying to discover what the current micro-framework
de-jour was for handling a particular problem in React.

For example, Angular supports view encapsulation. So you can write CSS
targeting a component, and the framework will ensure that the style rules you
write apply only to the HTML rendered by that components, without leaking to
other parts of the app. This really is a godsend for properly isolating
components in a reusable way. With React, there's a myriad of libraries for
doing CSS, but most seem to be abandoned, and none seem to offer as
straightforward or as easy style encapsulation as what Angular provides out of
the box.

It was a similar story with forms. Which are a rich, reactive API in Angular,
but seem to be an afterthought in React. And with dependency injection, both
of singleton services and components elsewhere in the hierarchy.

I expect if you go all in on Redux, you can eventually build up a reasonable
facsimile of what Angular provides. But from a standing start I think Angular
is a much more productive framework, just because it's actually trying to be a
framework, whereas React seems to be stuck somewhere between being a UI
library and a framework, leaving the community to somewhat badly fill in the
gaps.

~~~
smuemd
Check out this pattern [http://meiosis.js.org](http://meiosis.js.org)

Works great along w react

~~~
PunchTornado
your comment proves his point exactly.

~~~
pygy_
The Meiosis pattern cristalizes the essential complexity of centralized state
management (flux/redux), with no boiler plate, and little to no extra library
code...

How does that prove his point?

------
EugeneOZ
Just in case if somebody didn't read to that part, I want to highlight this
amazing tool: [https://update.angular.io/](https://update.angular.io/)

------
yesimahuman
The auto import of providers is my favorite feature in this. Now you can just
define something as @Injectable() and make it available in the module
automatically. Big improvement over older versions

~~~
erlich
Why do you even need providers?

No one using React uses them. Google can't break free of old Java habits.

~~~
azr79
The things Angular Community achieved with the dependency injection system is
mind boggling, it's a very powerful paradigm.

------
pepijndevos
In case anyone else has not been following Angular very closely, apparently
AngularJS is version one, based on JavaScript, while Angular refers to version
2 and higher, which use Typescript. A major difference seems to be that
Angular is more geared towards one-way binding. Two-way binding was from what
I gather a common complaint from the React side, saying it's slow and leads to
complex and unexpected behavior.

------
AntonyGarand
Very nice!

The ng update command will make updating a lot easier, this has been bugging
me with the fast release cycle Angular is using.

------
akmittal
I was waiting for ivy renderer which is a big improvement. It was not included
in this release.

~~~
STRiDEX
Its available behind a a flag. angularCompilerOptions.enableIvy

This article had more on it [https://blog.ninja-squad.com/2018/05/04/what-is-
new-angular-...](https://blog.ninja-squad.com/2018/05/04/what-is-new-
angular-6/)

------
ufmace
I came in here to try and get a feel for what front-end developers these days
think of the new Angular vs React. I don't have any stake in this game, since
I'm not currently working on anything front-end. I'm pleasantly surprised to
see that, instead of the half-expected Angular bash-fest, there seems to be a
number of people praising Angular over the React ecosystem.

When I last did front-end, I was using Angular 1.x, and despite some warts, I
did like the overall architecture of it, and how it provided all of the
important components for you and gave you an overall app organization. It felt
like quite a change to try and build an app with React and experience the
world of having to pick and glue together a bunch of components with ever-
evolving build systems. This makes me more interested in trying to build
something in the new Angular.

------
knowThySelfx
Probably good for starting new projects. The ecosystem looks clean with
separation of concerns. Not worth the pain migrating old projects to Angular
2/3/4/5/6/n, unless you have the resources to do so.

------
rsuelzer
Yay. I thought I was done with work for the day but I'm going to start seeing
how this update goes. I doubt I will be allowed to spend much time updating
packages during the week.

------
catchmeifyoucan
Still no support for deleting components in one go. That would improve the
toolchain :(

------
ausjke
Ignoring Angular since the start, this headline and comments made it like I
need check this out again, but, Angluar2+ seems like in decline in
trend(comparing to React and even Vue), is this not true all of a sudden now?

------
sixdimensional
How will WebAssembly play in to Angular in the future?

~~~
IggleSniggle
For the most part, they’re not part of the same discussion.
TypeScript/JavaScript is still a sensible language and execution environment
for interaction driven browser concerns.

That said, there are some interesting implied ambitions for Angular. The
AngularDart project, the Bezel project, the AngularCompiler more generally as
a point of special focus...

------
vonseel
6? Weren’t we just talking about the major upgrade to Angular 2.0 less than
two or three years ago?

------
megaman22
What is the backwards compatibility and support model for Angular? I just
don't have time to chase after things that move this quickly, not and fulfill
all my other responsibilities. I'm supporting a mature application that has a
front-end started less than eighteen months ago with AngularJS. Maintenance
and support on third-party components we use is already starting to dry up.
Rewriting things every six months is not reasonable for our team, much as we
really ought to stay up to date.

I suppose we'll muddle along until things really break down, but this pace of
change is not sustainable, particularly when so much of it just seems like
churn for churn's sake.

~~~
davidjnelson
Angular 2 came out in 2016. Why use angular 1 in 2017?

~~~
megaman22
It was 2016 when we started this front-end rewrite, away from a mess of jQuery
and Razor view spaghetti. Angular 2 was brand new, without much support for
third-party components we used, and AngularJS looked like the mature option.
Probably should have bet the other horse, but c'est la vie.

~~~
aeriklawson
We're in the middle of upgrading from Angular 1 to Angular 5 (probably now 6)
- it's not that hard and I'd recommend doing it.

