Tech Stack Modernization, Volume 1

Tech Stack Modernization

How do you know when you need to take the considerable effort of choosing a new tech stack?

There can be a number of signs:

  • Finding new developers willing to work on your stack is getting harder.
  • Newer stacks promise (and hopefully deliver) better performance, faster development or better user experience.
  • You current stack is preventing you from implementing the features or performance your users expect.
  • You need to freshen your resume with a new skill. (Just kidding. Don’t do that ever!)

Changing a client side framework is not something you can do lightly. You have to wait for a new project or a major rewrite. When the time is right to make the switch, it becomes a large and tedious discovery project: researching on the web, talking to developers, attending user group talks and prototyping.

Before you start, you should define what your requirements are and your most important metrics for choosing between frameworks. Your gold standard perfect framework might not (okay, does not) exist, but you need to know what you are looking for.

By way of an example, here’s my list:

  1. High performance. I want a client side framework that can render thousands of dynamic elements and deeply nested components. I want it to respond to model changes immediately and efficiently (and only update the DOM elements that were actually affected). I want it to prevent memory leaks, and clean up event handlers when they are no longer needed.
  2. Fast development. I want a framework with a minimum of “stuff” I need to do for the framework. Creating a component should be mostly about my application code, not about framework plumbing. I’d like great tool support, including full Intellisense support in Visual Studio or VS Code.
  3. Short learning curve. I want new developers to be able to read docs and look over tutorials and get most of the fundamentals in half a day. At that point they should be able to join an established project, follow the conventions of that project and be slow but productive. It’s understood that full proficiency will take weeks, and some dark corners and complex cases may always require some expert attention.
  4. Abundant resources. The framework should have good documentation, quick starts and tutorials. Questions should be easy to search for on the Internet. (Poorly chosen framework names can really hurt this.) There should be an active user community.
  5. Organization and structure. I want the code I write to be structured and organized cleanly. Having conventions in the framework is a plus, but isn’t mandatory (because I can enforce my own conventions). But the framework needs to support decomposing and organizing components without it becoming a burden.
  6. Maintenance. The code I write should be easy to maintain, which means the framework needs to support code that is DRY, readable, cohesive, loosely coupled but also with a minimum of things happening magically (like code being called dynamically in ways that aren’t obvious).
  7. Debugging and diagnostics. I want things to fail fast at compile time (yes, I’m old school). Runtime errors should be verbose and clear.
  8. Flexibility. While an all-in-one framework has some benefits, my picky personality would generally prefer a framework where I can pick and choose aspects I need—and easily plug in other tools or develop my own. I would accept the convenience of a kitchen sink framework, but the benefits need to justify the cost (and still provide adequate customization capability).
  9. Templating. Since we are talking client side frameworks, the details of the templating are a huge factor. I’d like something close to HTML, though I don’t have a strong preference for attribute based binding or handlebar style {{content}}.
    1. Despite an initial negative reaction, I’m coming to embrace the JSX style of React that puts the template markup inline with the code of the model. I don’t need JSX specifically, but I want to have a component’s visual markup as close as possible with its CSS styles and the logic that controls it. If you are unfamiliar with JSX, read React’s JSX: The Other Side of the Coin for a good introduction.
    2. Full Control. I’m abnormally picky about this, but I want to be able to fully control the HTML output of my application. I want to take HTML from a Web Designer and quickly drop it into my code. A framework that changes my HTML output, for example by requiring extra wrapping elements, is a strong negative.
  10. Longevity. This one is difficult to judge, but I won’t be changing frameworks every year or two.

As you might have guessed—based on the fact that I have obviously given some thought to my concept of the gold standard for a client side framework—I’ve undertaken the task of evaluating and choosing a new client side framework for development projects. Here at Stout we do a variety of web development projects for disparate clients, and ideally we’d like to adopt and learn a single framework that we can use on most of our projects.

For the past four years we have been using Knockout.JS. It’s still working well and will continue to be used on existing projects, but I have a few concerns which are pushing us to look elsewhere:

  • Models can be a little tedious to build. Unless you map from existing objects you have to manually specify each property that you want to be observable, while most newer frameworks do this automatically.
  • Knockout performs well, but I have concerns about pushing it further with more and more dynamic data. Most newer frameworks use a “virtual DOM” approach to updating the browser, which Knockout lacks.
  • As I mentioned above, I’d like to have my content markup close to my models. Knockout is better than JQuery style programming, but its data-binding expressions in the HTML are tightly coupled with the data models objects stored in completely separate files. This requires a lot of switching back and forth when building components, and can lead to fragile code with hidden dependencies.
  • Knockout is also showing its age a bit—development and buzz seems to have slowed down.

Frankly, getting four years out of Knockout.JS is impressive for the JavaScript world. I’d love something that will be maintained and improved for that long—and longer!

As part of my discovery, I looked briefly at many framework options. I ruled out most of them, leaving two to examine in detail: Angular and VueJS. Stay tuned for future articles where I go into the details and pros and cons of each of them.

Leave a Reply

Your email address will not be published. Required fields are marked *