
Angular 5.0.0 - d2kx
https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935ced
======
Yabood
This rapid pace of major releases is a little scary. We're stuck running
Angular 1.x because there's no reasonable upgrade path for us. We're a .NET
shop and really like Angular, but after the 2.x cluster fuck, we're now
thinking about going with something else entirely.

~~~
eric_b
Angular 2 will not help your team deliver valuable web experiences to
customers any more quickly or reliably than Angular 1. Probably almost
certainly the opposite.

I'd argue most teams, if they're willing to go all-in on an SPA framework
(which for most apps is a waste of time and money imo) would be better off
with React + TSX.

Edit: Vue is probably closer to the "Angular way" with databinding, but
component to component communication really needs something additional like
Vuex. So, really, just use React/Redux and you'll get a bigger community with
more real-world apps being built with the tooling.

~~~
apatheticonion
I disagree. In my experience, developing a REST API and SPA with Angular2+ has
been the quickest development cycle I've experienced.

Not only is it very pleasant to work in, but the end product for the user is
high quality.

Vue is great, but it's lack of proper component support makes it a bit
annoying to work with.

I have just migrated an app that was on Angular 2 RC4 to Angular 5 with little
to no migrational woes.

The transition from Angular1 - Angular2 sucks, but ng2 and beyond is trivial.

~~~
chrisco255
Vue has one of the best component models I've seen. Angular's is some odd mix
of SystemJS, HTML, RxJS, and TS...and it's dependent on it's custom CLI for
optimization. It's probably the most complicated component model of the modern
JS frameworks. And there's no JSX support on Angular.

------
philippz
I somehow do not get all that bashing. Angular did extremely great things with
Angular 1 (back then). As time passed, the community learned that there are
better/other concepts. React came out - nice. NG2/4 therefore had to include
major changes to pave the way for the future and more modern concepts. And it
is important that they do that because some people have built huge teams and
applications based on Angular. So, thanks!

From ng1 perspective, the migration path to ng2/4 is more economic than a Vue
or React rewrite. We examined that in depth. This is why we upgraded to ng2
instead of rewriting the application in Vue or React. And as i can see it, ng5
fixes major issues from ng2 and we're happy that the Angular team keeps on
pushing here.

~~~
skydv
People jump on a victim train too easy. If they can't complain on life, they
complain on JS or Angular. If you think something is better, ok thanks, we
will consider it. But what is the alternative? React? Good god, never. Vue?
Can't comment, but doesn't seem to be doing good:
[https://trends.google.com/trends/explore?date=all&q=Angular%...](https://trends.google.com/trends/explore?date=all&q=Angular%20tutorial,Vue%20js%20tutorial,React%20js%20tutorial)

~~~
yaseer
Google trends can be quite hard to read - that search term will include
Angular 1, which is far larger than Angular 5.

Github stars is a more precise metric. There, react has 80K, Vue is close with
72K (and gaining ground), and both are far ahead of angular on 30K (as of
early November 2017).

[https://github.com/vuejs/vue](https://github.com/vuejs/vue)
[https://github.com/facebook/react](https://github.com/facebook/react)
[https://github.com/angular/angular](https://github.com/angular/angular)

------
tannhaeuser
Congrats to the new release! I've got a lot of respect for putting so much
energy into open source projects.

Predictably, the discussion evolves around Angular vs react/vue/ember or
whatever (personally, I like react).

My current customer project introduced me to a new generation of web front-end
developers specializing in a particular framework (react/redux in our case)
but know very little about CSS and the myriad of plumbing and polyfilling
going on in browsers. In the end, they delivered an app that would only run on
Chrome. Sadly, the whole thing makes me realize just how utterly inadequate
the web platform after all these years still is for the kind of MVw apps folks
want to use it for.

I think there's a place for a new "opinionated" web framework once again which
more closely matches the needs of business apps, and which has an option to
stand-alone app deployment outside web browsers. Mind you, this isn't a
sentimental reflection on Java applets and their failure or some such, but
based on years of actual project experience, including in front-end developer
roles.

For example, the other day I learned that in 2017 there's no way to query the
current zoom level of a web app (until very recently with the brand new
Viewport API; but it's not supported using media queries; I mean, seriously?).
Furthermore, I'm using a very simple SVG background image for a text area
element, and the latest Chrome release introduced laughable aliasing bugs,
which I could only workaround by using `opacity: 0.99`. There are still just
so many tricks and hacks necessary for even the most basic of UI tasks that a
realistic web app project feels like jumping from one ridiculous issue to
another, frantically searching through StackOverflow, CSS-tricks, etc.

With the somewhat naive reception of react, Angular, and co (which don't
actually do anything GUI-related, nor help with browser compatibility
problems), I'm wondering whether I'm the only one feeling like putting square
pegs into round holes using the web for anything other than content-driven
sites.

~~~
hackerfromthefu
Perhaps WASM will provide the better match for business applications,
sidestepping HTML entirely.

It should allow side-stepping the complex morass of piecemeal evolved html
features and implementation border case incompatibilities.

e.g. Today you can use Unity game engine to target WASM as a runtime and it
should render, and function, very much identically across all browsers, and
with a bit of creativity can be used to include forms and business
functionality.

This does come at the cost of downloading the app runtime and UI libraries
with the app, but frankly the download size is not such an issue anymore and
in the future for many markets. e.g. 5G mobile broadband is targeting Gbit
speeds!

~~~
tannhaeuser
I know people put high hopes into it, but WASM by itself does exactly
_nothing_ to improve the basic rendering model of browsers (CSS and it's
various layout models). It just replaces JavaScript (which I have no problem
with at all), making browsers even more complex. WebGL, OTOH, can be used from
JavaScript without problems, including typed arrays and SIMD.

I was thinking more about ditching the browser entirely for apps. Because what
WASM and WebGL do is just a very tiny subset of what's been possible for ages
with plain old native languages and D3D/OGL. And why do we need a new bytecode
format when basically all phones run on the ARM ISA? I guess I don't get why
games should run in a web browser with all it's security and privacy issues.

But yeah, almost anything is better than HTML/CSS/JS for complex UIs.

~~~
hackerfromthefu
Since you stressed the point that WASM does _nothing to improve the rendering
model_ , it's worth noting I never wrote that it did.. but about replacing the
UI with custom libraries (rendering to canvas), hence why I used Unity as an
example, then mention the need to download UI libraries.

This is the only approach supported by WASM in the near future, although a
browser DOM bridge is roadmapped for a couple of years on. ie ditching the
(DOM of the) browser entirely for apps (in WASM) - apps that can run on ANY
platform with a modern browser.

>> And why do we need a new bytecode format when basically all phones run on
the ARM ISA?

There are in fact some good reasons

* It's an open standard, which it seems many vendors will get behind and it will become ubiquitously available, and as such stands a chance of competing with Html/JS for the crown of the 'everywhere platform'.

* Being sandboxed by the browser instead of running on bare metal has huge value for security.

* Being sandboxed as an abstraction layer allows ISA portability. You mention most phones run on ARM, but more than a handful of people want to use PCs running Intel too! Also not all phones run ARM, and there are future ISAs that don't exist or aren't mainstream yet (such as open source ones) and the abstraction of a runtime makes it easy. WASM has been design to be good as a portable target (ie easy to implement on a new ISA as opposed to writing full emulation).

The first one is the most important one, about being an open standard with
enough industry implementation to achieve critical mass for users and become a
sustainable 'any/everywhere' platform .. the technical issues could be
addressed other ways, but that only matters if people can access your runtime
(which is what killed Flash and Silverlight).

There are downsides too, such as performance, however the market has shown it
doesn't really care about performance by choosing the bloated Javascript mess
have today.

tl;dr; Runtimes are good for the majority of consumer and business software,
and WASM is the first one all the big players are supporting instead of the
competition sabotaging

>> I guess I don't get why games should run in a web browser with all it's
security and privacy issues.

The question implies that native code has a better security and privacy
profile than a hardened browser sandbox.. actually that right there is the
issue. You actually get a far better security and privacy 'platform' on the
browser, despite/because of the much larger attack volume.

With native you can do and access anything the OS allows, and find
vulnerabilities in the entire OS APIs. Even on e.g. iOS the native code can do
all sorts of things and call private hidden apis etc, Apple just tries to use
static analysis to attempt to find these issues before you download it..

------
ainar-g
From my colleagues, both front-end developers and full-stack developers, I've
heard nothing but criticism of Angular >2.0.0. I would like to hear the other
side. If you use fresh Angular, why?

~~~
hateful
When I used Angular 1, the two way binding was a breathe of fresh air. It was
akin to when jQuery first hit the scene and you all of a sudden had selectors.
There was a learning curve regarding the "Angular way" (think: $scope,
controller, directive), but altogether I was happy with the result and the
ideology.

I tried Angular 2 and it was a mess. It feels as though the ideology is
fighting you every step of the way, but with no foreseeable benefit beyond the
benefits of Angular 1. Angular 1 had some issues of course (mostly with scope)
but it gave us a way of working around them (via, $rootScope, etc), but
Angular 2 seems to have taken away (again, think $rootScope).

Around the time Ancular 3 came out (yes, a renaming of Angular 2), I moved
over to vuejs and haven't looked back yet.

~~~
microcolonel
> _When I used Angular 1, the two way binding was a breath of fresh air._

Yeah, to be honest, if you aren't suffering performance issues as a result of
it, Angular 1 is very productive. Problems present themselves in applications
with large views, or using esoteric low-performing features. Angular >2 should
never have been called Angular. Even if they call it "Angular" instead of
"AngularJS", everyone called AngularJS Angular to begin with. It's so utterly
different that it doesn't even fit in the same places.

------
interlocutor
Lack of compile-time checks for the template (and embedded expressions) is a
major limitation of Angular. This may be OK for small projects. For large
projects with many developers this is a huge problem. Here's what happens: a
developer modifies code he's not familiar with. He introduces a bug due to a
typo. He builds the code without errors, and runs the application, and
everything seems to be OK. The bug is not found even at run time because the
developer did not click on something during his manual testing. You can try to
reduce such problems with automated tests, but test automation can't reach
every corner. As much as possible such issues should be caught at compile
time, and Angular can't. This is a major flaw.

Compare that to .tsx templates (Typescript's version of JSX). All html as well
embedded expressions are checked at compile time, and typos are caught at
compile time.

~~~
mikeryan52
This isn't true and hasn't been true for a while. Angular's ahead-of-time
compiler converts the template strings into TypeScript which are then type
checked, all at compile time.

~~~
whitefish
Can you put a breakpoint in the template?

In .tsx templates you can.

Templates frequently need loops and conditionals. In the case of .tsx this
logic is in TyprScipt so you can debug it just like any other TypeScript. In
the case of Angular such logic is written in an undebuggable custom syntax.

------
afromobile
we're a c# shop too. 7 developers. we started with angular 1. we too got
caught in the angular 2 mess but we stayed with it. we know react but after
you add routing, redux, forms, etc to react, you've got something close to
angular.

i just updated a medium sized angular 4 app to angular 5 with no problems.
typescript has been our saving grace especially when you're collaborating code
with your team. we've really come to enjoy angular. if you're migrating from
angularjs it can be difficult but if your developing a new app with form
validation, routing, redux then i would recommend angular.

------
Yuioup
I really don't get the hate for Angular 2+. Been using it for almost a year
now and I love it. Fantastic stuff.

~~~
jmkni
Likewise.

I think a lot of the hate is down to the naming (AngularJS vs Angular), but at
some point you need to just accept that it is what it is and get over it!

~~~
Yuioup
Yeah. I have only ever used Angular 2+ . It seems that Google messed up on the
transition from Angular to Angular2, and the community hates them for it. This
is the situation that Python has been trying to avoid for years now.

------
racl101
I haven't used Angular in a while, so I haven't heard about Angular 3 or 4.

What's even weirder is that most people I know using Angular are still using
version 1.

------
myth_drannon
Unfortunately Angular lost the market momentum they had and other frameworks
picked up the tab. No matter how many amazing features they add.

------
nikolay
While most still are on Angular 1, releasing 5 reminds me of Magento where
most shops are still on version 1 with no desire to upgrade to 2. There are
even forks that focus on improving version 1 ignoring the version 2 of the
upstream project.

------
EugeneOZ
Thank you for new release. For me there is still nothing better than Angular -
I hate html validation, but I hate JSX even more. I hate verbosity of
declarations (app.module, app.component, imports...), but I hate lack of
official router in React even more. I don’t like RxJS and I hate that you are
forcing me to use it, that you ignore even simple feature request about GET-
caching, but there is still no good replacement for Angular. I didn’t mention
hell with tests just to don’t be too sad on this happy moment of new release
with a lot of breaking changes. Thank you.

------
jbigelow76
The more time I've spent with Angular 2+ and later the more it feels like a
DSL to me than a Typescript framework, much more so than the, admittedly very
limited, time I've spent with React and jQuery before that. That's not really
a knock on it, I find it to be extremely productive for me which is why I
haven't gotten away from it. I just don't think it does much to enhance my
skillset in front-end development overall.

------
maxpert
Have recently moved system from TS + Angular 1 to Angular 1.5 and then to
Angular 2 (took us solid 1 year and you can still see some traces of older
code), by time we finished move to 2, Angular 4 was released! And now this!
This is WTF moment of my life.

~~~
ptmcc
There's very few incompatibilities from the 2.0 release onward.

A few minor things here and there, and a few deprecations, but by and large
most everything that worked in 2.0 should still work in 5.0.

------
drraid0
All I want for Angular are better error message and better browser-refresh
times. Right now on 4 I get a meaningless page of gobbledeguck for most error
(b/c of transpilation) and 12 seconds to reload the page.

~~~
fknop
CLI should be pretty much instant to reload a page.

~~~
drraid0
It isn't. A fresh 'ng serve --open' takes ~20 seconds to get to a ready page,
and each reload is taking 10+ average. Every minor change.

I can personally stand it because I remember working on 2 million line C++
projects in the 90's. The millennials on my team, on the other hand, are going
insane. I've recommend they disable live-reloading completely.

------
botskonet
Several years ago we chose AngularJS/v1 for an enterprise-level app. Once
Angular/v2 was announced it was still more of an experiment, but things have
changed far faster than we anticipated.

Projects like ui-grid are dying and ui-bootstrap is dead and they're moving to
Angular support only. We're suddenly using tech that's being abandoned a lot
sooner than we foresaw.

I have my issues with Angular v2+, though overall it's way better than v1, but
I truly hope the same doesn't happen to those making an investment in this new
platform.

------
hanspragt
Has anyone had success using the AOT tools to build a package of reusable
angular components? I was able to use AOT pretty easily for a stand-alone app,
but keep running into issues when trying to create a shareable component, and
there is not a lot of documentation around this.

~~~
harunurhan
I have, but by using ngc in my gulp build task (had to use gulp for the reason
below), unfortunately couldn't make it incremental at that time, so it takes
several seconds to re-build when the source is changed.

There is actually another problem when you want to develop reusable UI
component library project is that you have to inline style files and template
file into ts component.

~~~
hanspragt
> There is actually another problem when you want to develop reusable UI
> component library project is that you have to inline style files and
> template file into ts component.

We have a webpack-based process, and using the angular2-template-loader will
take care of this for you. Unfortunately, webpack and aot don't mix well.

------
fareesh
We have invested time into Angular 2 and leveraged a fair amount of its
features and ecosystem, but implementation specifics on some have been a great
challenge.

We watched the Google I/O presentation from 2016 where the team pitched a lot
of exciting stuff coming to angular like SSR/Universal rendering, and decided
to buy in and use ng2, but using universal with the CLI was near impossible to
get done given how undocumented it was. There was a CLI fork that was quite
promising, and with a bit of work we managed to get client side AOT
optimization and SSR.

Bundle sizes after all this were unacceptably high. The documentation and
talks had discussed things like tree shaking and other such optimization
processes, but there was a tussle between webpack and rollup where the CLI
used one and not the other, and rollup did tree shaking better, so we had to
either drop tree shaking or the CLI. It was not a fun experience.

Eventually angular 4 dropped and there was a timeline on getting the CLI up to
speed with universal, the guys at Google I/O 2017 did a talk on universal
rendering, but they used some cryptic command line tools that were also fairly
undocumented at the time. The angular 2 app sat in production using the old
CLI fork that had been abandoned and we weren't able to migrate because
universal documentation for angular 4 was also relatively unclear.

Finally for future projects we opted to go with Vue, which has been relatively
nicer. We used localization, token based authentication via cookies to enable
authenticated universal rendering for logged in users, PWA features (offline).
The project was analogous to Yelp, with product and service suggestions
displayed to the user depending on their browsing habits and other aspects of
their profile. Roughly 300k monthly uniques. Universal was essential for SEO
and performance since 90% of traffic was search.

Other than struggles with universal and SEO, there were some issues with
getting customizations to the webpack build process since the CLI fork we used
didn't allow for many changes like adding minification, etc. We also wanted
stuff at the express end of things like HTML minification, but there was no
clear-cut way to do caching across things like authenticated vs
unauthenticated. Maybe we couldn't think of the best way to go about this.
Other frameworks seemed to have a painless way of doing this stuff, so we
spent a lot of time wondering if we had made the right choice. Most of the
plain client side stuff was very satisfying to use. RxJS is great as well, and
it was nice to see it become popular across the JS ecosytem. I am not sure if
I would go with angular for future work because the bundle size seems to be
overwhelmingly high - perhaps due to a knowledge gap at our end. What would be
fantastic some sort of sample kitchen sink demo application that employs all
the best practices for everything - auth, localization, seo, universal, build
process customization, etc.

At the time of our evaluation, we looked at a number of quickstart and
bootstrap/boilerplate/starter kit projects, but each one seemed to lack one
thing that we really wanted, with no clear path to integrating it in.

~~~
netinstructions
I was in the same boat - Watched Angular 2 presentations live (was it ng-conf
or something?), was excited about Angular Universal and the Angular CLI that
was announced.

Turns out the CLI didn't play nice with Universal. I spent a week trying to
convert the bare bones Angular 2 tutorial 'tour of heroes' into an Angular
Universal architecture. I couldn't figure it out. Lots of version mismatches
and either out of date or 404'd documentation.

I just gave up. If I couldn't convert a simple project to do server side
rendering there was no way I'd be able to convert a more complicated project.

------
simook
Still a fan of 1.x, not sure why they think new major versions will convince
me to move forward.

------
KaoruAoiShiho
Just use Vue. Angular is just dead for a large part of the community.

------
merb
`ng serve --aot` will be default?

thanks... please fix: [https://github.com/angular/angular-
cli/issues/6742](https://github.com/angular/angular-cli/issues/6742) before..

~~~
fknop
They actually reverted aot by default on serve because for really large
project it might slow down the reload time.

------
yatinkal
When Angular 1 was left for dead I went to Knockout.

------
azr79
Fantastic release, congrats to the Angular team!

------
gungoman
Coming from the jQuery and Datatables and Knockout era, I just can't accept
the weight and performance of Angular beyond the 1.0 release. I fell in love
with Vue.JS (it works like jquery and knockout very similarly)

------
bjconlan
Woah! static injector and typescript transforms! does this mean i can use
angulars dependency injection framework for any typescript project without
including any 'real angular' so i can start writing node services like i would
with spring!? (or perhaps closer to dagger2?)

------
diminish
5.0.0? - such precision in versioning for a library or framework seems both
too quick and too precise at the same time.

~~~
evmar
They are following semver: [http://semver.org/](http://semver.org/)

So the major version changes whenever they make a backwards-incompatible
change.

However, I clicked in their upgrade calculator (linked from the post) and at a
glance it appears the incompatible changes are fairly minor.

~~~
usrusr
But did semver really set out to eradicate all distinction between minor
incompatibilities and complete architectural reboots?

So much semver adoption seems to be based entirely on wishful thinking.

    
    
      Step 1: hey, perfect drop-in compatibility would be so cool
      Step 2: we can do it, with semver!
      Step 3: we use semver! Yay us!
      Step 4: oh, turns out adopting semver did not make perfect drop in compatibility any easier
      Step 5: don't ever touch that zero between major and bugfix

~~~
dragonwriter
> But did semver really set out to eradicate all distinction between minor
> incompatibilities and complete architectural reboots?

It's explicit terms do, whether or not that's the intent. Backward
incompatible is a bright line.

OTOH, I think that exact bright line _is_ the central purpose of SemVer.

~~~
usrusr
> Backward incompatible is a bright line.

Only as bright as the line between public API and private implementation
details that are allowed and expected to change between semver minors. This is
not always very clear.

