I’ve been a web application developer for over 20 years. I’ve seen all kinds of UI libraries come and I’ve seen them go. I’ve been in the industry long enough to know that just because a framework is new and cool and “OMG! Everyone cool is using it!”, doesn’t mean you should use it too.

Speaking from a purely enterprise perspective, which is probably the same perspective you should be looking at if you plan on building the next great SaaS app, you should be thinking long and hard about incorporating any kind of library or UI framework into your app.

Right now you’re small, nimble, you code things in record time and push to production with a minimal number of steps. You’re probably not writing tests, or very few, and all of your builds are done automagically locally.

But if you get successful, really successful, like with hundreds of developers working on your app kind of successful, all of that is going to change. You are going to become an enterprise; and in the enterprise, we do things very differently in the “real world” than you do in the “startup world”.

1. Any changes, even updates, are expensive.

Right now your team is small and you can push whatever you like because no one is, or relatively few are, really depending on your software. You can make changes quickly and easily, push them, boom! Done.

But that kind of paradigm doesn’t fly in the enterprise where all kinds of new and very necessary controls will suddenly be in-place to keep hot-rodding, fly-by-the-seat-of-my-pants kinds of changes from getting into production code and bringing down not just the app, but the entire company.

Every step you add into the deployment process costs you time and money in ways you cannot see when you’re a small startup.

If you unwisely choose the technology stack for your app, especially the UI, it’s going to take a tremendous amount of resources to rip it out and update it. Which leads me to my next point …

2. Avoid “fad” technologies that update too quickly or just come and go.

UI is notorious for flavor-of-the-day UI libraries and frameworks. Handlebars, React, Vue, AngularJS, Angular 2, 4, 5, 6, 7, and now fucking 8. All in the span of what—6 years? I’m sure there are bunch of others I’ve not even heard of yet.

“Angular is not a fad, Beau.” Sorry, it is. In the enterprise you cannot be changing out libraries and updating shit this fast. You won’t have the budget or the resources (“resources” is enterprise-speak for the people who will now hate you).

Each time some library or framework “updates” or changes versions, it costs you money.

3. Cost versus actual benefits.

Think about which UI framework you’re thinking of using in your project or next project. What is the framework really doing for you? Is it saving you time or just giving your application some cool “whiz-bang” features?

“It gives us model and DOM binding! A huge time saver.” Fine, you can do that with a jQuery plugin that you don’t have to compile. Next?

“It gives us an MVC on the front end with model-bound templates for a SPA (single-page application).” Fine, but this is not saving you time; in fact, it’s costing you more time in building pages, compiling, and SPA’s are terrible if you need real SEO and accurate analytics.

At the end of the day, by the time you are done installing all of the crap that you need to actually run the super-really-cool fad-tech UI framework, it’s not easier at all, and all you have done is saddled your enterprise team with hours and hours of frustrating local setup and configuration and IDE integration. It’s nonsense.

Yea, we do it; but it’s NOT easier. I’ve seen enterprise devs saddled with setting up the new wiz-bang technology spend literally weeks working out the bugs in their development environments because someone decided to install a new “framework”.

And at the end of the day, the UI framework, much more of a pain in the ass, much more difficult to debug, than it was helpful in achieving a good clean easy-to-mange front-end.

4. Just say no to UI compilers.

In choosing any kind of UI library the first thing I look at is: does it need to be compiled? If the answer is any kind of yes or “sort of”, then that shit doesn’t get included in the source code.

Now I am not talking about using Gulp or Grunt to manage your UI component libraries; I’m talking about having to pre-compile JS and CSS files into “browser-readable” code. If the browser can’t natively read what you are coding, throw it out.

Yes, I love Sass (and to a lesser extend Less); but I don’t use them. Why? Because even though they can save you time and they do an excellent job of organizing CSS, I really don’t need them. I can organize my CSS just fine without them. What I don’t need is adding extra unnecessary steps into the development process and CI/CD pipeline.

Did you know that you can actually write native CSS and native JavaScript without compiling it first?! YES! What a great concept!

I once interviewed with a really big video game company. You know what their development policy was changing to? Plain ECMA (JavaScript) and CSS. No compilers. No CoffeeScript. No TypeScript. They even ripped out jQuery. I was impressed.

Now why were they doing this? Because they needed to save time and money. Over the years developers had come into their teams, added in all kinds of wiz-bang fad tech into their UI, and then left. Now their teams were saddled with all of the UI garbage that was costing the company millions in developer hours each time Angular or whatever SPA library had an update or an upgrade. We’re talking about touching literally millions of lines of code and tens of thousands of files across the enterprise.

I totally understand why they junked all of it. Now, I personally wouldn’t junk jQuery or Bootstrap, but those don’t need to be compiled to run; and jQuery isn’t updating every 5-minutes either. You can usually update without causing huge regressions, if any at all.

Conclusion.

The reason these fad-tech UI libraries even exist is because of bored engineers working at big tech, like Google, Facebook, Twitter, etc. But at the end of the day nothing works better and is easier to debug and maintain than just pain JS and native CSS.