In early 2000, we were asked to do a project for a client of the company, that had to be cross browser compatible, which meant, a lot of fillings and compromises, mainly to satisfy Netscape. The team consisted of the following sub teams, each having 3 to 4 members in it:
Database team, to create tables, and stored procedures over SQL
Business layer team, or whom we called COM team: to create the COM classes over VB.
Front end team, or what we called ASP team: to create the ASP pages to consume the COM classes.
Designers: absolute aliens, who delivered once, then disappeared.
In another project, we were asked to make the client-side do the heavy lifting of
XML parsing, given that IE was the only browser used, and to that, we had a field day! There were times when we experimented with everything IE produced, and for this new generation who think IE was always lousy, let me have a word of defense of IE: Microsoft started it all.
I still remember the Java Applet we had to install to use Remote Scripting (now known as Ajax), then it became an
.htc (HTML component) file with the infamous
htc files are behavior scripts of custom elements, invented by Microsoft, never adopted by other than IE), and let us not forget
Along came JQuery
I cannot stress this enough. I have seen scripts injected in the weirdest places in ASP.NET Core itself, developers misuse the power given to them in a blink of an eye.
Then JSON showed up
As the internet became faster, and more reliable, and as browsers unified into “evergreen” releases, developers accepted JSON to be the only shape of data needed to travel on wires. A few years back I posted a question of which was a better framework: serving fully processed HTML scripts over Ajax, or only JSON that would be populated on client-side. See, back then, populating JSON was hand crafted, before Knockout, before Backbone, and few other players I don’t recall. The thing you could use back then was Mustache-like, which -by the way- still is a favorite of mine when venturing outside of SPA zone.
Shifting and lifting
The same evil developers who injected scripts in ASP.NET, started importing all kinds of open source, and third party libraries into their projects. And even though the ecosystem of client-side programming evolved, it was still developer-flavored. It still is to a great extent. The packaging system, the bundling and chunking, up to third party routing, all was a preference.
Angular 2, and the shift in paradigm
When I started with Angular 2, I was in the same mindset I was in when I worked with JQuery. I read the “get started” looking for the script url to dump in my header to start working, much like VueJS today. It was hard, and a lot of developers complained about the steep learning curve of Angular 2 (which by the way, is no longer true). I resisted change, I kept resisting, shamefully, up till Angular 4. I wanted to break open Angular to serve my ecosystem, which was, not surprisingly, an extension of my server side ecosystem. An IIS website that always served the dist folders. A way to inspect everything I was writing in Dev Tools. A way to force the source files to load instead of the “compiled files.” A way I can control which library gets served where. I used SystemJs, then I used my own Webpack over Gulp to generate the dist folder. I wanted to control everything!
Angular 4, I succumbed.
That was it, I no longer wanted to take care of the ecosystem, so I installed angular-cli (yes I hadn’t done that yet), and used ng serve, and ng build, and finally caved in. I changed! With that, came a different ecosystem, much like the .NET ecosystem. Add your pages, serve over a light server, then build and publish. I did not bother any more about maintaining the framework.
The source of truth
Angular 2 in my opinion, was not trying to compete with other frameworks, it was setting itself apart as the client-side default. It is different, and it is harder to learn. It has less flexibility in choosing third party plugins. Almost all of my third party plugins failed after an upgrade. Other framework developers take that against it. But; at the bottom of the anguish, beyond the last moment of nervous breakdown at the sight of this message in console:
“this feature… is deprecated, it will be removed in Angular x++”
Today, even Angular-adopted third party, break after an upgrade. The last one to break for me was Angular Material! Go figure. But at least, we know Angular team has adopted it, they will take care of it, we can stop worrying, and focus more on “writing code.”
Leading the crowds
Angular advanced with CLI and, lo and behold, React community developed NextJs then Gatsby, Vue community caught up with NuxtJs, Svelte creators are switching to SvelteKit, what are they doing? What Angular did more than 7 years ago. But Angular is still ahead in one game, TypeScript was made a prerequisite. None of the others followed suit, yet! They are still inhibited by the jQuery mindset: freedom of libraries.
As Angular upgrades (version 13 now), it matures. It becomes harder for other frameworks to compare. Even though the negative reputation has lingered beyond its expiration. I don’t think people see this, but just like ASP.NET core, though hated by many, and followed by little, is still going round making an impact, it is still the number one choice for many. If there was a issue, they either have figured it out, or will figure it out next version.
I may not like them, but I trust them.
Read on Garage Sekrab