Top 10 Reasons we should stop using frameworks

Have more fun and produce better, faster, most maintainable apps.

I’ve been coding for more than 50 years, and one thing I’ve learned is to simplify, simplify, simplify. I believe coders should really understand why the computer does what it does. At its must basic level, a computer is a pretty simple gizmo. It can do some arithmetic, and it can do different sequences of steps given the result.

For many years, we coded in assembler or somewhat higher level languages compiled with libraries to handle higher level and standardized activities, like reading and writing files, drawing graphs or processing arrays. That, of course, meant fully understanding how to link to those libraries, which were machine dependent. And this required wading through extensive documentation and keeping track of dependencies and versions.

In those 50 years, the greatest breakthrough for simplicity came with the invention of the web. Suddenly, most of what we wanted to do could be created in HTML and perhaps with some useful web server scripting extensions like PHP or ASP and fairly standardized connections to other servers. It didn’t matter if you talked to the web from a Mac or PC or smartphone — things just worked. HTML5, CSS, SVG and javascript made things more powerful and flexible. From my perspective, we then reached nirvana with the Progressive Web App (PWA) — something one could create in a few days, that would work cross platform as well as a compiled app that took months.

If you’ve seen the 1967 film Bedazzled, you’ll recall that the devil was then still alive and making life miserable by randomly scratching LPs and plucking off shirt buttons before they reached the shelves. In recent years, the devil has been devoted to building css and frameworks to enslave a new generation of coders to be powerless before their own creations. These coders might know how to create a React App or an Angular App but no idea how to fix the other persons code.

The ultimate peak in this Tower of Babel was node.js, which would happily load and update dependencies for 500+ files for even the simplest application. I once commissioned an apparently credible software company to write a fairly simple web app via angular and node.js which — upon delivery — resulted in each page load beginning by downloading hundreds of javascript modules, requiring 45 seconds to first paint. Although I was able to rewrite it from scratch in PHP to load in 2 seconds with no javascript at all, I wasted an enormous amount of time trying to even get the old thing to run on a different server.

In 2019, the thoughtful and much-younger-than-me Hans McMurdy wrote on Medium “Should we stop using frameworks?” My reaction — after the searing experience with node.js and what Mr. McMurdy described as “Dependency Hell” my answer is “Hallelujah YES!”

Now I’ve just completed writing a rather complex PWA over a weekend in vanilla javascript and NO packages — not even for the spider diagrams. No jquery, no Bootstrap, no chart.js, no gulp, no npm. It delivers 60 different data collection and analysis screens, offline in two languages, in under 200k, and scores 100% on Lighthouse. And it was such a pleasure.

So on that high, here is my top-10 list NOT to use frameworks.

1. You have more fun! Coders are fundamentally puzzle solvers. When you figure out the most elegant way to make your own inline SVGs to plot a curve or form an icon, it’s just more fun than figuring out how to make somebody else’s package do it. And why should an icon be 3k when you can do it in 100 bytes?
2. You learn so much more that’s useful. When you write in HTML5 and Vanilla JavaScript, or you style your own navigation bar in CSS, you can learn patterns you’ll use over and over again. Someone has already solved the problem you’re working to solve, and has likely shared it somewhere.
3. You create faster apps. An app that has to load packages will always take a bit longer than one that doesn’t.
4. You create fixable apps. If you’ve ever had to update an app from CakePHP 2 to 3, or Bootstrap 4 to 5, you know how annoying it is when package authors change requirements that require you to change class names across a whole package of pages that depend on them. Even worse, when you have to fix an angular or react app written by someone else.
5. The web might be OK as it is! Since I write for clarity rather than innovative artistic design, perhaps the only font I need is default sans-serif! The fact that HTML flows to fit screens is a GOOD thing — you don’t have to control every pixel.
6. Avoid tools that manage packages. In a 2017 Medium article, Chris Pearce argues that a front-end developer should not only understand packages, they should be proficient using tools like “ Webpack, Gulp, Babel, ESLint, Stylelint, PostCSS, NPM…”. Really? Bulky tools whose only purpose it to manage the dependency hell created when you use packages?
7. DevTools! Chrome’s built in DevTools are just plain awesome to debugging JavaScript, tinkering with CSS and debugging PWA service workers. It is particularly brilliant at teaching you how to make your app more accessible and optimized for search engines. And it is so much easier when you’re just dealing with one layer of CSS.

What would help us be free of frameworks?

8. Better Tutorials. Although I love Google, their tutorials are terrible and often out of date. A good tutorial should include the very MINIMUM you need to know to get the job done, with no styling, no extra packages to distract you — just the straight vanilla code please!

9. Better access to patterns. What a good tutorial provides you is a pattern and an explanation of why it works. But currently, you have to guess at what the question the previous person asked that triggered the response. (I’m lookin’ at you, StackOverflow!). Maybe someone can give us a good tutorial for how to ask questions in a way that helps our colleagues in the future? Or a standardized database of patterns?

10. Smarter defaults. I appreciate that PWAs are a relative new technology, but the code for a simple, cache-first sw.js service worker should be simpler. Here is one that caught me: the default cache match function treats index.html?p=2 as a different file than index.html?p=3 unless you add the {ignoreSearch:true} parameter. Really? Would the majority of users want them to redirect to different files?

Hopefully you will join the movement for eschewing frameworks and regain your love of pure, elegant coding free from bondage to the quirks of package authors!