
Angular v8.0 - tashoecraft
https://github.com/angular/angular-cli/releases
======
pure
Angular is really a great framework. I think a lot of people complaining about
Angular haven't actually built an app in Angular 4+. I also wish the Angular
team had just called Angular 2 something else, since the 1 -> 2 transition
frustrated a lot of people who jumped ship and never looked back. I also
understand that people just have different preferences, which is fine, too.

Out of the box, you get: routing with lazy loading, full TypeScript support
and a TypeScript-first ecosystem, a great CLI that completely abstracts
Webpack and the build process, easy and mostly automatic updates with the CLI,
reactivity with RxJS baked-in and supported widely in the community, a great
forms library, and, of course, a component-based approach to UI development.
The uniformity is a big benefit. It's easy to ramp up on a new Angular
project, and there are fewer decisions to make when starting a new one. The
built-in parts of the framework are all high quality and an easy bet. There's
no need to evaluate different routers, form libraries, HTTP clients, get back
up to speed on configuring Webpack only to forget how until next time, etc.

It's also interesting to see the React community move towards some of the
things that Angular has been doing for years: embracing TypeScript, extracting
business logic to services (or you can call them Hooks), creating injectable
shared state (or you can call it Context).

~~~
bpye
I've been using Angular for a few months now and it's mostly been a good
experience. We've been using Angular 7.

My biggest gripe, and this might just be my inexperience, is fighting the
change detector to try and ensure reasonable performance when displaying a
large number of elements. There are certainly mechanisms to do this but it
does seem to take some work.

~~~
jamesgeck0
FWIW, the Angular team is aware that this is a pain point. There were several
talks at NG-Conf a few weeks ago that referenced replacing or removing
zone.js-powered change detection for increased performance and/or smaller
build sizes. They're trying to avoid another Angular 2 situation though, so it
may take a while for a backwards compatible solution to surface as the
default.

~~~
nicoburns
This is precisely what I don't like about Angular. That there is all this
_stuff_. And I have to care about what it is doing under the hood (and this is
complicated and not especially well documented).

In React if I have performance issues, then it's pretty easy to work out
what's causing them.

~~~
jamesgeck0
You can largely ignore what Angular is doing under the hood, tbh. If you're
having performance issues, the answer is often related to change detection
(aka, Zone.js).

~~~
nicoburns
> If you're having performance issues, the answer is often related to change
> detection (aka, Zone.js).

This is part of Angular really. At least it's not optional to use it. Change
detection issues are not fun to debug!

~~~
jamesgeck0
> At least it's not optional to use it.

Zone.js is optional, although it is on by default. It's considered best
practice to remove it when building standalone components with Angular
Elements.

------
royjacobs
Congratulations on the release! For all the talk of React and Vue I still like
the 'batteries-included' approach of Angular.

I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way
applications are structured. I don't get the militant need for terseness
that's seen in approaches like React Hooks. I also don't need the choice
between multiple backwards-incompatible (or competing) routers, nor do I have
a need for functionally pure reducers.

So, it may not be sexy, but It Works and that's good enough for me :)

~~~
mhd
I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the
desire for something simpler. On the other hand, when you leave the world of
progressive enhancement and widgets (ie. jQuery), you find yourself needing a
lot of common infrastructure and picking and matching that can be quite
tedious (never mind dependency hell), which is something that react always had
issues with -- and that seems to extend fractally, where it's not just MobX
vs. React but then what framework/project setup you have on top of each of
these choices. And now hooks.

Still, angular always struck me as going slightly too far into Java-land -- my
Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations.

And in between you've got VueJS/Vuex, which seems to move a bit too close to
react at times, and EmberJs, which seems to move too slowly and/or without
many people watching it.

I really want to go back to late-90s desktop UI development sometimes…

~~~
ChicagoDave
WebAssembly is still a couple of years away, sadly.

~~~
mhd
Yes, then we'll get _native_ J2EE in the browser instead of JS copies…

The whole interaction model is just a lot more tedious than desktop UI
development. One of the few approaches that I actually liked (not just
tolerated) was Seaside, but that went away when the blood-dimmed tide of JS
was let loose.

~~~
sheeshkebab
>then we'll get native J2EE in the browser instead of JS copies…

Can’t wait. Imagining all the possibilities...

------
vfc1
This release is awesome, here is a summary from the Angular team blog -
[https://blog.angular.io/version-8-of-angular-smaller-
bundles...](https://blog.angular.io/version-8-of-angular-smaller-bundles-cli-
apis-and-alignment-with-the-ecosystem-af0261112a27)

The main feature among many is differential loading, that will load different
versions of the application depending on the capabilities of the browser.

This will avoid installing polyfills without the need for them and reduce the
bundle size. There are reports of 40kb reduction in bundle size, which is a
lot.

More than that, this release does a lot of preparation work for Ivy in version
9, which will bring a completely new rendering layer.

Also, there is a lot of preparatory work for the introduction of Bazel in the
build pipeline, which will bring us fully incremental builds (recompiling only
the part of the code that changed and nothing more).

~~~
marshallant
Differential serving can easily be done using babel and webpack. Been doing it
for awhile now.

~~~
vfc1
Yes, it was possible with Angular also before, just like with other
frameworks, but now this is built-in the Angular CLI build pipeline.

This means that this is now mostly transparent to developers, and taken care
for us by the build pipeline without having, for example, to configure webpack
and Typescript manually ourselves.

------
dmitriid
In my opinion Angular's story is a story of how people invent problems and
then valiantly tackle them.

\- We want to re-write the whole thing from scratch. In TypeScript.

\- And let's use Google's Closure Compiler for JavaScript. Even though it
doesn't support TypeScript, modules, or anything, really from non-Google
Javascript world (at the time)

\- Oh. Then... Let's create a TypeScript to Closure Translator even though
TypeScript doesn't let you extend the compiler and TypeScript and Closure are
in general not entirely compatible

\- Oh, and we use a weird combination of annotations and templates to work,
so... we need to compile our templates into TypeScript (which we need to
translate to Closure-compatible JavaScript which will then be compiled further
down)

\- Only the whole process is abysmally slow. Let's implement incremental
compilation.

\- It's probably still slow, complicated, and error-prone. We know! Let's use
Google's Bazel! You know, the tool to build huge codebases in parallel on
clusters. Yeah, why not use _that_ to build JS code?

\- Only bazel has no support for either Closure, or Javascript, or TypeScript,
so we have to build tools and integrations to work with bazel!

And the quests just keep popping up.

~~~
equasar
What's the point you are trying to achieve with that negativity?

Writing non existing tooling around some tools is almost positive as they can
pave the journey to other and better tooling.

Also, I doubt you are paying a cent to those developers to justify your
complaints about it.

~~~
dmitriid
> What's the point you are trying to achieve with that negativity?

Not trying to achieve anything. It’s my own personal opinion on how I view
Angular’s development. The devs dig deeper and deeper holes to bravely climb
out of them.

> Writing non existing tooling around some tools is almost positive

Since there’s no cost-benefit analysis, “almost positive” is entirely
speculation.

> I doubt you are paying a cent to those developers to justify your complaints
> about it.

“Only paying customers are allowed to voice criticism. Please purchase a
criticism package or a yearly subscription today. Volume discounts are
available, contact your nearest sales representative”

------
pier25
While the effort by the Angular team deserves praise, I think for the vast
majority of use cases it is a mistake to do it all client side.

With some exceptions, there is really no benefit in making a SPA but there are
many drawbacks.

I don't say this lightly. I used AngularJS in 2015 and since then I've been
making SPAs in React, Vue, and Inferno + Mobx.

~~~
christophilus
I tend to agree. But in defense of the SPA, my experience is that over time,
most screens accrete complexity.

You start out with a simple content screen. Then the client wants comments.
Then they want richer comments. Then they want live comments. Etc.

Over time, most of my web applications tend to require richer and richer
interactivity on each screen. As a result, it's nice to have started out with
a client-side framework, rather than hitting some threshold where you suddenly
need to switch things over.

~~~
hombre_fatal
Your last paragraph summarizes why I default to a client-side framework if
there's going to be much of any JS interactivity at all on a screen.

Even something that seems simple like a search form can be surprisingly
interactive.

------
holografix
I was recently at a Microsoft heavy tech conference and spoke to at least 50
.Net developers. Anyone who also did front end did so in Angular. I was
surprised at how popular it is!

~~~
jaabe
I work in the Danish public sector and we currently have 300 systems from
various contractors. Almost all of them are moving toward a C#/JAVA api based
backend and an Angular front. Only one of those systems uses Vue. None of them
use React.

Outside the public sector React is a bit more popular, but it’s still mainly
used outside of enterprise and Vue rarely sees any use.

The job-market doesn’t seem to follow the tech hype cycles much, at least not
when you live in a country like mine.

~~~
vnglst
I can confirm this for the Dutch public sector as well. I'm saying this as a
longtime React contractor. There's some React contracts, but very few and no
Vue that I know of.

------
Sahhaese
This should point to [https://github.com/angular/angular-
cli/releases/tag/v8.0.0](https://github.com/angular/angular-
cli/releases/tag/v8.0.0) which is the release page for this version rather
than all releases.

~~~
tashoecraft
I can’t update if a mod wants to update it for me then go ahead

------
chrismbarr
Literally just finished a huge re-write of an angular 4 app to latest Angualr
7 today, to revise the UI and improve everything. As I was about to merge it
in I see this... time to upgrade!

~~~
sheeshkebab
Job security

------
zihotki
I wonder what's the story behind delays of Ivy? Can somebody elaborate? It was
first scheduled for v6 (don't remember , then for v7, now there is v8 and it's
again rescheduled for v9.

~~~
romanovcode
It needs to be backwards compatible and it is tested with google internal
applications and needs to be approved by said applications.

~~~
imcotton
That what they have been saying for years, not what the REAL reason.

~~~
romanovcode
What would be the real reason then? It's not like they are workng on something
else. Ivy is pretty much all they are working on for the past 1-2 years. Even
to the point where events like Angular Connect are very boring because there
is nothing new except this. I'm pretty sure they want to release it ASAP and
be done with it.

------
bob1029
I honestly had no idea this was still a thing. We jumped ship to riot.js back
around Angular V2 and haven't really thought about another javascript
framework since. All of our web tools have been vanilla JS/CSS/HTML with riot
tying it all together for the last 3+ years now. It really does seem like the
ideal way to compose single page web applications. We do use some 3rd party
stuff like codemirror, momentjs, etc., but that's about it. Not even jQuery to
be found unless some 3rd party component depends on it.

The advantages of not using someone's framework, language or module system is
that we have a direct and stable surface (the DOM) against which to tie things
together. Complex web interactions we attempted to do (and failed to do) using
Angular directives/components/etc became trivial using our vanilla+riot
approach. It almost feels like cheating by comparison, and then you don't care
because your incredibly-complex web interaction that involves 5+ vendor
libraries and 8 nested API calls just works and is easy to inspect directly.

Obviously, you need some discipline to manage something with less structure
around it, but all it takes is a handful of code review sessions to get other
developers synced up on how things work in this more 'open' world. There
honestly aren't a lot of new things to learn either (there are definitely more
things to unlearn coming from Angular). Productivity is also a huge plus. I
don't have to spend an hour reviewing the semantics around some Angular
construct before I do my work. After a few weeks away from some web project, I
can jump directly into the HTML/JS/CSS, crank out a new .html riot tag file
and be done with it in less time than it would have taken to re-sync my brain
into Angular semantics land.

If you haven't tried riot yet, you should definitely take a look. Once we got
our first application working on it and we understood the basics, it felt like
we had escaped from frontend jail and could do anything we wanted to. For
everyone who views front-end as a mosh pit of chaos and uncertainty, I
strongly suggest trying this approach out on a throwaway project when you get
some free time.

~~~
pier25
Anyone knows when Riot v4 will be ready?

I wanted to try Riot but then I saw they were working on v4 with the Simulacra
guy and decided to wait until the new version.

------
visarga
Angular is too abstract / has a steep learning curve. You need to learn too
many design patterns at once (factory, provider, service, singleton, pipes,
directives, observable, component, container, dependency injection). Trying
something simple is trivial, but trying something more complex is overly
difficult.

~~~
DrFell
True, but you are learning ubiquitous programming concepts in about as well
conceived of an implementation as you will get in a frontend scripting
framework.

While none of the extra complexity is crucial to making a dynamic website, it
earns its keep when you try to build a big online application. Why not just
learn that stuff.

I think all the bundled pre-built functionality, like reactive forms, is the
hardest part of Angular. That can be tedious to learn. But then again, so is
3rd party library X, so it's a wash.

Factories are no longer in Angular 2

------
revskill
I feel Svelte is the framework that Angular author actually wanted to build
since the first version.

~~~
inglor
Funnily enough, Ivy takes a pretty similar approach to Svelte with its
markDirty calls similar to Svelte's $$invalidate calls.

That said, Angular doesn't utilize its compiler the same way Svelte does (yet)
so time will tell.

~~~
Sammi
I think moving stuff from runtime to compiletime is the theme of most changes
to Angular 2+ compared to Angular 1. So I'm very much expecting Angular devs
to look at Svelte and start hitting ctrl-c ctrl-v repeatedly on their
keyboards :)

------
arnvald
Congratulations on the release and thanks to core team and all contributors
for their work!

------
sheeshkebab
Angular feels like frontend framework built by backend java Spring developers,
that hate frontend development.

~~~
stupidcar
This feels like an argument made by somebody who has never built a serious
project in either, and has instead formed an opinion based on quick glance at
the respective syntaxes.

To me, Angular is what HTML and the DOM would look like if they had been
designed from the beginning for application development:

\- Custom elements backed by controller classes. \- Data-binding and event-
binding syntax baked into HTML \- Component style encapsulation, on by
default.

React seems far more like a project created by people who dislike front-end
development: As I recall the genesis of the project was to replace traditional
DOM mutation with a more PHP-esque approach of updating state and re-rendering
everything, just as you would do on the back-end.

~~~
sdegutis
Every time I look at Angular, I remember that they use string literals for
both HTML and CSS which is strongly off-putting. Especially because for HTML,
it becomes another template language like Vue.js, whereas React.js is just
JavaScript with a simple and predictable syntax transformation.

~~~
sixbrx
You see the template and css as literals in little Angular examples, but the
normal case is that the literals are just names of the separate html and
(s)css file names.

------
i_can_c_sharp
Does anyone know how Angular compares to Aurelia?

