maestros

A flashback to Tech Stacks I have used

8 April, 2020 • 7 min read

It was a late-night coding session at home. It must have been several hours of non-stop keyboard typing when I took a breath for a minute.

I looked around, it was dark. I picked up the remote and slightly turned on the lights.

It was then that my gaze fell on the library, and especially my programming-related books. The ones I used to read when I took my first steps as a software engineer.

All of a sudden, as I was looking over there, a flashback occurred... A flashback to all the technology stacks I was engaged with, during the past decade.

It all started with .NET Web Forms

Back in 2011, the very first codebase I ever had the chance to work with, was a massive admin dashboard implemented in .NET Framework 3.5. The glorious ASP.NET web forms.

Everything was meant to live server-side and the user experience had nothing but postbacks. Every single user click was handled by the backend. The page was constantly flashing until the server responded.

I'd like to mention here, a handy Visual Studio feature that allowed to drag-and-drop form controls from a predefined toolkit and bind C# methods on certain events. For example on button click trigger that method.

No need to tell you that my CSS skills reached as far as style="color: red;" or at best moving inline styling to separate *.css files and call them where needed.

MVC and $.ajax to the rescue

If I am not mistaken, I think it was mid-2012 when I first came to the MVC world.

Having adopted the Model-View-Controller (MVC) pattern, along with the usage of jQuery, I was able to get rid of the aforementioned form postbacks.

Now, with the help of jQuery, and specifically $.ajax(...), I could write a JavaScript snippet to call a Controller and retrieve a JSON result. Mindblown!

Having said that, and given the fact that I was still a .NET developer, things got easier for me as I switch from *.aspx to *.cshtml also known as Razor syntax.

As for my styling skills, they were leveled up as I was using the jQuery UI library now.

Using MVVM for the first time

Not much later, around the beginning of 2013, I faced an issue.

Which was that ?

Having obsession to reduce postbacks, by taking advantage of the fact that I could send and retrieve data from the server via AJAX calls, I ended up with extremely large and unmaintainable JavaScript files, including tons of jQuery lines manipulating the DOM.

I was trapped in a nightmare...

All these demanding DOM manipulations caused the application's performance to significantly drop. Not to mention that now I had to deal with spaghetti code.

That's when I first came across the Model-View-ViewModel (MVVM) world for the first time and specifically Knockout.js. To my surprise, by the time of writing this article, it has 9.7k stars on GitHub. I am still struggling to spell ko.dependentObservable which then became ko.computed in latter versions for simplicity's sake.

All joking aside, the MVVM pattern was revolutionary to me back then. Being able to avoid complex jQuery selectors by instructing various HTML elements to which JavaScript values should be data-bound, the codebase was remarkably reduced and improved.

Welcome SPAs & Responsive UI

It was early 2014 when I got involved with a new project that should meet the following requirements. Users should be able to view it from their tablet devices, the app itself should be deployed on a Linux server, and of course, it should be fast.

My first thoughts were... "You must be kidding me... right ?"

  1. Run on a tablet ? Using jQuery UI for some time, I knew it was performing badly, even on desktop browsers. In addition to that, I couldn't find out how would the same screen be equally used on both desktop and tablet resolutions.

  2. Deploy on Linux server ? Being a .NET C# developer, and not having the option to build cross-platform applications with .NET Core until it was released in 2016, I had to search for an alternative solution.

  3. It should be fast. My prior experience with Knockout.js had proven that it was not the best option for handling large datasets.

Not to say much, the outcome was that a whole new technology stack should be chosen to proceed with this implementation.

That's when I first used AngularJS and jumped into the Single-Page Application (SPA) world. I also became familiar with task runners like Gulp or Lineman.js, that I used to bundle and minify the client-side source code.

As for the responsive user interface requirement, the game-changer Twitter's Bootstrap CSS framework became part of the solution along with its 12-column grid-layout system.

Last but not least, I eventually left IIS, C# and Visual Studio ecosystem behind, to embrace Apache, Python and Sublime Text tools.

Literally, it felt like I had to learn everything from the beginning.

Solid Stack, Small Adjustments

I must admit that although it wasn't easy to almost re-learn everything, it turned out that it wasn't that difficult after all. I already knew of server-side practices, JavaScript MVVM frameworks, CSS and styling, as well as deployments. I just had to adapt.

That being said, I liked this specific tech-stack and kept working on it. I had chosen popular tools and within a fast-paced web development community, they fit perfectly.

Nonetheless, small adjustments occurred like using Webpack, in favor of other task runners, to bundle my application.

Additionally, I started building RESTful APIs with Python on top of SQLAlchemy. By using an Object-Relational Mapping (ORM) technique, I was able to switch between various database engines like MySQL, Postgres, Oracle and MS SQL Server, just by changing the database connection string in the config file.

Willing to experience new things, I tried to replace Vanilla JS with CoffeeScript since at first, I liked the Python-ish way of writing in the frontend, but I dropped it since it wasn't that useful as I thought it would be.

On the other hand, I also tried TypeScript and I actually liked it. Although, I have to admit that all this type-checking thing in JS seemed weird to me when it was announced.

Regarding the UI part, I played around with other responsive CSS frameworks like Foundation or various wrappers/themes of Bootstrap.

I went through this stack for almost three years, until 2018.

From Full-Stack to Frontend

Around late-2018 I decided to stop "officially" declaring that I'm a full-stack engineer.

Having noticed that web development was a chaotic place with lots of moving parts, and the fact that more and more development teams switched to a cross-functional model with distinct roles per duty, I decided to play that way. At least four engineering roles. Backend, Frontend, DevOps and Testing. I picked-up the Frontend one.

As a frontend engineer anymore, the things I had to keep track of, had been notably narrowed down. I was able to watch for every single new JavaScript library which was announced every year, focus on frontend best practices and guidelines, as well as try new CSS frameworks. I wanted to improve my expertise in that field.

During that period, I deep dived into the latest versions of React, Angular, ECMAScript and CSS. I also used RxJS and took online lessons for functional JS programming. I learned what Virtual DOM is and experimented with various CSS preprocessors like SASS or LESS.

In addition to that, I got involved with frontend testing frameworks like Jest, Karma and Jasmine as which one to use per case.

My frontend debugging skills leveled up as I learned how to get the most out of the Chrome DevTools and monitor an application's performance on the browser.

What's Next ?

As of 2020, having been working for almost two years exclusively as a frontend engineer, I think it is a good time to start dealing with backend stuff again.

I miss Python, as well as the fact that I used to design and implement end-to-end application features. However, whatever is going to come next, I am open to changes as long as they are related to programming.

Retrospectively speaking, software engineering was never about the code syntax itself or the language specifics. It's all about the art of creating applications that users will use to accomplish their day-to-day tasks.



Thanks for reading!

Glossary and Links

Backend

Frontend

Patterns & Architecture