A topic that people tend to discuss about. Stability. Who doesn't want stability? The knowledge you gain by sticking to one thing. It makes you feel safe that you can rely on this thing... say a set of libraries. The productivity benefits where everyone can learn from what you did and you can start a new project with those set of libraries again faster than before. Managers and stakeholders are happy that you got results. You feel good knowing that you delivered something and customers are using it. When you see the other people who took a risk at trying other new shiny libraries, you scoff at them and tell them use these libraries and you wouldn't have had the trouble. Yeah, always feeling smug about any competitors. You've turned into an evangelist.
Blog - Switch to NodeJS
If you've followed this blog since the start, it was first a WordPress site because it is a ready to go content management system. Who has the time to create a blog from scratch anyway. That attitude changed as I kept having to upgrade the blog because of security vulnerability. I believe at one point my blog got hacked since I didn't upgrade for like a year or so. After I quit working at Uber, I decided to move the blog to software created using NodeJs. My requirements were simple. No security upgrades and admin side must be accessible only on internal network. I surveyed the landscape and deemed every blog software I saw as unfit.
So i made the decision to create my own blog software. I was troubled on how to proceed whether I wanted to create a tool that generated html or full blown blog. Eventually said screw it and went with a view only public application and an internal management application. The view only public application would never need to be upgraded unless NodeJS had a bad bug, but that was easy to do. Install the latest node and restart the application. I again surveyed the landscape of libraries I would need to create a blog application. Express is a well developed web framework, but even then I questioned if I wanted to use it. The biggest factor for a web framework was the breadth of libraries it had behind it. Express had the biggest out of the choices at the time. Even then some of the libraries I did not like, so I created my own simple version of them. Passport, for instance, was too complicated for my taste. I created my own authentication, session management and authorization using ideas from multiple libraries. It didn't take long since the only authentication I wanted was with PKI which is uncommon on the web. This is just the backend side.
The frontend side was rushed given I did not consider the huge hit it had on Google Organic results. I used Aurelia even though I knew React and Angular. Why did I use Aurelia? I was so used to it and loved how Javascript was separated from the HTML portion. Server side rendering support was lacking and I was ignorant of that because I figured Google was fine with loading Javascript. Turns out Google has a time limit for loading Javascript, so the search result listings had partial/no content. I took a risk and paid the price.
Switch to React SSR
Few months later, I decided to move over to React SSR as the search results were hit hard. It was not bad since I do not try to use specialized parts of frameworks. Had to translate the components in my ui library to React and support SSR. This is when I really started to appreciate React, but I still didn't like it. Javascript/HTML feels like PHP/HTML. Not that PHP is bad, but the mixture encourages a laziness in me. When I released the blog, the visitors from search recovered a bare amount. The switch was good enough that I dropped Aurelia entirely from my internal software.
On the backend? Nothing needed to change.
Fast forward to this year, I observed my search results being impacted again. This time pages weren't being rendered properly. Discovered that Google used an older version of Chrome for Googlebot, so I needed to include some polyfills. which worked for awhile. Not sure what the hell was going on since PhantomJS was rendering properly. Yes I started to use PhantomJS to test rendering of my Blog. Search results were essentially flickering as in sometimes there and other times not. I did a Google Pagespeed to see how Google was interpreting the speed of my site.. yes page speed will affect the search result position. I saw a super bad number and instantly knew it was time to move again! In hindsight I probably could have investigated more into Webpack module splitting, but bleh come on this is a blog I want something very simple.
React is a good library, but Webpack is probably not.
Switch to Svelte/Sapper + Rollup
What was my next move? I could leave it alone and abandon the blog or invest more time surveying the landscape. At some point, I figured I would just create that tool to generate html pages. Html pages are inherently server side rendered and easily cacheable on the file system and client side. Just so many benefits. Then I remembered... Svelte v3 on HackerNews a few months ago. Took a closer look at what it was exactly. I had dismissed the framework when I first saw it, at v2, with "another framework another day". This time I went through the tutorials and did a few google searches for the libraries around it. Sapper came up as the SSR version. Took on the sample projects in both Svelte and Sapper to get a feel for them. I excitedly say "This is fucking awesome, this is was Aurelia should have been"
Ok, I wanted to switch, but had to make sure that what I needed would be covered. Once I found I was covered, I created a whole new folder and reorganized the directory structure of my blog and improved the deployment script. I had wondered if I should stay on Webpack or use Rollup. Rollup was smart about chunk sizes. Needless to say, upon seeing the smaller chunk sizes I had to try Google Pagespeed... my god. A monumental improvement in page load. I abandoned Webpack in general.
No changes to the backend,
Switching to Typescript + Fastify
I did not take a good look at Typescript at first because I hated having to run a step already with Babel/Webpack/Rollup on the frontend. I loved being able to write Javascript and just run it. one of the issues with this is that as you modularize your code you lose context and IDEs are not very good with Javascript intellisense in general as in one minute you see the type aheads and another minute you don't. So many mistakes are made without that ability, Even if I don't make mistakes, other people will. I started using Typescript for the first time at work since I wanted to use Javascript at work. Weird at first having to run `tsc` to compile the code, but shit, Intellisense worked every time and you get types! This is an extraordinary improvement to what I was used to.
Slowly but surely at home I started making new projects in Typescript. My code generator for Data Access Objects generates ts files and contains a TS checker to make sure it is syntactically correct along with prettier library. This was significant because I basically decided that I am going full on Typescript. Some time later, I started work on Version 2 of my commons library which was to get NodeJs up to par with my Java commons lib and this meant copying data structures from Java to Javascript. Funny enough, by switching to Typescript it made it much easier to do that. Just had to switch the positioning of type declarations and some syntax and surely enough working Typescript code. Shocking.
The move to Typescript spawned because I was making a build/release software which I wrote in Typescript and wanted to make use of the commons lib functions. I had to make an upload function as part of it and decided to use Fastify in a prototype way. Just needed a simple HTTP server.
My blog at this time is still using Version 1 of my commons lib, which is fine for now. I started a new full time project for Task Management. I decided I would use NodeJs with Typescript. Express was still being used, but I wanted to use software that could autogenerate documentation for my endpoints which meant "typescript-rest" was a candidate which I was familiar with it already. I had chosen it quickly when I was looking and didn't like how part of it worked. Scouring through Google with multiple keywords, I found some pretty good libraries and was torn between two of them which did a much better job than "typescript-rest". Consequently, I found tsyringe for IOC dependency injection, which I really really like and am using. I bumped into Fastify again and was looking at Swagger/OpenAPI libraries around it. While I did not exactly feel good about how to declare routes, it was workable. Fortunately, fastify-decorators exist to make route declarations much more familiar. Again, I took a closer look at Fastify and what ir brought to the table and declared "Is there any reason why not to use Fastify over Express?"
As part of Version 2 of the commons lib, I had removed a bunch of custom code I wrote around express and server stuff like Authentication/Authorization/Session Management. I figured I didn't need these anymore if I could use other libraries. When I committed to Fastify and looked at the Authentication story around it, I found that it supported the way I was adding authentication/authorization to routes on my blog so I did not need to create some custom code to register routes like I did with Express. My peeve around route registration is that one should be able to add information somewhere near the route to say it needs authorization and when the route is officially being registered the middleware would be added on which mean routes that did not need it did not run that middleware. Fastify was perfect.
Before I committed to any auth story, I looked at several authentication libraries. Passport is weirdly attached to Express, so that eliminated it. Fastify auth and other agnostic libs didn't look attractive to me. One of the agnostic auth libs I saw reminded my of my custom Authentication/Authorization/Session Management solution. BACK FROM THE DEAD BABY, written in Typescript and less assuming than before.
I toil to the point that my blog runs on Fastify and the Task Management product is released to the public. 😀
Frontend remains on Svelte/Sapper.
Conclusion
Switching software once in a while isn't an inherently "bad" activity. It is quite illuminating. Honestly, to the complainers who say they can not keep up with the changes in software, you really don't need to. Younger people will replace you regardless.
Why should any company or person be stuck to things that could be unmaintained in the future? Because some older guy liked this or that, that's why younger people should hold back and not reap benefits? Just imagine if everyone listened and did what the "older more experienced" said about new software. The kinda software that is "TOO RISKY" "TOO NEW" "SHINY" etc. Yuck, no wonder we have Big Tech. They are so stable tho.
I dismiss people who outright dismiss software that attempt to do better than the entrenched. I'm a big supporter of writing your own thin layer that abstracts the lower level parts. Configuring a Fastify server? Create a FastifyServerBuilder for you company that has good defaults and allows one to customize Fastify. Same with Express. Essentially, lower the cost of switching, so one can experiment.
Spring Boot does this really really well. You can switch web servers easily. You can switch database providers easily. You can bring your own objects to provide what you want. It is insanely good. Using something like Spring Boot helps you, your peers and your company stay agile I think.