RXJS 7 was recently released to much fan fare, but buried deep inside the release was the deprecation of the “toPromise()” method on the Observable type.

For example, this sort of code :

let myPromise = myObservable.toPromise();

Now gives you the following warning :

@deprecated — Replaced with firstValueFrom and lastValueFrom . Will be removed in v8

That last point is the most important thing here. Not only is it deprecated in RxJS 7, but come version 8, it will be completely gone. That’s big, because often libraries deprecate methods but keep them around for backwards compatibility, but not this time!

Luckily, there is a simple work around that doesn’t require much of a change at all to how you were already using toPromise().

Using FirstValueFrom and LastValueFrom

FirstValueFrom and LastValueFrom are new utility methods inside RxJS 7 that more or less give you the same functionality as toPromise(), just in a different format. To use them, simply import from rxjs and give them a whirl!

import { firstValueFrom } from 'rxjs';
let myPromise = firstValueFrom(myObservable);

firstValueFrom does exactly what it says on the tin, it waits for the very first result from the observable, returns it as a promise, and unsubscribes from the subject.

lastValueFrom however, waits until “complete” is called on the subject, and then returns the last value it received. It’s important to note that if your subject never calls complete, then your promise will never be resolved.

Why?

The obvious question would be, why? Why remove toPromise() in favor of adding static “helper” methods. There’s actually a simple reason.

When using toPromise(), if the Observable completed without ever emitting any value at all, the Promise would resolve with a value of undefined. However, when you were using this in code, it was impossible to tell if the promise itself returned undefined, or it returned nothing. This has been the case ever since RxJS was released.

To be able to differentiate between no value, first value, or last value from the Observable, it was decided a static method, off the Observable prototype was a better solution than changing the behaviour of the toPromise() method all together.

Over the past couple of months I’ve been doing battle with an Angular Universal project. Angular Universal is Angular’s answer to Server Side Rendering or SSR for short. Why use SSR? In most cases it’s for SEO purposes but in some cases it also gives “perceived” performance.

For SEO, when opening a link to an SSR website, Angular renders the complete (Or semi-complete) page on the server, and returns the HTML that can be read by search engines (and other robots).

When I say “perceived” performance, what I mean is that because it’s atleast semi-rendered,  a user doesn’t see a flash of a blank screen like you normally get with regular Angular apps. I personally don’t think it really returns the complete page any faster than a regular Angular App, but the first paint is more “complete” than that of a regular Angular app.

It sounds good on the surface, but just try and have a quick search for how many people are actually using Angular Universal in production – there’s not many. Almost every tutorial you find on the subject is the Angular Universal equivalent of a “Hello World”. I won’t say I’m an expert on Angular Universal, but I wanted to write this article to maybe show you a couple of things that every tutorial leaves out of the conversation.

Library Support Is Rough

The first thing you probably learn when using Universal is that when the page is rendered on the server, it doesn’t have access to a couple of really important (common) javascript paradigms. Among them, you can’t access the window object (Since this refers to the browser window of which there isn’t one when doing server side rendering), you can’t access things like localStorage or any sort of memory that might live inside a browser window like Session Storage. Cookies are also a bit of an issue for obvious reasons.

Angular recommends you wrap things that need to access these objects inside a method called isPlatformBrowser so that you can check if you are in that moment doing server side rendering or if you are doing it in a browser. (More info here https://github.com/angular/universal/blob/master/docs/gotchas.md).

But, that’s with your code. What about something like an authentication library that uses localStorage? Like the MSAL library from Microsoft that allows your javascript application to integrate with Azure AD. They have a great Angular package that makes authentication a cinch. But they obviously haven’t gone and wrapped everything in browser checks. Why would they muddle their code with that when very very few people are using Angular Universal anyway?

And I ran into this same problem many times over. Even just libraries that try and access the window object (which has to be pretty common in javascript), they are going to completely bomb out when running inside Angular Universal. Of course, you can always fork the code or try and add in a bunch of browser checks yourself, but the point is is that all those libraries that were plug and play on your last project suddenly become a headache to get integrated.

Development Is Extremely Slow And Confusing

Let’s face it, building Angular Universal bundles are slow. When you have a plain Angular app and you run “ng serve”, it’s snappy. The watchers are fast and changing a couple of lines typically only takes a couple of seconds to recompile. I’ve found Angular Universal to be the exact opposite. Often with recompiles taking almost the exact same time as the initial compile. Those jokes back in the day of “can’t work, code recompiling” when you were working on mainframes are back!

I also found debugging of Angular Universal apps incredibly complicated and often confusing. You see it’s only the *initial* request that is server side rendered. As you click around the site, you are then inside a regular Angular app and therefore everything is client side. But common debugging tools like console.log() become very confusing to follow because if it’s an initial request, that log will be written on the server, not in the browser, all subsequent logs will be written to the browser. Same goes for any debugging tool you might use. The initial request would be like debugging a typical Express application, but all subsequent requests can be debugged just fine from the browser. Trying to bring a new developer up to speed is pretty damn difficult.

Documentation Is Terrible

Finally. The documentation is terrible. Angular Universal has one, yes one, page of documentation here : https://angular.io/guide/universal. That’s it. I even had to log a bug that the sample application they provide doesn’t actually compile at all. And they closed it was they were “working on it”. So not sure how hard it is to just provide a working example of an Angular Universal app, but evidently it’s still not been updated.

Beyond the official documentation, you typically rely on other examples and blogs floating around on the web that really only scratch the surface of what Angular Universal does. If you run into any roadblocks at all, you are pretty much on your own because as far as I’ve seen, no one actually uses Angular Universal in any large commercial capacity (Happy to be proven wrong though!).

Should You Use Angular Universal?

I’m a big believer in using the right tech for the right purpose. As it stands right now, I believe that if you need server side rendering, then don’t use a client side javascript framework to do it. While it’s not too hard to turn any app into Angular Universal. On any project of reasonable size, you’ll start hitting roadblocks thick and fast and soon realize that Angular Universal is a fun POC, but not a commercial offering.

Angular 9 was released on Februrary 7th, 2020. Generally speaking, this isn’t a flashy release with lots of goodies, but instead a release that gives a huge (needed) update to plenty of behind the scene components.

Angular Ivy

Angular Ivy is the name given to Angular’s new compilation and rendering pipeline. Essentially when you build and package your Angular app, the HTML, JS and CSS you have written is all compiled and packaged up to be delivered to a users browser. While the way you write code doesn’t change, the way Angular builds thing has changed dramatically without you having to do anything. This results in :

• Faster build times (Which is massive if you do any sort of git pre-commit hook using ng build!)
• Smaller build package sizes (Less to deliver to the client results in your page loading faster)
• Better understanding of how modules fit together unlocks better tree shaking, ability to lazy load components etc.
• Improved CSS and style binding

And a tonne more!

Probably the most exciting thing to me are the first two. Faster build times is huge to me as I like to do a full build before checking any work in just to make sure everything is playing nice, but the slow down in commiting even a one line change is pretty big right now. Secondly, the smaller build packages are pretty amazing. There is this official image floating around that demonstrates the difference :

40% size decrease!? Sign me up!

What Else?

I get that Ivy maybe isn’t the most exciting thing in the world if you were looking to get your hands on something new and shiny. Angular 9 does have a bunch of bug fixes and deprecations, but nothing new that will completely blow you away. In terms of methods being deprecated, you can see the full list here : https://angular.io/guide/updating-to-version-9. Most notably are things like Renderer becoming Renderer2, and the <ngForm> tag becoming <ng-form>. Nothing too spectacular.

Upgrading

To update your existing application to Angular 9, simply run :

ng update @angular/cli @angular/core

If you’ve ever sifted through job boards or even stackoverflow when it comes to Angular, you will see people use the terms “AngularJS” and “Angular” interchangeably. Or atleast that’s what it can sometimes appear to be. But AngularJS and Angular actually refer to two very different versions of Angular. While learning one basically gets you half way to learning the other, they are not necessarily interchangeable. So what’s the difference?

AngularJS Is Angular 1

Before we jump into the actual differences between AngularJS and Angular. The first thing you need to know is that the term “AngularJS” is typically used to refer to the very “first” version of Angular, Angular 1. When Angular 2 rolled out, it had tonnes of “breaking” changes from version 1. Infact it was a completely different architecture! Where Angular 1 used things like Controllers and used Scope/Rootscope, Angular 2 did away with these and made everything in your app a “component”.

Naturally some were adverse to such a hard shift and given that many applications were already written in version 1, people didn’t want to have to go through and update their entire application architecture so they stuck with it. Even as further versions of Angular rolled out (Angular 4, 5, 6 etc), Angular 1, now called AngularJS, received it’s own updates with things like performance boosts and security upgrades. For some, this meant AngularJS was still a very viable alternative to creating a Single Page App without having to re-learn a new framework.

Feature Comparison Between AngularJS And Angular

As mentioned above, Angular 2 introduced a completely new architecture of “everything” being components. Because of this you could almost say it’s a different JS framework, but I’ll try and list out a couple of important differences between the two versions.

• Angular uses Typescript (as default but you can use Javascript also) while AngularJS uses plain Javascript.
• Angular makes everything a “component” and you use these as blocks to create your app. While AngularJS is primarily MVC (Model-View-Controller) based.
• Angular makes uses of it’s own CLI to create components, run tests, serve the app etc while AngularJS does not have a CLI at all.
• Angular has it’s own inbuilt packaging system using Webpack while AngularJS requires you to roll your own (Often Gulp, but you can also use Grunt or Webpack)
• AngularJS requires different attributes to say whether you want two way or one way binding (e.g. ngModel vs ng-bind) whereas Angular just uses [] or ()
• Angular has a component based CSS encapsulation concept, AngularJS does not
• Angular supports server side rendering, AngularJS does not

This is by no means an exhaustive list. Realistically, I could list out many “annoying” gotchas with AngularJS that were fixed in Angular 2+. For example data binding in Directives is a right pain to learn in AngularJS and is by no means intuitive, you need to learn crazy text symbols to work out how multi directional binding works :

{
   scope: {
     text: "@myText",
     twoWayBind: "=myTwoWayBind",
     oneWayBind: "&myOneWayBind"
   }
}

Whereas in Angular this is just so much more intuitive.

Should You Start A New Project On AngularJS Or Angular?

Angular. 100% Angular.

On July 1st 2018, AngularJS entered into lifetime support mode. This means it’s not actively being worked on (feature wise), and new releases will only contain security fixes or critical bugs caused by a new browser version. This is expected to last until June 2021 at which point support will end. So at best the AngularJS you have right now will continue to be the same in the future, and at worst from mid 2021 onwards your framework will no longer be “supported”.

Angular just fixes so many issues with AngularJS with a very small learning curve. If you know AngularJS already, then getting started on Angular won’t be a hassle at all. If you are starting fresh and thinking of building your first SPA, there is no reason to pick a framework with notable gotchas that will run out of support in a years time.