Why Frameworks Are Bad For Your Web Site

With a degree in computer information systems from Mohawk Valley Community College, John worked for small businesses and performed freelance work before joining Site-Seeker in 2007.

If you know me, or have read anything I’ve written on the subject of frameworks used in front-end Web development, or seen any of my comments on the subject, like on LinkedIn, then you’ll know that there is no love lost between frameworks and I. Quite honestly, I hate frameworks and dealing with them leaves a bad taste in my mouth. I’ve had to deal with many and I’ve done a lot of research on what they do, don’t do, and how they do it. I have personal reasons why I dislike them, but before I talk about that, let’s talk a little about Site-Seeker and about some of the reasons why frameworks are a mistake to use.

Site-Seeker is More Than a “Web Site Development” Company

Yes, I am a developer, I work at Site-Seeker, and I build Web sites. But Site-Seeker is more than just a company that builds Web sites. There is a whole host of other things that we do that you can learn about by reading the information on this site.

When I build Web sites, I have to keep all that other stuff in mind. When most people think of SEO, they may get this limited picture in their minds of “titles,” “descriptions,” and “keywords.” The truth of the matter is that site optimization begins before the first line of code is written and continues long after the last line of code is done. It is not something that I have the luxury to think about only once a site is complete. It is something that I must think about when I’m planning how I’m going to build a site, while I’m building the site, and after the construction is complete.

If my only job was to build Web sites and I did not need to worry about all of the other variables that I need to think about, if my goal was to just get the project done and move on to the next one, frameworks might make my job a little easier and take a bit less time. (I said “might,” I don’t really think so, but others do.)

Frameworks are Bloated

All frameworks, no matter what they are used for or what they do, are bloated. The reason for this is that they include many, many features and options, so many that it would be nearly impossible to use them all. In order to sell themselves, frameworks need to provide as many features and options as they possibly can so that they appeal to a largest possible audiences. Yes, maybe every feature is used somewhere on some site in the world, but only a small percentage of the features will ever be used on a single Web site, no matter how big that single site is. Even though features are not used on a specific site the code for those features must still be loaded. If there are settable options for a feature, more than likely there are database queries involved in checking those options.
To add to the bloat that already exists in the framework itself, more bloat must be added to make even the most insignificant of changes. You can’t just change what’s there, you must override what it does, add functions to extend or modify it, continuing to add layer upon layer of additional code to an already bloated system. The truth of the matter is that any real coder could accomplish the same thing in the first place without using much more code than they need to write just to make the framework behave and do what they want it to do.

Here’s a bloated image to emphasize the bloat in frameworks.

Bloat slows down your Web site. This slowness can be even more pronounced on mobile devices. We all know, or should know by now, that slow, bloated sites do not perform as well in search results. Therefore, using a bloated framework is bad for your web site. With this in mind, why would I want to use a framework on your site? Why would you want me to use a framework on your site? Why would anyone that knows anything about the impact of site speed on SEO ask why we’re not using some framework that’s all the rage at the popular table?

Frameworks Increase Complexity of Code

Using a framework means that the code needed to make your site function will be more complex. Anyone that says otherwise is blowing smoke up your butt. Whenever you use a framework, there will be additional things that must be learned: more functions, classes, or specific architectures that must be used in order for the framework to function. Some will say, well if you know A and B you can learn to use X and Y, but it’s not a matter of learning and using X and Y instead of A and B. Instead, you must learn and use X and Y in addition to A and B. This increases the knowledge and abilities of not only the person that builds your site but also leads to sites that are…

Harder to Maintain

From the point where you begin to use a specific framework you are married to it. From that point forward, anyone that touches your site to maintain or alter it must be familiar with the framework used. The framework cannot simply be removed without rebuilding everything in it that your site is using. You cannot make the smallest of modifications without taking into account how they will interact with the framework. Making small modification that should take minutes when not using a framework could potentially turn into hours or days of work because of the need to research, learn and deal with the intricacies of the framework. Yes, it may initially take a week or two less to build your site (and I’m still not convinced) but the additional cost of maintaining the site in the future will far outweigh the small initial savings you may or may not realize. The people that create the frameworks and those that use them, in my opinion, want you to be married to them. They do not concern themselves with what it may cost you in the future. They are the ones that will reap the rewards of using them, not the site owner. If you have a site that uses their framework then you’ll need to go back to them when it comes time to make changes.

Harder to Customize

From my experience, most frameworks are not created with programmers, like myself, in mind. Frameworks are created with the non-programmer in mind, someone that does not know how to write and debug code and does not have any interest in doing so. Or for those of limited skill that are not very interested in increasing that skill. They are built so that these non-coders can get a site launched with a minimum of effort and meet a minimal quality standard. As long as they stay within the features that the framework provides and use those features exactly as they were designed, they don’t have a problem.

The moment that you find a feature does not do exactly what you want to do, the way you want to do it, or that you find the framework does not include a feature that you must have, then you have a problem that cannot be dealt with by most of the people employing them. How do I know this? I also do freelance work and you’d be surprised at the number of other developers that come to me for help because they need to modify some feature of a framework.

This is the part that the person selling you the framework does not mention, or they say something vague like… “A developer that is familiar with the framework could extend it.”

That means nothing at all until you’ve been there and the developer you’ve hired gives you the bill for making the needed changes. It could take hours, days, or even weeks to make the needed modification in a way that does not break the framework or make it impossible to update. You can’t simply go into the frameworks code and make changes to it willy-nilly. You need to dig through that code while hoping and praying that the developers that created it have put some hook in place that will allow you to change how it functions or add additional functionality. To top it off, most of the frameworks I’ve met are poorly documented in this respect. The documentation is usually designed for the person that’s going to use it as it was built, not for the person that wants to drastically change how some feature works or add additional features that the creators didn’t think about. Remember, you’re married to them, you’re supposed to go to them when you need significant changes.

I’m a Coder and I Enjoy Coding

Now for what some would consider a personal reason for why I have such a disdain for frameworks: I am a coder and a programmer. I love working on code. I get great pleasure out of solving complex problems that require the use of the knowledge I’ve obtained from more than 30 years of writing and looking at code. The most important priority for me when it comes to my work is that I enjoy the work I do, you could almost say it’s my only real priority. Dealing with frameworks takes the joy out of my life, all-in-all I’d rather dig ditches, with a pickax and shovel, then deal with them (and yes, I enjoy digging ditches.) They remove the need for coding skills, which would cause my skills to deteriorate. Then when it came time to solve a real problem I would be in trouble because I’ve let my skills evaporate while depending on someone else to do the real thinking for me.

Why should my like or dislike of frameworks be important to you?

Ask yourself this: Who do you want working on your site, someone that loves the work they do or someone that hates it? Who do you think is going to do a better job?

I’m Not Alone

Here are some others that feel the same way. If you have time you should give them a read, if you do be sure to read the comments, many are as enlightening as the articles themselves: