
Angular 9.0 - theodorejb
https://blog.angular.io/version-9-of-angular-now-available-project-ivy-has-arrived-23c97b63cfa3
======
tony
One of the nice things that Angular has you don't see in the post is... _very_
polite and courteous maintainers!
[https://github.com/angular/angular/pull/33717#issuecomment-5...](https://github.com/angular/angular/pull/33717#issuecomment-553118863)

This was a fast release cycle. It was back in November 2019 we were talking
about 3.7, and now it's in.

I'm not even thinking about Ivy. But it's nice to have all the nice comforts
of typescript ready and working out of the box. (I mainly work in React, but
dabble with angular/vue to stay up to date)

And what a smooth update process (abbreviated):

    
    
        ng update @angular/cli @angular/core
        ** Executing migrations of package '@angular/cli' **
        ** Executing migrations of package '@angular/core' **
        Your project has been updated to Angular version 9!
        For more info, please see: https://v9.angular.io/guide/updating-to-version-9

~~~
joshschreuder
Igor seems like a good dude. I used to follow his talks and stuff from back in
the AngularJS days.

------
Phenix88be
After 2 years of Angular madness I will send my resignation and I hope I will
never work with it again.

My app is a big stack of workaround stuff that might break anytime. Because
that is how angular work. Some stuff work in a context and doesn't in an
other. Nobody's know why ! They have so much issue on Github that they need a
bot to close them after a while. They hope the bug disappear by himself ?

~~~
crubier
Meanwhile, the web apps I wrote in 2014 in react still work flawlessly.

Join us, you’ll enjoy the ride!

~~~
dragonsh
On HN in general there is a disdain for anything other than react, probably
more people of Facebook generation and admiration of it's technology like open
graph, react and few other products.

Based on personal usage of React, it's no easier than angular or any JS based
framework like Vue (which in my view more sensible than react). You add state
management, templates, router and 1000's of npm packages to do anything simple
and react soon becomes an unmaintainable nightmare with emany vulnerabilities
if you do not upgrade. An app is not just simple react but many of the npm
packages (although it's true in general for JavaScript eco-system which is by
default is insecure and maintenance nightmare unless there is an extra amount
of work done to secure it).

Angular at least provide a decent complete single framework to work with and a
unified documentation, there are issues with it, but react is same when you
need any reasonable size app from it.

React gives you an easy start with false sense that it's easy, than becomes
just too convoluted and complicated with the addition of different components
as soon as app starts growing. Maintaining and upgrading apps based on react
is very difficult as one version to another it introduces breaking changes.
Angular had similar thing from angularjs to angular 2, but slowly they made it
much better but letting compiler do more work.

Ivy tree shaking compiler will give a fight to upcoming compiler framework
like svelte and keep the size smaller and may be in some cases much smaller
than react app bundles, will wait for the benchmarks and size comparisons.

I am still waiting for a simpler way of developing web apps, elm looked very
nice, but it is still far from ready for use in the same way as Angular or
react yet.

~~~
crubier
Maybe the disdain comes from the fact that people don’t like getting a whole
house (like angular) built on shaky grounds, but prefer a clean basic
foundation (like react) where they can lay whatever bricks they like on top
(routing, data management).

It feels cleaner and more solid.

~~~
ghego1
Your argument is flawed with a very opinionative starting point, which is that
Angular wouldn't provide a solid foundation.

This is, at the very best, very debatable.

In my experience, it's the very opposite. Angular gives you very solid
foundations as it's a proper framework that ships everything you need to build
scalable apps. So you start from something small, and as you grow you know you
can do so without rethinking the foundations of the app, as they are provided
by the framework, which is Google guys, which means most likely people with a
lot more experience than the average front end dev.

On the contrary, react leaves basic choices (the bricks you mentioned) to the
user. While freedom can be good, it also implies that errors will be made, so
you are a lot more likely to build on shaky foundations.

~~~
kls
They are not people with more experience you are appealing to authority. The
cold hard truth is that Angular got it so wrong the first go around that they
had to completely rewrite the framework. The very reason was that a lot of the
early guys where just out of school and built a framework on theory. If you
contrast this with React, guys in the trenched trying to build applications at
scale for FB, they where built with totally different mindsets. The FB guys
understood the render loops that has been a pattern in UI since the desktop
days and has stuck around because it works. To this day two way data binding
and template based logic are both a dumpster fire, that cause unmaintainable
code and side effects that cause debugging to be more difficult.

This is just a bad idea: [https://angular.io/guide/template-
syntax](https://angular.io/guide/template-syntax) Without writing the tooling
to debug it, to this day there is not said tooling.

~~~
IggleSniggle
...well...on THIS day there is said tooling. In Angular 9.

~~~
kls
This is the most comprehensive document I can find on debugging in 9 and I
still do not see a way to set a breakpoint in say a loop declared in a
template. I may be missing something as I have not worked on an Angular
project in probably 6 months. But I don't see template debugging I see being
able to get reference to a component and then manipulate said component via
dev tools.

[https://juristr.com/blog/2019/09/debugging-angular-ivy-
conso...](https://juristr.com/blog/2019/09/debugging-angular-ivy-console/)

------
gitgud
The only thing I like about Angular is the dependency injection of services.
Having "services" managed for you and just picking and choosing what you want
is pretty nice.

What I don't like is the verbosity and boilerplate... here's 2 examples:

\- Routing boilerplate is convoluted and time consuming. I think Nuxt.js has a
much nicer implementation of SPA routing, where the filesystem is used to map
the routes.

\- Angular modules are verbose, redundant and don't even truely encapsulate
dependencies anyway. You can easily create implicit dependencies by relying on
services instantiated in higher level modules.... which is bad

I love using Typescript though!

~~~
mattlondon
Another benefit in my mind is that Angular is "batteries included" \- you get
everything you need in a single library, e.g. routing is a big one.

From what I understand of React, you need to pick and chose the libraries (and
versions of those libraries!) to use for your app, and then keep the versions
of all the different libraries up-to-date and in sync with each other. Sounds
like a maintenance nightmare.

~~~
mojzu
It has probably been improved since I last tried it but this is one of the
reasons I picked Angular over React. Having a router, HTTP client, forms,
i18n, etc. out of the box compared to having to
find/evaluate/integrate/maintain the various libraries that build on React to
get the same functionality was a great benefit.

The other reason is the first class TypeScript and RxJS support.

------
theodorejb
I just updated my mid-size app from v8.2 to v9 with Ivy, and the total es2015
bundle size decreased from 973 KB to 669 KB. An over 31% improvement with no
effort on my part!

~~~
pier25
> _973 KB to 669 KB_

Is that minified and gzipped?

~~~
theodorejb
Just minified. Gzipped size is now 225 KB.

~~~
pjmlp
Great!

------
pier25
Will be interesting to see how it fares in the Js Benchmarks:

[https://krausest.github.io/js-framework-
benchmark/current.ht...](https://krausest.github.io/js-framework-
benchmark/current.html)

~~~
topspin
What happened to React? It's on the wrong end of almost all of those micro
benchmarks.

I know micro benchmarks don't tell the whole story, but when you consistently
wind up on the slow end it's not a good look.

~~~
igammarays
React was a mistake of the last decade. React itself is a great academic idea
(i.e. pure functions, composability), but the whole React-Redux boilerplate
mess (I dare not call it an "ecosystem" because that word implies harmony of
some sort) is the the result of an entire generation of code monkeys and job
seekers who didn't design their technology stack with any real engineering
consideration, but rather on the basis of tool popularity, feeding a vicious
cycle of "lean startup" companies spending a glut of VC money looking for the
fastest way to hire more React code monkeys because they think "that is how
you do engineering".

~~~
crubier
I have the exact opposite opinion. React is the only sane way to do web
development. All other approaches are deeply flawed by either relying on
imperative mutations of the DOM instead of clean declarative code, or by
relying on ugly templating syntax and data attributes instead of just using JS
basic constructs like react. The power of react is just at its beginning, as
we can see with things like react-three-fiber that was coded in a weekend
initially and which is unthinkable in any other framework.

Edit typo

~~~
tannhaeuser
I'm not a React hater (in fact, I like it a lot _when it fits_ ) but I think
when people criticize React, they're actually after the one-size-fits-all
attitude displayed in comments such as yours. No, React is clearly not "the
only sane way of doing web development" considering the web hosts many types
of markup applications, the most successful ones predating React by decades.

~~~
crubier
Only _sane_ way, you missed a word. Of course there are other ways, but they
clearly flawed in my opinion. I used to hate web development before 2014 and
now I love it. Php is an awful language, jquery was a nightmare. Angular makes
no sense hence why it keeps reinventing itself, Vue forces you to have some
logic expressed using an ad hoc language in templates like it’s 2010 instead
of just using JS constructs etc...

I stand by my point, I am yet to find a use case where some form of react is
not the best solution. Whether it is server side rendered, a single page app,
or statically rendered.

The only criticism I hear about react boil down to people complaining about
bad practices that are not linked to react, but merely conflated with it, like
not caring about bundle size, messing architecture or other aspects that are
orthogonal.

~~~
izietto
> Vue forces you to have some logic expressed using an ad hoc language in
> templates

That's not true, you can use JSX with Vue, we do use that for one of our
clients and it hasn't raised issues whatsoever

~~~
crubier
You are right indeed, but from a developer point of view at that point you
could be using a react based framework and your experience would be the
similar to vue with JSX.

Render functions returning JSX is the key brilliant idea invented by react and
the fact that vue adopted it just proves the point even more:

React or the ideas at the core of react are not the mistake of the last decade
but the blessing of the last decade for web development (and more).

~~~
izietto
> from a developer point of view at that point you could be using a react
> based framework and your experience would be the similar to vue with JSX

It will not, because Vue has a better integration with the data source (Vuex)
and a better integration with the routing (Vue Router)

I mean, I agree that React is an awesome framework implemented upon great
design ideas (pure functions and plain JS templates), but it has its
shortcomings, that frankly make me still prefer Vue to React (mainly Redux and
the router)

~~~
crubier
For routing react-router is just perfect. And for data source/state management
there is plenty of choice, I use Apollo for global state/data source and
useState for small state full interactions, I can’t see how it could get
simpler.

But whatever floats you boat really, the point is that the nice part of vue
are inspired by react anyway. I wish the two community merged, to be honest, I
see no point in dividing for such small differences.

~~~
spaceribs
> But whatever floats you boat really

You specifically argued against that, your arguments seem to be highly
religious in nature.

I don't know how many years you've worked in the industry but if you think
React will be the dominant way of building apps for the next ten years, I have
some Adobe Flash developers who I'm sure would like to say a few words.

~~~
orange8
haha! Former hotshot Flash ActionScript 3 Ninja Developer reporting for duty
as requested.

Seriously though, JSX and TypeScript are nothing new. Both were part of
ActionScript 3, a big language backed by a powerful company (Adobe). 15 years
later, nobody even remembers it existed. How am I still making a comfortable
living coding today? By not getting too attached to any language or
framework... they are all just tools in the end.

So let the young ones be, time will eventually teach them those lessons,
sooner than they think.

~~~
pier25
Huh? AS3 had XML integrated into it?

I remember E4X and Flex but not a JSX like syntax.

~~~
orange8
It wasn't exactly like JSX, more powerful as the XML was just another program
data type to work with like strings and arrays.

------
rsinger87
Huge thanks Angular team. A few years ago, my team desperately needed to pick
and run with a frontend framework. After a couple months to learn the Angular
fundamentals, we haven't looked back. We find the framework to be extremely
intuitive and flexible enough to handle any scenario we've encountered. The
productivity wins have been enormous. We have about a dozen apps and anyone on
our small team can jump into any project and contribute. I can't imagine how
fractured our knowledge would be if we had to stitch together multiple
libraries and come up with our own constructs.

------
tashoecraft
Huge release with a lot of time and effort put into it. Congrats to the
angular team. Couldn’t imagine another framework putting in the amount of work
they did in order to insure Ivy goes well.

~~~
mgechev
Thank you! We're really excited to finally make Ivy generally available! ️

------
doczoidberg
Just want to say that all the Angular React comparisons are dumb. It is
comparing apples to oranges. Angular is a bigger framework for developing more
complex stuff. Therefore of course there is a steeper learning curve. Here are
comments like "react is so much more easier because it is just functions". Why
not just using vanilla js because you have nothing to learn then? Or just use
binary code? It is just 0 and 1.

~~~
spaceribs
I wholeheartedly agree, this is a false equivalency.

Angular was built specifically around avoiding an entirely different problem
that the heavily debated issue here of overengineering: Multiple teams that
build out complicated and feature laden systems in parallel need to make
concessions to allow interoperability.

If your organization is culturally flat, Angular prevents the core of your
application from diverging in unmaintainable ways.

------
dfsegoat
Is there still a clear path from angularjs 1.x onto angular 9.0? Anyone done
it recently?

Supporting a large 1.x codebase right now, and would love to start
incrementally moving to angular.

~~~
filoeleven
AFAICT the upgrade path is still the same (0) and...it looked pretty painful
when I first looked at moving from 1.x to 2.

I maintain a sizable 1.x codebase and am deciding what to move to, since 1.x
is dead next year. I just don’t see a good reason to go to 2+. It’s a
different framework. All of the UI libraries we built upon (ng-grid, angular-
ui) are either gone or different enough that we will have to redo all of our
code no matter what. If I have to switch frameworks anyway, I want to go with
something simpler (no custom module nonsense, no annotations, no hierarchical
dependency injectors, hell, no classes!) with a healthy ecosystem.

React with hooks, bootstrapped with CRA, is the clear winner for me. It’s just
so much more straightforward to reason about, and way faster to build things
with too. I made a toy app in Angular a year ago to check it out, and had a
hell of a time even getting the simple data model working right. With React,
day two had me already wiring up a dashboard with charted details that
responded to a calendar widget I had customized to show QoS at a glance. I was
looking at Vue too before I read up on react hooks, but once I saw functional
components everywhere I was...erm...hooked. Sorry.

Now if only I can convince them to let me use ClojureScript...

(0) [https://angular.io/guide/upgrade#using-a-module-
loader](https://angular.io/guide/upgrade#using-a-module-loader)

~~~
rubicon33
What is with this bazaar conviction that classes are bad?

~~~
e12e
Objects and messages good, classes and inheritance mostly bad.

Except maybe for modelling/simulating concrete classes of objects (ie, as in
Simula, the language).

Proper multiple dispatch (a la common lisp CLOS) seems rare - I'm guessing
java/c++ seemed like a sane trade-off for some type safety - but they probably
should've stuck to self/smalltalk (for Java) or looked to standard ml/common
lisp (c++).

I still don't understand why Javascript got classes, rather than some paint on
the prototype system.

------
thallukrish
I have spent a lot of time in Angular 2 and later in Angular 6. I had later
switched to plain java script and used requireJS to modularize. I have my own
orchestrator to route events like a pub-sub. HTML5 + CSS + plain JS is good
enough for most simple UI.

~~~
projectileboy
This is a (currently) under-rated approach that would apply well to many sites
today.

~~~
Cthulhu_
While I want to agree, at the same time I'm afraid of people creating their
own frameworks, re-inventing the wheel, etc. Mind you, Angular feels like a
very heavyweight framework, so that would be the other side of the coin.

Personally I wouldn't go for a vanilla JS application, not unless the script /
application part of it are minimal.

~~~
projectileboy
I should have been more clear - my point is not so much that people should use
vanilla JS rather than a framework, it’s more that the majority of SPAs I’m
forced to interact with could have been implemented just as well with HTML,
CSS, and a relatively small amount of JavaScript - small enough to not beg for
any kind of framework at all. If the nature of the app really truly demands a
full-blown SPA, then by all means go all in on something like React.

------
mnm1
How often do they release major versions? It seems every few months there's a
new major version update. Having been burned once with angular, combined with
this aggressive release schedule, by themselves are enough to make me not even
consider angular. It could be the greatest framework in the world and I still
wouldn't consider it. Not everyone is building throwaway prototypes and
garbage startup code. Many people need stable libraries and frameworks that
last many years and don't need time consuming updates and migrations
constantly. Angular is clearly not this.

------
qwerty456127
Why is Angular so less popular than React?

~~~
pacala
Angular: Learn about property binding, event binding, pipes, templates, views,
metadata, attribute directives, structural directives, services, modules,
components, injectors.

React: Write a function that generates a piece of HTML. Use standard event
handlers to manage user interactions. Update state via setState methods. Ship
it.

~~~
ng12
The first time I saw this in Angular's material implementation I was
completely floored:
[https://material.angular.io/components/dialog/overview#shari...](https://material.angular.io/components/dialog/overview#sharing-
data-with-the-dialog-component-)

The method for passing data to a dialog component is to import a magic
constant and inject a data field into it's constructor? It's a completely
over-engineered, nonsensical solution for a problem that doesn't even exist in
React. There's so much stuff you have to be familiar with in Angular just to
build the simplest features.

~~~
EugeneOZ
Don't use this library as an example of Angular code. I've written dozens of
Angular apps and none of them were so over-engineered. AngularMaterial is a
good example how to not design API. I'm sorry if it insults some people - we
all make mistakes, it's ok, I'm sure you'll next library will be better and I
understand it's too late to change API in a project, when some huge Google
apps are using it.

~~~
ng12
Not only is @angular/material the most popular component library by a huge
margin but it's maintained by the Angular team itself. If it's as bad as you
say it is that really doesn't inspire confidence.

~~~
chvid
Yes.

Take a look at what you have to go through if you want to create a custom
component in angular material (that can sit inside a form):

[https://material.angular.io/guide/creating-a-custom-form-
fie...](https://material.angular.io/guide/creating-a-custom-form-field-
control)

Something has gone completely wrong here.

------
Yuioup
I have a policy of only shipping "back-end" apps because I'm worried about
performance, browser compatibility and SEO. I don't know if the situation has
improved in Angular 9.

Does anybody here use Angular for their customer facing websites?

~~~
pjmlp
We follow the pattern Java/.NET traditional BE stacks, Vue and Angular (on
this order).

So far I have only deployed Angular once in production for an IoT Dashboard.

It was based on Material Dashboard, it was good enough for the monitoring use
case, but it was for on-premises deployment.

~~~
Yuioup
Yeah exactly. I do something similar (Angular, .NET Core) and use Angular for
apps that the customer never sees.

------
rawoke083600
I've been running the RC's at least the last 6 months or more, upgrading
usually within in day when the new one comes out. I've been impressed but what
I've seen is that even though A9 is very good (Well done developers) when the
real world hit you and your app. Its many times all the other nonsense you
have to include in your app that makes it big and slow (GAnalytics,GAdsense,
fb-pixel, crazyegg and and and) Still wouldn't want to code without it !:)

------
annnoo
There are no words on ESLint instead of the deprecated TSLint... :/ Would
really like to do the switch, but official support by Angular is more
important at my company.

~~~
theodorejb
It's on the roadmap for Angular 10: [https://github.com/angular/angular-
cli/issues/13732#issuecom...](https://github.com/angular/angular-
cli/issues/13732#issuecomment-573149865)

------
5cott0
What % of angular apps in production are <= 1.5?

------
eternalny1
I tried updating to Angular v9 from v8 and am getting an error regarding
strict mode and a "with" statement.

Anyone have any ideas?

[https://stackoverflow.com/questions/60114758/uncaught-
syntax...](https://stackoverflow.com/questions/60114758/uncaught-syntaxerror-
strict-mode-code-may-not-include-a-with-statement)

------
tommyjepsen
I just upgraded and got 'Failed to load module script: The server responded
with a non-JavaScript MIME type of "text/plain".' from my S3 through
CloudFront.

Seems like it's not adding 'type="text/javascript"' to <script> in index.html.
When adding this manually, everything works.

Just FYI if others upgrade and seem to get the same errors.

~~~
mgechev
My guess is you hit
[https://github.com/angular/angular/issues/30835](https://github.com/angular/angular/issues/30835).
In version 8 we introduced differential loading to allow users on newer
browsers to download smaller, modern bundles.

Modules, however, enforce strict mime type checking. As the comment below
suggests, you should make sure your static file hosting serves JavaScript with
the correct mime type.

------
no_wizard
Anyone know what the real world sizes of the bundles are now? Last I used
Angular I couldn’t get a bundle smaller than like 250-300kb

~~~
romanovcode
Real world e-commerce app without Ivy (Angular 8) is ~500kb gzipped

------
sgt
Angular 9 is out? The other day I thought version 4 was the latest one. It
sure moves fast!

------
radiKal07
What about AngularDart?

~~~
pjmlp
Flutter is now the only thing that matters to Dart devs.

[https://flutter.dev/web](https://flutter.dev/web)

~~~
adolfojp
It's interesting to see how Dart has almost been reduced to Flutter's Domain
Specific Language.

------
EGreg
Can someone here please do a serious overview comparing the latest:

    
    
      Angular
      React
      Web Components
    

Things are changing so quickly, I just wanted to sort of have an overview for
those of us who don’t work with these frameworks daily.

[https://blog.usejournal.com/web-components-will-replace-
your...](https://blog.usejournal.com/web-components-will-replace-your-
frontend-framework-3b17a580831c)

Can Web Components pretty much do everything without a framework now? I think
Ionic moved to it for example. If we already have our own code for loading and
rendering components, using Handlebars templates, what would we need to do to
make them into web components instead, or make all of ours compatible with the
latest React or Angular?

 _The specifics for anyone who cares:_

When we began our own framework, way before React and Angular, we built our
own, kinda “sane” reusable component engine. We called them “tools”. One tool
on an element is a component. But you could also add multiple tools on a
component, to add or remove behaviors:

[https://qbix.com/platform/guide/tools](https://qbix.com/platform/guide/tools)

Basically, we figured it would be easier to just let Templates, HTML, CSS and
JS each do what they were intended for.

 _HTML side_

1\. We had <div class=“Q_Tool Streams_chat_tool” data-streams-chat=‘{“foo”:
bar, ...}’> easily exporting json from php or templating engines, very
readable and completely standard (no JSX or custom components). It was just
slightly longer to write but provided useful metadata. It used to be called
_microformats_ back in the day. Multiple tools can be added on same element
this way. The element didnt have to be a div.

2\. We had handlebars helpers like {{&tool “Streams/chat” foo=bar}} and
Q.Tool.setUpElement(“div”, toolName, options), or pass an element instead of
“div” to add a tool on an existing element. We also had a jQuery fn method
like $(“foo”).tool(“Streams/chat”, options).activate() .

3\. Our users just called var element =
Q.activate(Q.Tool.setUpElement(“div”))) in vanilla JS or $(“<div
/>”).tool(...).activate() if jQuery was loaded.

* CSS side*

1\. We namespaced our CSS by Modulename_toolname_

2, Some tools took advantage of shared CSS classes defined in the module or a
module they depend on

 _Javascript side_

1\. We just had Q.Tool.define(toolName, constructor, defaultOptions, methods)
and the tool.state would be the options merged over the defaultOptions. It was
all customizable and merging was done via a smart Q.extend() function that we
tweaked to eg combine Q.Event handlers in the best way.

2\. Ways to access tools on an element would include Q.Tool.byId() and
element.Q.tools etc. The tool ids would be autogenerated so as to establish a
hierarchy of which tool was a parent. Then you could do
tools.children([filterName]) and tools.parents() and so on. Traverse faster
without touching the DOM.

3\. We had Q.activate(container, options) to activate tools within a certain
container. Javascript for tools would be loaded on demand, and tools would be
added/removed on demand. We had Q.Event.prototype.add(callback, key) take a
String key or a Q.Tool, so events would be automatically removed when a tool
was removed.

4\. You could also do Q.Tool.define([toolName1, toolName2], toolName,
constructor, defaultOptions, methods) to have tools require that previously
named tools already be activated on the element. This is for composability of
tools, something more general than inheritance. Let’s say you have a chatroom
and you want to add support for @mentions to it and
[https://linkscraping.com](https://linkscraping.com) as you type. So you’d
make tools that work in top of Streams/chat.

It seems to me that ANYWAY your user will have to load a Javascript file that
defined your web components. And ANYWAY they will have to load javascript on
demand. And ANYWAY this javascript may be packed into a single file so you’ll
have to actually check whether a variable has been set before loading modules
_dynamically_ so you dont want static loading. And ANYWAY your tools may want
to use shared css so you may as well namespace your CSS. And ANYWAY your
default options may include event handlers or other things you can’t serialize
easily into attributes of an element. And you may want to compose tools or
find them with CSS so what’s wrong with using CSS classes instead of the
element name for that? And ANYWAY you will want to render your tools in a
readable way so why not stuff JSON into data attributes which were allowed for
exactly such purposes? And ANYWAY you may want to use a powerful templating
engine like Handlebars. The only part I am not sure of is the last one.

Seems to me - but I am biased - that we have the optimal approach. If
something else comes out we can just turn Q.Tool.define into a wrapper around
window.customComponents.define. But our users won’t have to change a thing.
They can continue to use Q.Tool and Q.Page and Q.exports(arg, arg) and
Q.requires(module, callback) without worrying what’s underneath. Isn’t it
better and more stable?

But everyone got into Angular and React with its JSX etc. I think the main
sell was the dirty checking (the model in Angular, the DOM in React). So you
can just render a large chunk. I never saw the benefit of that. You _should_
reason about mutations imho. Components are views with their own viewmodel,
that’s all. You can update a bunch of state parameters and then call
stateChanged(“a”, “b”) which would requestAnimationFrame() and update stuff.
Is it so hard to call stateChanged() after changing state.a and state.b ? Do
you really need to instead grok digest cycles or a virtual dom??

------
DonHopkins
I've been going down the long road of learning Angular recently, and I love it
and want to learn more, but I have a couple naive newbie questions whose
answers I thought should be obvious, but I haven't been able to figure out:

Is there a standard way to define local variables in an Angular template so
you don't have to repeat the same redundant expression again and again (or so
you can at least give an expression a self documenting variable name so it's
not so mysterious)? Or do you have to define an instance variable on your
component and figure out how to initialize it to the right value before the
template gets executed, with no way to lazily (or repeatedly) evaluate it by
putting the calculation inside conditionals (or loops) in the template so
they're not run if they're not needed (or to calculate the local variables
independently for every loop iteration)? Is there an angular hook or technique
that's meant for that, and efficient, and hopefully doesn't involve much
arbitrary non-JavaScript gobbledygook syntax, and is at least somewhat
standard and well supported? Please don't tell me I shouldn't ever want to do
that for some reason of ideological purity or separation of concerns (as if a
templating language could ever be called "pure" or "elegant"). The common
legitimate use case is ngIf="some expression is not null" then {{some
expression}}, and also ngIf="some expressions" ... ngIf="not some expression".

I googled for it, and the solutions of "abuse ngIf's special goofy syntax to
name the result of the condition and pray to God it's truthy or don't bother"
and "abuse ngFor to loop over an array of one item to give it a name" are not
acceptable answers. There were also a few competing and possibly out-of-date
"install this non-standard ngLet directive that I hacked up but don't support,
but don't call it with an "ng" prefix because that's reserved for the Angular
team" \-- but isn't there a standard way of doing such a simple essential
thing, that the Angular team already thought of and included, such that other
people will have some clue what's going on when they see it? And it would be
nice to be able to define more than one variable at once per begin/end tag, if
you know what I mean. Maybe even without using any begin/end tags, perchance
to dream?

Also, is there a way to easily define simple light weight macros ("snippet
reuse") so you can repeat the same pattern in one or more components, without
defining a whole component in all its glory and splendor with multiple files
that other multiple files need to import and declare? Or even a global file of
shared macros that a bunch of other templates can import, like the globally
shared css declarations you can include in local css files? I've seen "ng-
template", but I am having a hard time getting my head around it, compared to
the simplicity and power of Genshi's py:match, that's based on xpath, and
py:def, that precisely follows Python function calling conventions and that
you can easily call from any normal expression. And py:match is quite useful
for defining concise custom tags (or xpath patterns) that can wrap embedded
content. In comparison, ng-templates seems quite clumsy and limited, and
confusing about calling and scoping and passing parameters and content, which
is nothing like standard JavaScript calling conventions, and reminds me more
of the abomination that is Zope METAL templates.

[https://zope.readthedocs.io/en/latest/zopebook/AppendixC.htm...](https://zope.readthedocs.io/en/latest/zopebook/AppendixC.html#metal-
overview)

[https://en.wikipedia.org/wiki/Template_Attribute_Language#ME...](https://en.wikipedia.org/wiki/Template_Attribute_Language#METAL)

[https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates](https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates)

I've been using and loving Genshi with Python for more than a decade (and
before that, Kid, which Genshi is almost the same as, and before that Zope
page templates, TAL, and METAL templates, which inspired Kid and Genshi, but
totally sucked), and I love its ability to drop into Python with <?python ...
?> to define some variables or import some functions locally in the template
that you can use, with real honest to god multi-line indented Python "if"
statements for logic (and Python comments for, err, commenting) instead of
Christmas trees of deeply nested ternary ? : operators (or rather postfix
conditional "foo if bar else baz" Python expressions). Genshi also has "with"
for defining scoped local variables with tags, like <py:with vars="y=7;
z=x+10">$x $y $z</py:with>.

And I also love Genshi's py:def for making locally defined or libraries of
includable imperative "code snippet" templates you can call just like Python
functions (with glorious optional named defaulting args, etc), and py:match
for declaring xpath pattern matching templates that can wrap html content as a
parameter (so the macro can cherry-pick out and transform different parts of
the passed content with xpath), as well as taking attribute parameters.

Another nice feature of Genshi is that for all directives it supports both the
attribute form like <div py:if="condition"> ... </div> attached to an element
that you want to keep, or the element form that dissolves without leaving an
element, like <py:if test="condition"> ... </py:if> . You can also attach
multiple directive attributes to the same element, thanks to the way it
executes them in a well defined ordered hierarchy that makes practical sense
(like "for" above "if", so each iteration of the "for" loop can be
conditionalized with its own "if" evaluation), and "def" above all else, so
you can define a single tag macro that loops over something then
conditionalizes each iteration, then sets attributes on and adds content to
the included elements. It's quite concise and expressive!

<div py:def="FizzBusted(count)" py:for="i in range(count)" py:if="i % 3"
py:attrs="{'class': 'orange' if i % 7 &lt; 2 else 'blue'}" py:content="['odd',
'even'][i%2]"/>

[https://genshi.edgewall.org/](https://genshi.edgewall.org/)

[https://genshi.edgewall.org/wiki/Documentation/xml-
templates...](https://genshi.edgewall.org/wiki/Documentation/xml-
templates.html)

py:def

[https://genshi.edgewall.org/wiki/Documentation/xml-
templates...](https://genshi.edgewall.org/wiki/Documentation/xml-
templates.html#id4)

py:match

[https://genshi.edgewall.org/wiki/Documentation/xml-
templates...](https://genshi.edgewall.org/wiki/Documentation/xml-
templates.html#id5)

Processing order of multiple attributes (precedence rules you must remember,
but they make practical sense, and at least Genshi is quite minimal and only
has a few directives): py:def py:match py:when py:otherwise py:for py:if
py:choose py:with py:replace py:content py:attrs py:strip

[https://genshi.edgewall.org/wiki/Documentation/xml-
templates...](https://genshi.edgewall.org/wiki/Documentation/xml-
templates.html#processing-order)

These two features (local variables and code snippets) are so important to me,
and I'm having such a hard time figuring out how to do them in Angular, that I
feel like there's whole a chapter in the Angular templating manual that I
missed somehow. Thanks for any tips on how to do this kind of stuff with
Angular templates!

I've written more opinions about Genshi and templating on hn before:

[https://news.ycombinator.com/item?id=8445252](https://news.ycombinator.com/item?id=8445252)

[https://news.ycombinator.com/item?id=10842990](https://news.ycombinator.com/item?id=10842990)

[https://news.ycombinator.com/item?id=12365442](https://news.ycombinator.com/item?id=12365442)

[https://news.ycombinator.com/item?id=12527839](https://news.ycombinator.com/item?id=12527839)

[https://news.ycombinator.com/item?id=16677520](https://news.ycombinator.com/item?id=16677520)

[https://news.ycombinator.com/item?id=20745676](https://news.ycombinator.com/item?id=20745676)

[https://news.ycombinator.com/item?id=10842902](https://news.ycombinator.com/item?id=10842902)

~~~
mattlondon
> Is there a standard way to define local variables in an Angular template so
> you don't have to repeat the same redundant expression again and again

I usually define something in the component, and reference that. If you need
to lazily evaluate it you can just reference a function in the component (e.g.
"...{{ someFunction() }}...", and have the function do whatever lazy work
and/or memoisation you need there.

If you need things to be initialised before the template is ready, you can use
one of the life cycle hooks - e.g. ngOnInit(). More details of the different
hooks here:
[https://angular.io/guide/cheatsheet](https://angular.io/guide/cheatsheet)

... that said, it _might_ be easier (depending on context) to "learn to love
the bomb" and just rely on Angular's binding to update the template as soon as
the value becomes ready after the template has rendered - i.e. don't sweat
about getting everything ready before the template loads, just let Angular
handle the data binding and let it update the tempalte when the value _is_
ready. This is where the RxJS stuff really shines since you can forget about a
lot of the sequencing and just let Angular handle getting the right value on
the page when it becomes available. Unless you are doing long network calls or
heavy computation, everything is usually in place by the time your brain
registers seeing the page anyway so it mostly works out OK and no one notices
any thrashing of templates going on under the covers (... although there is a
part inside of me that dies when thinking about the performance/wasted CPU
cycles).

> is there a way to easily define simple light weight macros ("snippet reuse")
> so you can repeat the same pattern in one or more components

I have also suffered this recently. I am not sure how this is "meant" to be
done, apart from making everything a separate component. I guess the argument
is, if you need to use something in multiple places then it is an ideal
candidate to become a component. For these "lightweight" components I will
usually just use inline templates for the component decorator (rather than
referencing a separate HTML template etc), e.g.

    
    
      @Component({selector: 'snippet-one', template:`<b>My First Snippet</b>`}) export class SnippetOne{}
    

You can put a load of them into a single "snippets" module, import the
"snippets" module when you need it, and then simply include that where I need
it in other templates with <snippet-one></snippet-one> and so on.

I agree though that sometimes it would be nice to just have a file you can
just easily drop in where you need it.

~~~
DonHopkins
Here's another newbie question, if you don't mind: What would be the optimal
place to hook to get a callback to draw something in a canvas whenever the DOM
is updated?

I'm currently subscribing to changes in a BehaviorSubject<any[]> instance
variable of my selection service "god object":

selection service:

    
    
        public user$: BehaviorSubject<any[]>;
    

my subscribing component:

    
    
        constructor(
            public selectionService: SelectionService
        ) {
            this.userSubscription$ = selectionService.user$.subscribe(user => this.drawUserInCanvas(user));
        }
    

Is that a good way, or might I miss updates for changes to component instance
variables and other reasons? Is there a canonical Angular callback that's
recommended for stuff like drawing a canvas view after any changes have been
made to the DOM?

Thanks for the advice!

~~~
mattlondon
You can use ngOnChanges callback to react to changes in the angular framework
- i.e. if bindings/@Input()s/etc have changed and you want to do something
special there when they change. But for just generic DOM changes happening
outside of the angular framework that wont work (since angular does not know
about random other DOM stuff going on elsewhere in the page and outside of the
framework). E.g. if there is some static JS code in the page doing stuff to
the DOM, angular won't trigger ngOnChanges for that.

For your approach, that looks reasonable to me in the 5 lines we have to look
at :-) ... so long as you are consistent with the SelectionService and make
sure all the changes go through that, you should be fine and your component
will get all the updates.

This sort of requirement for consistent management of things like this - i.e.
the application state - is a weakness of Angular I think. It is easy to start
simple and end up coding yourself into a corner with god services etc. I have
used a thing called NgRx in the past for managing state - its the redux
pattern and seems to be quite good at making sure state is a bit more sane and
well-mananged in the app (at the cost of some boilerplate). One day I hope
that there is an official state management mechanism.

~~~
DonHopkins
Thanks, that sounds like the right approach. I don't need to react to all DOM
changes, but I have one jolly callback for changes to my one big happy god-
owns-the-user-owns-the-world object (the observable), but the component has
view-level properties like hiding and showing details, zoom and pan, etc, that
aren't in the observable model, and I'd still like to redraw the canvas when
they change. It doesn't take long to draw, but I just don't want to miss any
updates, or have to pepper the code with explicit calls to redraw it every
time I think something might have changed (causing a lot of pointless
redrawing).

Fortunately my app is simple enough that I can just redraw everything whenever
something changes, as long as I'm not doing it 37 extra times.

------
grkg8tr
How does Aurelia compare?

~~~
DigitalSea
In my opinion, Aurelia has always been the less complicated and lighter option
of the two. Aurelia 1 had some design choices that made it harder to tree
shake down, but Aurelia 2 is around the corner with AOT and numerous
optimisations that looks like will put it at the top of the benchmarks again.

