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 XMLHttpRequest, (htc files are behavior scripts of custom elements, invented by Microsoft, never adopted by other than IE), and let us not forget ActiveXObject to open SQL connections from JavaScript — highly discouraged, unless you developed an HTA, a technology by Microsoft to run IE as a native application, now replaced by Edge App or Chrome App! Yes, we had fun!
But that was it, the technology that came out, was IE-only, and had unpredictable future. Not many adopted it, the majority of UI developers focused more on JavaScript itself.
Along came JQuery
JQuery came as a natural extension to the way we perceived JavaScript: client-side library to manipulate client-side elements. The heavy lifting was still done on the server. My experience was mostly .NET so I can tell you from that angle how things worked. The project was on Visual Studio, with main scripts and libraries, and empty template pages. As a developer you would fill in the gaps, and hit BUILD! What happened next was not a concern, until something failed to work. The ecosystem was provided by Microsoft. The external libraries soon became hosted on NuGet. The source of truth was one: Microsoft. If they were okay with your plugin, it worked, else, it failed. There was little interest in the extra folders you see in the solution: properties, bin, debug, it didn’t matter. As for client-side programming, you had the flexibility of writing your own JQuery plugins, and stuffing them anywhere in your code, literally, anywhere!
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
What Angular, Ember, React, and later VueJS and Svelte proposed, was shifting the weight of the web application to the client. The server now could sit anywhere, and be served by any technology, as long as it produced JSON. REST APIs now became ever more popular. All new frameworks used JavaScript, and everybody was invited. But something went wrong.
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++”
… Angular team is pushing everyone to change. This is quite daring, and risky. But it worked for me: someone who does not jump on the bandwagon, and who’d rather wrote C# functions to bundle JavaScript code than use the bundler.
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.
Maturing
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.