DEV Community

Cover image for Angular: The Framework of Past, Present, and Future
Santosh Yadav for This is Angular

Posted on

Angular: The Framework of Past, Present, and Future

Photo by Drew Beamer on Unsplash

I started using Angular in 2017 when version 4 was released. And I have seen this framework growing since then. In this blog, let's see why Angular is a framework of Past, Present, and Future.

AngularJS and the Start of Angular

AngularJS was released in 2010 and was one of Google's first Open Source front-end frameworks. It was open-sourced and lived for 12 years before reaching the end of life in 2022.

AngularJS introduced a new way to write the html templates. It introduced directives like "ng-for, ng-if," which paved the way for many other frameworks and rendering engines.

The AngularJS team quickly realized it's difficult to maintain a vast codebase written in JavaScript. And a rewrite of AngularJS called Angular was announced in 2014.

Choosing the best tool for the job

Angular is known for deep diving into the existing tools before picking the best for the job. Let's see the tools chosen by the Angular team over the years.

Past

When Angular development started, Angular Team decided to use Typescript, which was very new in 2014, and many didn't like it. Some chose not to use it and moved to another framework where they could use Javascript.

But everyone has realized the true power of Typescript over the years, and most developers now choose and prefer Typescript over Javascript.

2014 was the time many build tools for Javascript started appearing. I remember using Grunt and Gulp. Even when the early version of Angular appeared (2.0), SystemJS was used, and developers had to configure everything independently. With Angular 4.0 Angular team introduced Webpack and CLI, and all the configuration was hidden from the developers. Webpack served as the best and most stable tool over the years. It became a tool trusted by many other frameworks and developers.

There was a time the Angular team considered introducing Bazel as the build tool. Bazel is a great tool, but introducing it might have complicated the development effort, as it is hard to understand. The angular team decided not to take that path.

Present

Angular still uses Webpack and has experimental support for esbuild. The team realized its time to move on and chose other tools better than Webpack.

CLI has improved over the years, enabling smooth migrations between Angular versions. Check out https://update.angular.io/

Future

After considering many build tools, Angular will invest in esbuild, which will be used for building Angular applications.

But vite is the hottest tool now; you said, yes team decided not to use it as it was not the best fit for building Angular applications. Still, it will serve applications using vite when you are doing the dev build.

Rendering Engines

Angular uses a compiler to build and produce the final build output, which generally goes through multiple tools. One of them is the rendering engine; the Angular team has iterated over the rendering engines numerous times, and Ivy is the current generation which has unblocked the Angular team to introduce great features like the Standalone component.

Focus on Reactivity

Past

Angular wanted developers to write more reactive code from Day 1 and chose the best tool present RxJs. For APIs like HTTP and Router, Angular used RxJs internally; even for EventEmitter RxJs Subject was used.

Present

RxJs usage has grown over the years, and more and more developers are using this powerful library. Still, many developers asked for Angular without RxJs. Many want better integration of Angular with RxJs.

Future

The angular team is experimenting with Signals, and there will be a public RFC soon. Signals will reduce the learning curve, which was required for RxJs. Still, it will also introduce APIs to better integrate with RxJs.

Change Detection

Past

Change Detection has always been a very critical part of any framework. The angular team introduced zone.js very early to take care of change detection.

Present

Angular still uses zone.js, but soon it started giving performance issues for large apps, and developers had to figure out how to improve the performance. OnPush change detection strategy is widely used to improve performance. Libraries like RxAngular allow you to disable zone.js but need some refactoring.

Future

We, developers, should focus on writing more quality code rather than caring about change detection. Yes, this is the policy the Angular team has decided to go with. With the introduction of Signals, zone.js will become optional, and you can care less about Change Detection strategies.

Do not leave anyone behind policy.

Angular has a release cycle of 6 months, which means there will be a new major release every 6 months. And the version has support for the next 18 months, which means if you have been on an Angular version for more than 18 months, chances are the version is not supported anymore.

But Angular has your back. For any new version release, Angular CLI offers an automatic migration. You need to run ng update and relax.

You can read the docs to update Angular between multiple versions

ng update 
Enter fullscreen mode Exit fullscreen mode

Great Set of features

Over the years, the Angular team has interacted more with the community and worked on some excellent features.

inject function

One of the most loved features of Angular is DI (Dependency Injection). We all love it. With inject, function Angular team made the developer experience even better.

Let's see an example before and after:

@Component({
  selector: 'app-employee-details',
  templateUrl: './employee-details.component.html',
  styleUrls: ['./employee-details.component.scss'],
})
export class EmployeeDetailsComponent {

  modes$ = this.route.queryParamMap.pipe(
    map((params: ParamMap) => params.get('mode'))
  );
  userName$ = this.route.paramMap.pipe(
    map((params: ParamMap) => params.get('username'))
  );

  employeeId$ = this.route.paramMap
    .pipe(
      map((params: ParamMap) => params.get('employeeId'))
    );
  constructor(private route: ActivatedRoute) { }

}
Enter fullscreen mode Exit fullscreen mode

With inject function

@Component({
  selector: 'app-employee-details',
  templateUrl: './employee-details.component.html',
  styleUrls: ['./employee-details.component.scss'],
})
export class EmployeeDetailsComponent {
  modes$ = inject(ActivatedRoute).queryParamMap.pipe(
    map((params: ParamMap) => params.get('mode'))
  );
  userName$ = inject(ActivatedRoute).paramMap.pipe(
    map((params: ParamMap) => params.get('username'))
  );

  employeeId$ = inject(ActivatedRoute).paramMap.pipe(
    map((params: ParamMap) => params.get('employeeId'))
  );
  constructor() {}
}
Enter fullscreen mode Exit fullscreen mode

Template:

<h1>
   Employee Details for EmployeeId: {{employeeId$ | async}}
</h1>

<h2>Current Mode: {{ modes$ | async }} </h2>
Enter fullscreen mode Exit fullscreen mode

Standalone components

The angular community has been asking Angular Module less Angular for a long time. I still love Angular Modules, it still has their place when structuring your apps, but we can usually work without them. Not having Angular Modules reduces the mental modal and learning curve. So now we have Standalone Components, Standalone Component does not require to be registered with any Angular Modules, and it still has backward compatibility, meaning you can use them in an Angular Module.

import { Component, OnInit } from '@angular/core';
import { MatTableModule } from '@angular/material/table';
import { MatPaginatorModule } from '@angular/material/paginator';
import { MatSortModule } from '@angular/material/sort';

@Component({
  selector: 'app-user',
  templateUrl: './user.component.html',
  styleUrls: ['./user.component.scss'],
  standalone: true, // Standalone flag to differentiate between component with module
  imports:[
    MatTableModule,
    MatPaginatorModule,
    MatSortModule
  ] // you can import Angular Module, Standalone Component/Directive/Pipe here
})
export class UserComponent implements OnInit{

  constructor() {
  }

}
Enter fullscreen mode Exit fullscreen mode

Standalone APIs

To take the Standalone Component experience to the next level, Angular introduced Standalone APIs, its already available for Router and HttpClient, and even libraries like NgRx also introduced the Standalone APIs.

Let's see the code sample below to use Standalone APIs for Http and Router


providers: [
    provideHttpClient(),
       provideRouter(
      routes,
      withDebugTracing(),
      withEnabledBlockingInitialNavigation() //required for SSR
      withHashLocation(),
      withPreloading( PreloadAllModules),
      withRouterConfig({
        onSameUrlNavigation: 'reload',
      })
    ),
]
Enter fullscreen mode Exit fullscreen mode

Standalone Component Migration

Of course, we now have Standalone Components but think about the effort you and your team have to go through to convert all components to Standalone, dont worry; the Angular teams have your back, run the below command and migrate all components, directives, and pipes to Standalone, Happy migration.

ng generate @angular/core:standalone
Enter fullscreen mode Exit fullscreen mode

functional guards

Router guards are great, but we had to write a service every time we had to write a guard. It all changed with the introduction of the functional guard. Guards can be a function now. No need to write a class anymore.

const authGuard: CanMatchFn = () => {
  const authService = inject(LoginService);
  const router = inject(Router);

  if (authService.isLoggedIn) {
    return true;
  }

  return router.parseUrl('/login');
};
Enter fullscreen mode Exit fullscreen mode

New Image Directive

It's 2023, and images are among the most critical reasons for bad LCP(Largest Conentful Page). You dont need to care about this anymore with the introduction of the NgOptimizedImage directive.

Listening to Community

Optional ZoneJS

If you are an Angular developer, you know what zone.js is. It is responsible for all the magic in Angular around change detection.

But it starts giving performance hits in large enterprise applications, and enterprise is where Angular shines.

Finally, we will have an optional zone for our Applications. Signals are coming to Angular, and it will make zone.js optional, and a good thing it's backward compatible. It means you can still have an existing app with zone.js and run these new components, which are signals side by side. There are ways to disable zone.js, but it's not very straightforward.

In the below sample signals: true property will land soon, but not available with 16.0.0-next.7 version

import { Component, signal } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-counter',
  standalone: true,
  signals: true, // you can still try this code by commenting this line
  imports: [CommonModule],
  templateUrl: './counter.component.html',
  styleUrls: ['./counter.component.scss']
})
export default class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(n => n + 1);
  }

}
Enter fullscreen mode Exit fullscreen mode
<p>counter works!</p>
{{ count() }}

<button (click)="increment()">Increment</button>
Enter fullscreen mode Exit fullscreen mode

But Signals will bring more than just optional zone.js. you can read more on the RFC

https://github.com/angular/angular/discussions/49685

https://github.com/angular/angular/discussions/49684

https://github.com/angular/angular/discussions/49682

https://github.com/angular/angular/discussions/49683

https://github.com/angular/angular/discussions/49681

SSR and hydration

SSR in Angular has many issues today. SSR in Angular is less famous than other React or Vue-based SSR frameworks. The Angular team has started improving the SSR experience and released the first feature.

Typed Forms

Angular has types of forms ReactiveForms and Template Driven forms. The community wanted forms to be typed for a long time, and it finally landed in Angular 14.

Yes, you can create typed forms now, and chances are you are already using them.

  form: FormGroup = this.fb.group({
    name: new FormControl<string>(''),
    salary: new FormControl<number>(0),
    age: new FormControl<number>(0),
    dob: new FormControl<Date>(new Date()),
  });
constructor(private fb: FormBuilder) {}
Enter fullscreen mode Exit fullscreen mode

Conclusion

I tried to summarize all the fantastic things Angular is going to bring to you as a developer. I am looking at a great future investing in Angular as I did six years ago when I picked up Angular and transitioned from a .Net developer to Angular Developer.

Investing my time in learning and supporting the Angular framework was worth it in the Past, which is still rocking in the present, and I am sure with features like Signals, it will keep shining in the future.

Top comments (17)

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

Honestly, Angular has been trailing behind the alternatives.

Angular Universal came circa 2016, matching React alternatives -Gatsby (2015), Next JS (2016)- but yet today it doesn't bring SSG nor ISR (as far as I know).
At this moment, Next is moving towards Streaming SSR, which isn't mentioned in Angular Universal plans (as far as I'm aware of).

Signals will be a truth on the next stable version (late this year I guess) which along Standalone components will bring similar DX and features React has since early 2019.

Angular still uses OOP as base, which is absurd in the frontend as the tree-shaking capabilities when OOP-ing are just absent (though Angular has some for the built-in framework stuff, it won't cover custom logic).

Aside from that, Angular (React also does that a bit) implements stuff to cover things that the standard API (of HTML, CSS) covers on a seamless way (e.g. form validation) which seems not only odd but also makes it objectively worse than the default solution (RFC compliance), plus one could reach the conclusion that they could do better putting the effort into something else instead.

I don't think a non-retrocompatible Angular 3 is necessary but they may do better using FP as the default for stand-alone components and hurrying a bit on a stable version with Signals, while putting some effort on SSR/SSG/ISR/Streaming SSR, otherwise it will keep loosing users to end up dying sonner rather than later (in comparison with alternatives).

As a tech lead I need to decide which stack to use whenever a new project is coming and I can't pick Angular for almost anything since some years ago, simply because I can't objectively justify the choice.

For a PWA? Next JS
SSR/SSG/ISR? Next JS
Content-Driven? Gatsby or Next JS

And so on 😅

There are other options out there (Solid, Svelte, Astro, Qwik...) each with it's pros and cons, but the community, available human resources with experience on them and so on is still low in comparison. We'll see either evolving convergence (every option will reach the same feature set on it's own) or a pure Darwin theory winner (the one that best adapted the market needs will prevail).

Will see 🤔

Collapse
 
maxart2501 profile image
Massimo Artizzu

I think your impression on Angular has been biased by your personal work experience.

It is true that Angular Universal has been lagging behind the counterparts, but it's also true that Angular's main focus hasn't been that. I think there will be some revamp, at least, since v16 will bring component hydration to Angular, so I'll wait.

In the meanwhile, I found that Angular is a pretty good choice when it comes to internal and B2B applications. Its use of TypeScript has been a real precursor for modern FE frameworks. Its form API (the reactive one, at least) has always been a step ahead of what you can fin for React, for example, and it's even better now with typed forms. Angular offers style encapsulation (either native or emulated) out of the box, whereas you have to deal with dozens of CSS-in-JS libraries each with their own compromises. Its router has always been a really good one, and supported lazy-loading for a long time. Its CLI has been an example for other frameworks. You need Next to get on par with React on these matters.

Angular still uses OOP as base, which is absurd in the frontend as the tree-shaking capabilities when OOP-ing are just absent (though Angular has some for the built-in framework stuff, it won't cover custom logic).

I've read a lot of criticism against OOP, but this is quite new to me. It's true that it's hard to tree-shake properties and methods from a class, but to me it sounds more like a bad class design rather than a bad framework choice.
The same bad design created some of the horrible god-like class services and components but, as I said, it's a developer problem, not a framework's one. The same problems that created 300 LOC functional components in React... Not that was absurd, but I personally see nothing absurd in using classes.

Angular (React also does that a bit) implements stuff to cover things that the standard API (of HTML, CSS) covers on a seamless way (e.g. form validation) which seems not only odd but also makes it objectively worse than the default solution

I'm frankly puzzled that you might consider native form validation and handling anything nearly sufficient for the needs of a web application that's more than a todo-list. Native validation offers just the basic bricks, the rest has to be done by the developer. For example, async or cross-form validation.
On the contrary, I've seen that Angular is much more adherent to the standards than other frameworks. For example, its component model resembles much more the design of Web Components, and it can use Shadow DOM too. Speaking of Web Components, it supports them without a hitch - no problem with custom event either. Animations use the Web Animation API underneath.
I can go on, but the point is that web APIs usually do that: offer the basics, let the community build layers on them. There's nothing odd here.

but they may do better using FP as the default for stand-alone components and hurrying a bit on a stable version with Signals, while putting some effort on SSR/SSG/ISR/Streaming SSR

Angular 16 will come out in May (hopefully) with signals and component hydration. For the rest, it may surprise you that the average Angular developer doesn't feel the need for SSG/SSR, also according to the periodic developer survey they make.
This also applies to class components: there's no strong push to have a replacement. (In the meanwhile, some other one-method classes - like guards and resolvers - are now deprecated in favor of functional alternatives. That actually made sense.)

otherwise it will keep loosing users to end up dying sonner rather than later (in comparison with alternatives).

Angular has never been on a downward trend in its life so far. Meaning its user base is still growing - a little, but steadily. It has grown quite bit of momentum and we won't see it go any time soon.
And even if it will die "soon"... well, whatever, it's just a framework. The web will survive.

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

Angular offers style encapsulation (either native or emulated) out of the box, whereas you have to deal with dozens of CSS-in-JS libraries each with their own compromises

Just one. Pick one and go ahead. In Next JS, styled-components get pre-rendered so no downsides, plus it allows you to have a monorepo with a shared styled components library which also share presentation logic across your Apps seamlessly, making everything robust.

Its router has always been a really good one, and supported lazy-loading for a long time.

A router that you need to manually define? Svelte, Next and many others did a way better job by basing it's routing in filesystem (and filesystem routing is the default one in webservers since the beginning by the way, they didn't bring anything new but came back to the simplicity of the origins).

Its CLI has been an example for other frameworks.

I like the Angular's cli, but it's nothing new, many frameworks had this before and also remember that half the need of the cli is also tied to the complexity of it's workarounds, something that doesn't exists on certain alternatives.

You need Next to get on par with React on these matters.

Of course, because React is a library and Next is a framework that happens to implement React... Even Next doesn't cover all the features Angular has, neither it's its intention to do so for many reasons (Angular is 100% opinionated, Next JS is just a bit opinionated, giving you freedom on most of the things. Whether this is good or bad is up to a different discussion).

In the meanwhile, I found that Angular is a pretty good choice when it comes to internal and B2B applications.

Ok so it's good in the less possible demanding scenario. Cheers, I guess.

I've read a lot of criticism against OOP, but this is quite new to me. It's true that it's hard to tree-shake properties and methods from a class, but to me it sounds more like a bad class design rather than a bad framework choice.

Each paradigm has its pros and cons and notice that I've said "in frontend" specifically (because you may want to reduce the bundle size as much as possible for several different reasons).
To be able to tree-shake OOP based code you'll need a "static" analyzer more powerful than the TS one itself and even in this situation it may be tricky and prone to error, simply because you can access any property (and methods, which are properties as well) dynamically whenever and wherever you want in runtime. When using FP it's quite simple, if you don't import a function or variable, it's not used here, you can remove it safely. That's all, and it's a bad framework choice.

I may write a post around this with details as soon as I have time (I need to gather tones of info and digest it on an easy talk, covering details like the tree-shaking and explaining which programming paradigms you should combine depending on the situation) so stay tuned if you want to read more.

I'm frankly puzzled that you might consider native form validation and handling anything nearly sufficient for the needs of a web application that's more than a todo-list. Native validation offers just the basic bricks, the rest has to be done by the developer. For example, async or cross-form validation.

So I don't know what to say here.
Native form validation is as powerful as it can be and I may be wrong, but the statement above smacks of a lack of knowledge in web standards (no pun intended, learning the details of stuff is costly in mental effort and in time).
Check this post as starter point, I tried to summarize it briefly, don't hesitate to ask for details if you feel like.

Cross-form validation will need to be implemented on the spot anyway, that's for sure, but in this situation you don't validate the value of inputs "as is", instead, you evaluate that the value of a given input is OK in concordance with the value of another input on a different form, so you can use default form validation in each form itself + custom JS for cross-validation, can't see the issue.

Moreover, you'll probably do better by re-rendering the forms values just with the OK options whenever you do a change into another one. UX-wise it's way better to provide available options that are OK to the users, than showing all the options and then telling them that the chosen values are wrong.
In this situation you just map options of an input to available options into the second one (or one in a different form) and it will fall into functional logic, no cross-form validation is required.

For the rest, it may surprise you that the average Angular developer doesn't feel the need for SSG/SSR, also according to the periodic developer survey they make.

I mean yes. Absolutely. Sure they won't, because for anything that requires those no one is using Angular, there's objectively no reason for doing so as Angular ecosystem doesn't provide a way to deal with that properly or at all.

On the other hand, having SSG/SSR/ISR... is not due to a "developer feeling" but a technical need of certain projects which developers may not be aware of.

On one side it is the responsibility of Software Architects and Technical Leaders to choose the right stuff, on the other side, when all you have is a hammer, everything looks like a nail.


Look, there's a balance.
Angular has some pros that no other framework has matched yet:
It provides a unified way to work with the frontend, making most of the experience people gather working with it transversal to any angular project.

This makes things way easier on big companies when re-assigning developers from a project into another.
By providing this Angular was placed automatically at the god tier of FE tools.

The world evolves, Angular original team is gone and no one is doing what needs to be done to keep it up to date.

Angular was the brainless choice for corporate in-house software back then. Now It 's no longer able to compete (the balance is no longer balanced, nor it's inclined to Angular anymore in any situation you can think off).

Imagine doing the exact same web app twice, one with Angular and the other with Next.
With Next, setting ISR on that given page (or even streaming-SSR). You'll see FCP and TTI to be blazing fast, CLS to be practically absent and so on and so forth, whereas in Angular it will be notably slower.

One may argue that "you don't need core web vitals on this kind of software" and you don't need those for SEO, because no SEO is required, that's true.
Now let me remember you that core web vitals are metrics that highly affect UX and that's the reason for Google to take them into account for SEO, and not the other way around.
If you ask users to evaluate them from 0 to 10, they will evaluate the Next JS one much better than the Angular one, and this is quite important, because we -usually- build software for people.

In the DX side Angular is good by default: it gives you one way to deal with each thingy and you need to take it, like it or not -don't fight the framework- whereas in Next you need to take some decisions (which adds overhead but also flexibility).
The neat part is that aren't -usually- the developers the ones choosing the stack but us -Technical Leaders and Software Architects- by having the big picture and understanding the business needs, so we can ensure everything is there for a reason, that the reason is properly assessed and that the solution covers the needs as much as possible.

It's not that I dislike Angular, nor that I sh*t on it for no reason, It's more that I'm sad it ended up this way for different reasons. It was a nice pick for several things and now it's not objectively speaking, and it makes my job a bit more difficult timewise (having to define littler pieces instead just a framework in certain situations).

There are some other key points when choosing the stack of a project, check this for reference:

Best wishes.

Thread Thread
 
maxart2501 profile image
Massimo Artizzu • Edited

Just one. Pick one and go ahead.

No, it's not something you can always afford. Sometimes you have to work on the decision that others made, which may be starkingly different from what you're used to. Sometimes you don't have Next to save you. React has always been a mess in this regard, period. Now that Next has made some heavily opinionated choices we'll see, but be aware that being unopinionated is what some think is a strong point of React.

A router that you need to manually define? Svelte, Next and many others did a way better job by basing it's routing in filesystem

Your personal opinion. And while you might create route definitions for Angular based on the file system (what do you need? A crawler, is that all?), you have to admit that this pattern only solves a fraction of what a router can do.

I like the Angular's cli, but it's nothing new, many frameworks had this before

Like Angular CLI? No. When it came out, it was a step ahead of anything similar.

Ok so it's good in the less possible demanding scenario. Cheers, I guess.

I don't get your point of your veiled sarcasm. There's no "less possible demanding" case. You either do your job or don't. Are you trying to diminish the work of Angular developers or what?

To be able to tree-shake OOP based code you'll need a "static" analyzer more powerful than the TS one itself and even in this situation it may be tricky and prone to error, simply because you can access any property (and methods, which are properties as well) dynamically whenever and wherever you want in runtime. When using FP it's quite simple, if you don't import a function or variable, it's not used here, you can remove it safely. That's all, and it's a bad framework choice.

You've provided a weak example. If you need to dynamically access properties and methods you should be very sure of what you're doing, and anyway the equivalent in terms of exported functions is to dynamically access the exported symbols of a module, so you'll need to do import * as all from '...' or similar and access them with all[prop], which mean that tree shaking will fail there too.
There are reasons why using class components may not be the optimal choice, but tree-shaking isn't one of them (or rather, there are other problems underlying).

Native form validation is as powerful as it can be and I may be wrong, but the statement above smacks of a lack of knowledge in web standards (no pun intended, learning the details of stuff is costly in mental effort and in time).
Check this post as starter point, I tried to summarize it briefly, don't hesitate to ask for details if you feel like.

Are you honestly trying to prove a point with a beginner level article like that?
My point remains exactly as I stated: native validation can do very little by itself. Even the native popover that you get with invalid controls is generally frowned upon by designers and customers, so you'll need to provide your own implementation.
The fact that Angular offers an API to deal with such cases is definitely a plus. It gives you something coherent to also work with validations that depends on other fields and asynchronous validation. So what's the problem?

so you can use default form validation in each form itself + custom JS for cross-validation, can't see the issue.

The issue is that you have nothing to work with that. Angular provides you what you need.

On the other hand, having SSG/SSR/ISR... is not due to a "developer feeling" but a technical need of certain projects which developers may not be aware of.

I mean, sure! Angular clicked with a certain portion of front-end developers, so of course they're biased. After all, the demand for those type of applications has never faded, so it hasn't really being critical for the Angular community. Let's see if it'll change in the future, but if Angular has lagged behind in that it doesn't mean it will in the future or maybe will do better than the alternatives.

On one side it is the responsibility of Software Architects and Technical Leaders to choose the right stuff, on the other side, when all you have is a hammer, everything looks like a nail.

Uhm, said the one that suggested using Next for everything?

The world evolves, Angular original team is gone and no one is doing what needs to be done to keep it up to date.

On the contrary, I've seen Angular evolving surprisingly well since it came out in 2016 - when I actually thought it was doomed since it didn't provide a real difference from Angular JS. Have you actually read the last release notes or not? Do you really thing no one is doing anything? That's a bit insulting for the Angular team, if you ask me.

Or maybe they aren't doing anything that you think you need? (Even though they actually are, as per your own admission.) That's fine, you have different needs for your job, and Angular doesn't cover them. Good. But your experience is still partial, as is mine.

As far as I'm concerned, I've never suggested using Angular for anything public, that needs SEO and good CWV. In some cases I suggested using nothing because all you needed to do was some very basic interactions and - yes, native form validation was enough.

But I've never rejected a client because they imposed Angular - when more often than not they had way more important problems in their architecture stacks. Some even not depending on their own architecture board, since contracts with third-party consultants are often out of their hands and those third parties sometimes don't even have a decent tech lead that can make sensible choices for their front-end stacks. And so Angular it is.

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

On the first point, i f you can choose fine, if you can't, you'll need to check the reference of the chosen tool and that's all. Despite your preferences it will be one of three things; Something that implements CSS with or without extended capabilities (e.g. CSS, Scss, Sass, CSS-in-JS...), a UI kit (e.g. Bootstrap) or an utility-first (e.g. Tailwind).
Just try to understand how they work and adapt to what was chosen for the project 🤷🏼‍♀️

On the routing side, using the filesystem is the default behaviour in every single server since... always, and you can do pretty much with it. Of course, when dynamic-routing you'll need either a framework that handles that for you on a seamless way (like Next) or to code a little algorithm to apply this dynamism.

Like Angular CLI? No. When it came out, it was a step ahead of anything similar.

Rails for Ruby circa 2004, Symfony framework circa 2005, Django about the same time...

There's no "less possible demanding" case.

Well, allow me to disagree. When you code an in-house tool you know beforehand how many users will use this tool, and if a drama happens the reputation of the company won't be affected the same way. On the other hand, releasing a WebApp publicly for anyone to see and use (usually clients) is more critical in every single aspect and the consequences of it being slow or buggy are way worse for the company's branding and public image at least.

My point remains exactly as I stated: native validation can do very little by itself. Even the native popover that you get with invalid controls is generally frowned upon by designers and customers, so you'll need to provide your own implementation.

Have you ever tried it? I mean, seriously.
The styling for the default popover is something you apply to the form component in your App, just like you do with anything else. You can also customize the messages dynamically with setCustomValidity.
The information is out there, you can find it in the references of HTML, CSS and JS.

Let's see if it'll change in the future, but if Angular has lagged behind in that it doesn't mean it will in the future or maybe will do better than the alternatives.

It may be, but the odds are against it and that's just what I am pointing out.

Uhm, said the one that suggested using Next for everything?

It's currently one of the most advanced frontend frameworks feature-wise, with a nice DX, good performance and flexibility to build any kind of tool.

I've stressed it a lot; built a PWA, a PWA with offline capabilities, gateways and micro-services (GraphQL, RestFul), middleware, api-first monoliths, used it just as client, also almost just as backend with a tiny dashboard, used it in a content-driven App as replacement of Gatsby just to see how it would work when having a headless CMS source, also built a B2B WebApp as replacement for Angular... and I've been able to tweak it to match the best possible scenario in any situation either with what the framework provides or with a curated choice of a dependency, maybe sometimes built on my own.

By this I am pretty confident to say that using Next you won't go wrong or find any missing key building block which leads you to "fight-the-framework" to overcome.

As far as I'm concerned, I've never suggested using Angular for anything public, that needs SEO and good CWV. In some cases I suggested using nothing because all you needed to do was some very basic interactions

Public, that requires SEO.
I can think of online shopping platforms, product pages, online communities -including social media-, forums, wikis, any integration with recommendation systems, almost anything that has a headless CMS behind the scenes, sales funnels key building blocks, multi-platform web-first Apps...

Also CWV is not something you do for SEO, it's something you do for UX which happens to take a positive impact in SEO.

But I've never rejected a client because they imposed Angular

Neither did I, sometimes I was the guy suggesting Angular, now I can think of just a couple of very edgy cases in which suggesting Angular is OK nowadays. Will see in the future, maybe they do catch up with the rest, rendering Angular back to the menu.

when more often than not they had way more important problems in their architecture stacks.

A problem is a problem and has to have an analysed, defined and planned workaround to solve it.

Or maybe they aren't doing anything that you think you need?

I, personally, just need some vacations 😂
The industry though, is dealing with more and bigger data, delivering content at higher rates across the globe, each day that passes more countries get better internet and open to new markets and more clients get to the current markets.

Adding new features to optimise things (e.g. ISR, streaming-SSR...) are not whims of the framework creators but solutions to current needs.

That being said, you choose the tool with the pros that best fit your project and the cons that you are willing to deal with.

If you like Angular it's totally fine, on the other hand I'm pretty sure you won't retire by using Angular so you better learn the core API of the web (HTML, CSS, JS) which will help you learn frameworks and libs afterwards, and try a bit the alternatives to Angular just for you to know and have a bit or perspective or the big picture.

Best regards

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

On the routing side, using the filesystem is the default behaviour in every single server since... always, and you can do pretty much with it.

I suppose you meant "everything" there... But no, I cannot. I can't create a folder for every record in the DB. That's why I need dynamic routing, and that's actually what most of some of the apps I've dealt with need. And I want something that does that for me, also allows me to define guards, resolvers and so forth. Angular's router does that and even more, and yes, I've been using those features.

Rails for Ruby circa 2004, Symfony framework circa 2005, Django about the same time...

Weren't we talking about frontend tools? At least frameworks based on JavaScript...

Well, allow me to disagree. When you code an in-house tool you know beforehand how many users will use this tool, and if a drama happens the reputation of the company won't be affected the same way. On the other hand, releasing a WebApp publicly for anyone to see and use (usually clients) is more critical in every single aspect and the consequences of it being slow or buggy are way worse for the company's branding and public image at least.

Reductive, to say the least. You still work within contractual constraints. Only because it doesn't have certain requirements it doesn't mean it's a lazy job. A client will always be pissed if you don't do your job correctly.
You can talk about public risks, but what a client demands and is on the contract still has to be taken seriously regardless. If you develop an internal tool and the users use it incorrectly because of an issue, it can still cause a damage. Even public damage if it takes down public-facing applications.

Have you ever tried it? I mean, seriously.

Yes, in basically every personal project. That has always been enough for me.
Also have to be fully understood in order to make formAssociated Web Components play nicely with existing standards - and therefore, libraries.

The styling for the default popover is something you apply to the form component in your App, just like you do with anything else.

I don't know what you were trying to say here but you cannot style the default popover. I remember some old vendor-prefixed properties, but they have been removed since. But clients and designers almost always want something else and, above all, something that looks the same in all browsers, so you need to prevent the invalid event and replace it with your own implementation. So it's not "like you do with anything else", e.g. like I style an <input> or a <button>. Setting a custom error string is trivial and the least of my concerns.

By this I am pretty confident to say that using Next you won't go wrong or find any missing key building block which leads you to "fight-the-framework" to overcome.

Next, like any other framework, is technical debt by definition. Sooner or later you'll fight it when a new need will emerge, and saying the opposite is very naive. React already forces you to work around its limitations in several cases.

A problem is a problem and has to have an analysed, defined and planned workaround to solve it.

Sure. But time and resources are finite and so problems have priorities. I can raise flags all day, but the risk is to be viewed as bikeshedding or non-costructive criticism.

Also CWV is not something you do for SEO, it's something you do for UX which happens to take a positive impact in SEO.

That's incorrect: CWV have direct impact on SEO, as Google actively uses them for its rankings. Google measures the CWV, not how good a UX is (maybe one day, with enough AI...).

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

This is exhausting...

I can't create a folder for every record in the DB. That's why I need dynamic routing, and that's actually what most of some of the apps I've dealt with need. And...

Again, you don't need to manually define the routes, not the static ones at least. Of course, when dynamic routing you'll need to set up your custom logic to retrieve the related content to this dynamic route, that's obvious.

Only because it doesn't have certain requirements it doesn't mean it's a lazy job.

I've never said that, I've said are less demanding scenarios.

so you need to prevent the invalid event and replace it with your own implementation.

Or you can disable the submit button by default and enable it just when all inputs are :valid, handling the errors in the meantime as you wish 😃

But time and resources are finite and so problems have priorities

That's why making the right call at the beginning is so important, and that's just why Angular is less appealing than it was a couple of years ago when defining the stack of a new project.

CWV have direct impact on SEO, as Google actively uses them for its rankings.

Again: Google does that due to the CWV's impact on the UX and not the other way around. Just in case, UX is not limited to user journeys.

Core web vitals are pure UX, they can be defined as the user-centric point of view of your technical frontend. Please check Core Web Vitals

You'll see user experience mentioned in any category along guidelines.

For reference:

  • Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
  • First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of 100 milliseconds or less.
  • Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of 0.1. or less.

There are plenty of UX studies and reports that came prior to the definition of core web vitals and their measurement.

When doing a report of your site with Google Lighthouse you'll see different categories.
Remember that Accessibility is usability for people who interact with products differently, so it's also UX, and also measured by the tool.

Following the same rule, SEO specific stuff (links should have a discernible name yada yada) are meant to offer better UX to users searching the web, so you should stick to the standards (semantic HTML, A11Y...) making thing easier not just for the crawlers but also for screen readers as well (which are crawlers to a certain extent).

In other words, CWV and everything related is about UX and how do you manage each key point technically.

Google first decided to define the CWV through UX studies, testing and effort, then decided to take them into account for the SEO.

The normal workflow is to apply CWV key points for UX reasons. In this scenario, having SEO benefits is a side-effect.

If you want to reverse the workflow and apply CWV just for SEO purposes it's OK-ish (you'll often see yourself monkey-patching stuff when thinking this way), the important thing is that you do it, and that you do it properly.

By properly I also mean not doing the following workaround:
Using <span> to define links. Late-checking the Lighthouse red flag and monkey-patching it to <span role="link">, which is non recommended.

Doing it properly:
Use <a> instead from the beginning, which is the recommended and for good.

Extrapolate this to any situation of not following the standards.

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

I've never said that, I've said are less demanding scenarios.

Still incorrect: it's professional work we're talking about. Having some aspect less considered does not make it less demanding. And, above all, you used a dismissive tone that feels a little offensive, to be honest. Please be more respectful.

Or you can disable the submit button by default and enable it just when all inputs are :valid, handling the errors in the meantime as you wish 😃

Wouldn't recommend doing that for accessibility reasons.

Again: Google does that due to the CWV's impact on the UX and not the other way around

I wonder if you're actually reading what you're writing... It's the UX that has impact on CWV, not the other way around.
Google uses CWV as a parameter for the rankings, and that's all that matters. More often than not, companies don't care about UX per se. Rather, they might ask you to improve the CWV because they have direct impact on SEO. They only care about being on top on Google's results and they'll try to exploit the algorithm as much as possible. Heck, they'd ask you to put the whole dictionary in the keywords meta if only it'd mean anything today.

Core web vitals are pure UX

No. They might claim to be "pure UX", whatever that means, but in the end they're just numbers generated by a soulless computation. And the goal is to have them as good as possible. The easiest way might be having a good UX, but if someone finds a shortcut, they'll ask you to implement it. That's also why they're constantly adjusting the parameters, the rules and the metrics.

Also, you can have a terrible UX with excellent CWV, because UX is much more than that.

In this scenario, having SEO benefits is a side-effect.

No, again: it is a direct effect, because Google decided to take them into consideration for their rankings. Period.

Sorry to burst you bubble, but for certain companies it's all just a game.

(How did we get here talking about Angular? ...)

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

Having some aspect less considered does not make it less demanding

Having less things to care about and less spikes on the rest is like the definition of less demanding...

I agree on that the UX -Core Web Vitals thingy is like the mobile-first, everyone knows it's better to do it one way but few actually implement things this way.

Also agree on this conversation has lost the focus long ago 😂

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

Having less things to care about and less spikes on the rest is like the definition of less demanding...

You actually have no idea if that's actually the case. Only if certain aspect aren't taken into consideration, it does not mean there are "less things to care about". There could be others - in form of dependency constraints, quality gates, multiple deploy environments, workflow processes, documentation production, even dealing with other departments and/or third-party consultants or providers. Or could be "simply" stringent deadlines which, more often than not, you'll deal with in B2B applications rather than with companies that develop their own digital products. Nothing of this is in any way, shape or form "less demanding" than any other kind of frontend project I've dealt with. Only my side projects can be considered "less demanding" (or they wouldn't be fun).

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

👍🏼

Collapse
 
tayambamwanza profile image
Tayamba Mwanza

I think they're mostly focused on signals ATM and will probably go to universal stuff after that.

Unfortunately they can only move so fast so will just have to wait and see what the future holds for Angular, although I heard Mino speculating about AI in AngularAir and he developed ngx-quicklinks back in the day which uses machine learning I think, so I'm curious if an ai based feature is in Angulars future.

Collapse
 
pbouillon profile image
Pierre Bouillon • Edited

I’ve been working with Angular since version 7 and I don’t recall seeing that many core changes to the way we use the framework itself

Standalone components, signals, typed forms, and all the evolutions in the libraries gravitating around it (the huge Angular Material update, providers from NgRx and new APIs, etc)

I don’t know if this is the response the Angular dev team has found for many years of being left behind in the State of JS but I am definitely looking forward to what some call the renaissance of Angular

One thing I still regret is the frequency of Angular major releases: despite being a great framework, too many updates require developers working on many project to periodically invest a lot of time to migrate each one of those every 6 months, which can lead to evaluate wether or not it would not be better to use another framework, less volatile

That’s all for my two cents, thanks for your article, always a great read and a very good rewind of Angular over the years! I would also be curious about the path Angular has taken regarding testing (protractor, etc)

Collapse
 
davidgagne profile image
David Vincent Gagne

I applaud anyone who isn’t a native English speaker and attempts to write a lengthy article like this in what is arguably the most difficult language to master. This was difficult to read at times because of grammar and sentence structure issues, and would have benefited greatly from an editor, but overall was an interesting synopsis of the state of Angular.
All that being said, as a developer who has been creating websites for more than twenty-five years, my biggest complaint about Angular is that I’ve never seen a website built with it that didn’t suck. (Please, I beg you, find me an example of a website built with Angular that doesn’t suck!)
I see the exact same problem with so many Wordpress sites now, too. The team in charge of the framework has been so dedicated in their relentless, methodical march towards making it so that anyone — regardless of skill — can build a website with Wordpress (or Angular), that they’ve enabled just that. There are “developers” churning out Angular websites (and Wordpress sites) that literally have no idea how websites are supposed to work.
I click a button and there’s no indication that anything happened at all. I click a menu link and the page sits there as if nothing happened. I load a webpage that appears completely empty and I’m convinced the link is broken, and then suddenly I get the content. Every Angular site I’ve seen is just awful.

Collapse
 
tayambamwanza profile image
Tayamba Mwanza • Edited

I think this one doesn't suck;

expobeds.com/

Starlink, is simple but quite snappy

starlink.com/

This feels high quality

tomastrajan.com/home

I Watched reviews of Google bard and many normies say the UI is very clean, it's also built with Angular

bard.google.com

Recent

startrack-ng.web.app

Collapse
 
bwca profile image
Volodymyr Yepishev

The best thing about Angular is that it basically has everything included, from means to manage state, to style guide and update tool, which allows even mounting AngularJS inside newer Angular apps.

Though it lacks the flexibility of React in terms of fiddling with components.

Collapse
 
chickensiblings profile image
Gus

I started to work with angular in 2018 and I have learnt many things of the angular past with this article.