Angular 12 has just been released. Time to discover what’s new!

In this article, I’ll go over (almost) everything noteworthy in this brand new release. I’ll also highlight what’s changed around Angular, just like I did with my previous articles about Angular 11 and Angular 10.

If you’re just looking for the bird-eye view, then check out the official release announcement. Here, I’ll dig much deeper into the release notes.

Join the Ivy league…

The Angular team has been working on Ivy (the new compilation & rendering pipeline) since 2018. It was finally released with Angular 8. Since Angular 9, Ivy has been the…

Learn how to migrate your applications to Tailwind 2.1+, and how to enable Tailwind’s Just-In-Time mode.

Update 2021–04–06: Adapted the content after the release of Tailwind v2.1

About two weeks ago, Adam Wathan announced a new Tailwind experiment: Just-In-Time. Since then, Tailwind 2.1 has been released and it introduces official support for this new feature.

In this article, I’ll tell you what it’s all about, and how you can take advantage of it.

WARNING: Tailwind’s Just-In-Time mode is still in preview at this point in time. …

In very rare circumstances, you might want to delay the loading of your Angular application. In this article, I’ll show you how you can do it.

Warning: Don’t do this lightly. Carefully evaluate if you really need to do this, as it can have a devastating effect on user experience!

Angular module import side-effects

In my previous article, I’ve briefly explained the Angular application bootstrap process. One thing that I mentioned there is that the import statements remain at runtime, and are taken care of by Webpack.

What I didn’t mention though is what happens as soon as Webpack imports an Angular module; for…

In this article, I’ll give you an overview of how Angular applications are bootstrapped. Note that this is an article for beginners, not a deep-dive.

High-level process

For an Angular application to start, multiple things have to happen within the Web browser:

• The HTML of the entry point must be loaded
• The different JavaScript bundles of the application must be loaded
• The main bundle of the application must be executed
• The main bundle must load Angular and trigger the bootstrap of the root Angular application module
• Angular must bootstrap the root Angular application module, and render the application

Let’s look at those…

Last month, I wrote a lengthy post to share my story as a SaaS startup founder: https://medium.com/swlh/20-months-in-2k-hours-spent-and-200k-lost-a-story-about-resilience-and-the-sunk-cost-fallacy-69fd4f61ef59

This is what happened next.

In that article, I’ve explained what I’ve gone through during the previous 20 months; all the time and effort spent trying to create a product, and not succeeding (yet).

I wrote that honestly, sharing my thoughts about the ups and downs, and the struggle to accept or reject the idea that I had fallen for the sunk cost fallacy.

In this article, I’m sharing my lessons learned since last month, and how writing that article last month influenced…

Recently, I’ve been doing some research around Next.js & GraphQL.

After looking into the back-end side (which I’ll write about another day), I wanted to test drive some libraries for querying my GraphQL API.

Of course, since I was using Apollo on the back-end, it made sense to go full-circle and use Apollo on the “client-side” too.

In this article, I’ll explain how I’ve integrated it into my Next.js application. Since you know me, it should be obvious that the application uses TypeScript!

Note that I’m no Next.js specialist (nor a React one :p) and thus, I might be wrong…

Back in 2019, I wrote a short cheatsheet about the Design Sprint 2.0 approach. It’s been sitting on my Google Drive, and I thought that it may be useful to others, so here goes!

This isn’t an introduction to the approach, so if you’ve never heard of design sprints, you should probably check out the Sprint book of Jake Knapp (the creator of Design Sprints).

In two words though:

Design Sprints are workshops, spread out over about a week of time (depending on which variation you use), during which your team will try to solve a big design challenge, and…

As some of you might know, I’m working on a book about Software Development Concepts.

Among many other things, the book will cover the basics of User Experience (UX), User Interface (UI), and Customer Experience (CX).

Tonight, I wanted to help my readers to visualize the difference between those. Here’s what I’ve come up with so far:

This diagram is directly inspired by the one published here by Michael Janda, extended with some ideas of mine.

Now that I have created the visualization, I can continue explaining those concepts… one by one ;-)

That’s it for today!

PS: If you have ideas/remarks about this, don’t hesitate to comment, I’m curious.