Frameworks are one of the hugest anti-patterns in software development. They're hard to learn. They limit your creativity. They increase your project's complexity and dependencies. They go out of business and get abandoned. You have to maintain and upgrade your code to match the latest framework versions for no good reason. You have to search for help and ask others for advice when you're stuck. And you probably only need a small percentage of features that the framework offers anyway. They just don't make much sense.

You should prefer core-language solutions to small abstractions to small helper libraries to general libraries to frameworks. Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years. Frameworks are at the far end of software complexity spectrum and you want to avoid them as much as possible. You should be fighting complexity and not embracing it. I don't use frameworks and I encourage you not to use them as well.

In fact, one of the rules for writing software at Browserling is to avoid frameworks at all costs. There must be a tremendous reason to use a framework. So far we've used 0 frameworks and just a few libraries to get things done. I've yet to see someone come up with a good reason to use a framework. Simplicity is the law at Browserling. I've taught my employees well to never choose a framework solution and to try to find the simplest solution starting from the core language and core tools and going up.

Let's go over the reasons why you shouldn't be using frameworks in more details.

Frameworks are hard to learn and this knowledge is generally useless

Frameworks take a lot of time to learn. Instead of learning fundamental tools, core computer science concepts, and programming techniques, you spend time learning something specific and generally useless. Just because someone invented a framework and many people use it doesn't mean you need to learn or use it. People give in peer pressure too easily. "Everyone's using FrameworkA/FrameworkB, I must be using it as well."

No, you shouldn't.

You should be thinking, how do I avoid using this framework? How many actual features or core concepts do I need from this framework? Can I implement these features in a hundred lines of code and be done with it and never depend on this framework? Who are the authors of this framework? Do these guys have a track record of maintaining their code or did they just put it together in a weekend and released it?

Don't learn useless frameworks that have no value.

Frameworks limit your scope of creativity

Frameworks limit the scope of your creativity. Frameworks put you in a box you can't escape. Frameworks make you dumb. Whenever you're faced with a problem you can't just invent a solution; you're limited by what the framework lets you do. You have to seek experts, waste your time and energy to find a solution to a problem you shouldn't have had in the first place if you hadn't used a framework.

You can't let framework authors control what you can or can't do. You should be in total control over your product.

Frameworks increase your project's complexity and dependencies

Complexity and dependencies are bad. You should keep both your project's complexity and dependencies at minimum. If no one controls complexity and dependencies, and no one enforces how software is written, then one dependency leads to another, and soon your project ends up using 25 different frameworks and 5 different programming languages. There should be strict rules what you can and can't use in your project, and someone has to make that call.

Without rules you might save time at the beginning and sound cool using all the latest frameworks, but now your software is so complex that no one understands how or why it works. It's also become unmaintainable. You may not notice it in the first few months as things are moving along quickly, but as your project progresses, your team's productivity will drop because of all the complexity and dependencies. You'll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you're dead.

You should be fighting complexity and not embracing it. Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.

Frameworks go out of business and get abandoned

Frameworks go out of business and new frameworks appear. You have to learn the new frameworks again. It takes a lot of effort, energy and resources. You just spent all that time earlier learning the old framework and now it's out of business. All the skills you accumulated are now useless.

Everyone's hyped about the new frameworks and you don't want to be left out, but in fact you shouldn't even care what they are. Core fundamental tools already let you do everything that these frameworks do and you'll just waste your time learning something that doesn't solve anything new. The more marketing and buzz a framework has, the less you should trust it.

Even worse, framework authors sometimes just abandon their projects or they quit the projects and delete their entire projects. Your entire build now fails because of one author.

Use fundamental core concepts, solid tools and programming techniques that are here for the next 20 years, rather than frameworks and useless libraries. You don't need them.

Frameworks evolve and you have to spend time upgrading your framework versions and other dependencies.

If you wait too long between updates, frameworks have changed dramatically, and you have to spend days adjusting your code and learning the new interfaces. You don't need all the extra functionality the framework developers added. Most likely you don't need anything at all from the new version.

Framework developers can't stop evolving their projects for no good reason. Often software is just done. It does what it's supposed to do and doesn't need any changes ever again. You don't need the latest version of every software. Some of the best software was written 10 or 20 years ago. Use it!

Upgrading versions for no reason is another huge anti-pattern. If software works at version X, then it should stay at version X and should never be touched unless absolutely necessary.

Ask how happy your developers and system administrators are when you have to upgrade from Framework v1.4.3 to Framework v2.0.0. It's the worst time of their lives.

You have to ask others for help

When something goes wrong with the framework or you get stuck, you can't just come up with a solution because you're limited by what the framework lets you do. You have to ask for expert help, wait until someone helps you or pay an expert framework consultant.

If you keep your dependencies to bare minimum, then you're the expert and you can quickly get things done and come up with the solutions without ever asking for anyone's help or advice.

You probably only need just a few of framework's features

I've seen this again and again - someone starts their project with a bunch of full blown frameworks when they only need a few features from each. At this point they have already destroyed their project. "Which frameworks shall we use?" is the wrong question to start you new project with. Start your project with an empty file and use programming and a few helper libraries and core tools to get it going.

Use frameworks only when absolutely necessary

I'm not saying that there isn't a use-case where framework would be good but it should be an absolute exception. The only areas that come to mind where frameworks make sense are mathematically complex areas of computing such as sound processing, image processing, and machine learning, where it would take many months to write the code that does the job. And even then you should try to avoid them.

Friends don't let friends use frameworks

Until next time!


March 11, 2016, 05:29

I've been a proponent of "libraries over frameworks" for a while. In the case specifically of PHP I wrote my opinions here some time ago

Mr.Key Permalink
March 11, 2016, 05:53

I think it is better to use a framework, but to choose a solid one. My thoughts are that projects which choose a framework based on the level of hype, are itself pretending to become a hype. Culture match.

Maybe it's like a person is an average of 5 people he or she connects regularly; a project is an average of technologies it uses. Solid, matured framework choice probably means solid project. For projects whose authors hunt for customer hype, it is obvious to choose everything related with hype. Ascetic projects tend to chose lean dependency stack. Project bloated with all possible technology stack could mean the result is hard to maintain despite many very clever things in it. It's a diverse world.

Otherwise, your arguments are correct and the points are valuable for making decisions. Decision to avoid everything is just one of possible decisions, however.

Hugh Jater Permalink
January 22, 2018, 21:23

Nice bunch of platitudes, bro. You should become a methodology consultant.

March 11, 2016, 07:13

Great article. Plenty of times had similar thoughts and sympathise with you.

Love the quote "Frameworks make you dumb", so true.

Keep up the good work and don't let the Hacker News crowd make you dumb also.

Christoph Permalink
March 11, 2016, 07:17

I completely disagree with this biased article. It seems like you're either using frameworks wrong or it's based on bad experience. You have to make a framework your tool, not be their slave. Then suddenly all the reasons above turn 180 degrees.

amn Permalink
March 24, 2016, 12:25

Very few frameworks, by their nature, let you turn themselves into your tool. I am by no means a very experienced framework user, but I have been through Wordpress, Django, Celery (Python), JQuery, RedMine, and some others, and have not to date been in a position where I could turn either of these into a tool I could really wield. It was always an upstream battle against frames of thinking imposed on me by these. And I don't blame them per se -- like I said, frameworks, by nature, impose limitations. You trade complexity for convenience.

Can you give examples which frameworks you have managed to make your tool and turn the reasons 180 degrees? I am interested in the process --- like, what did you have to do to the framework in question, or a particular way you applied the framework, etc.

Needless to say, I agree with the author of the article. Frameworks rose to the top because there was genuine need to share and reuse logic for rapid application development. That need has been addressed indeed, at the cost of development freedom. Nothing very strange about it, but we can't continue to pretend it's the only way. It's a bad way, but the mind rot has set in, wouldn't be the first area of life where humans have settled for the mediocre alternative. But we need to acknowledge the mediocrity for what it is then.

January 13, 2017, 12:45

Hi, I totally agree with you, but I have some other thoughts and lets just put aside the fact that jQuery is not a framework.

I have just spent 6 months wrangling Django, more specifically the admin side of the framework, and yes, it is an opinionated beast. Most frameworks are. They are built by developers who have an 'aha' moment about how things should work, then they build it, viola, a new framework. I agree that using a framework stifles creativity, but the irony is that a framework is a creative solution to a perceived problem.

SO was I able to use Django creatively... kind of, did I have to fight it to do what should be simple things... definitely. But when I needed to do something which the framework was built for... Oh the wonder and simplicity. I needed a database table to be searchable... ok, just give a list of searchable fields as a class member and bang... searchable database table. If I tried to code that from scratch, a) I would have just built the same thing over again, and b) it would have taken me far longer than setting a variable in a class.

To put it simply, frameworks are simply tools you can use to get a task or set of tasks done, without writing the code yourself. They are not meant to allow creativity, they are meant to be the hammer to the nail, nothing more. If I need to cut watermelon, will I choose a hammer? (That could actually be fun).

Another reason of why to choose a framework is recruitment. Yes, you can be super creative and solve heaps of things with your own code, but then any dev to come after you needs to understand your thought process, and style of coding. Why do you think the largest companies in the world think Python is great... one word... formatting. You can raise a pull request, and the way the code looks wont be very different between every dev on the team. So it's a productivity thing, If Company A uses framework Blurg, then it can hire Blurg developers, contract them in or out, and get productivity off the starting line. Otherwise every company you walk into would be like learning Angular all over again! Possibly worse if you happen to get hired by the PHPSpaghettiMonster.Org

Whats my point here? Basically, I don't think frameworks are evil, and I do think solving problems with your own creative code is a dying art. I want to blend both worlds, because writing the same boilerplate crap day in and day out is depressing, but trying to figure out why coolframework5 just wont stop converting all my strings to ALL CAPS is a pain I don't need.

Both approaches have their place, when used in the right way. We just need to learn when to use them!

BTW, I totally made Django my biatch. I killed off a bunch of plugins, took it back to core Django + Django Rest Framework, sprinkled on some Angular, then overrode that puppy till it was half dog, half machine. My productivity increased after 2 months, I took the defect rate way down, and I didn't have to spend ages doing some basic stuff, allowing me to get the UI to an acceptable state of usability. I definitely solved some problems in a creative way, using lesser worn paths or Django development.

Nice article :)

sol Permalink
March 11, 2016, 07:22

I also disagree. That's a huge generalization, obviously based on negative experience. A framework helps build better software, with structure, especially in large teams.

I also think that you're not quite honest because whenever a team builds software they create some kind of framework. Be it a re-used solid framework as mentioned in other comments, or just a OO structure of classes. But you do it because otherwise it would result in a mess.

So isn't it much better to use a solid framework that is maintained by a lot of people, than your individual reinvented wheel? Yes, it is. And the overhead mentioned in your list is far outweighted by the benefits.

mhair Permalink
March 18, 2016, 15:42

This may be true, but when you're living this negative experience (, it is easy to understand how the author came to the conclusion. I'm living it as we speak. Zurb Foundation 6.x ( has been a, "less than stellar experience" and though they claim to be "slowing down and shoring up", that is starting to sound hollow since they said the same thing on the last point release, plus they've been promising things for nearly 4 months (like a migration guide), ignoring user's pleas.

One thing that does ring loud and clear in this author's article is to beware of hype. Zurb hyped this release greatly, which encouraged people to "depend" on it, claiming many solid enhancements such as much greater accessibility features that I fully support. Then they delivered a maze of problems in their build system, so much that I don't have any idea about the rest of the codebase since I can't get past the "modern tooling" to actually compile the code completely. People are now heavily invested, and it doesn't sit well with their own pressure to deliver projects. I'm actually reconsidering all of my alternatives right now after 3 months and other users have announced "farewell."

Major frameworks with a large user base have the responsibility to treat their "product" exactly how a "product manager" would. With the highest regard for user experience and ROI of time spent. That means strict quality control through testing and explicit documentation. Without that, and with a new paid support option I might add, it would appear they have a conflict of interest, or at the very least, a very questionable approach to revenue, one that certainly is not sustainable if they lose their user base. Their previous version had a rightfully good reputation. At this point, they need to quickly understand "product management" in order to recover their brand equity before it is too late.

Yet with all of this said, I feel a bit of their pain. Just as we depend on them, they have major dependencies themselves, perhaps this was their greatest flaw. As the author implies, and with my own experience in this situation, with level of complexity and sheer number of dependencies, a certain amount of chaos, and thus "churn", is a statistical certainty. Reducing dependencies….especially for frameworks….is a laudable goal. In general, I still support the use of frameworks in situations such as my own where I don't have a large team to help build our own solution, but I will think more carefully about each of the author's points each time a start a project from here on.

Alfred Permalink
September 25, 2017, 08:39

If Zurb is all you can think of when talking about "frameworks", I don't think you've got the point right.

Grant Parks Permalink
October 04, 2016, 16:50

Programming is not "inventing wheels". Your first sentence says it all "with structure"; a framework is a substitute for system design used by those who can't design software. A framework tells you how to configure it. It becomes configuration instead of designing and coding. It's a different, more commonly available mentality because the demand for software development exceeded the supply of excellent developers long ago.

AeroNav Permalink
September 10, 2018, 18:20

The core of the problem is not the idea of the framework to facilitate starting up a project, it is the ridiculous complexity and time needed to learn it. absolutely ridicules

evil error Permalink
December 07, 2018, 18:09

Ridiculous complexity and time needed to learn? C'mon, most of existing frameworks can be learned in like few days. And most of micro frameworks and third party libs can be learned in like few hours. I'd have to totally disagree with this article. Sorry.

March 11, 2016, 07:31

I do understand that your article may be tuned to a "expert" audience although it came across as a generalization.

I am not a programmer and not a designer. But, I have a urge to create things. I tried to code on my own but failed miserably to crank out anything of value for about a year. Then I discovered the idea of frameworks. A combination of better programming knowledge and a good choice of frameworks (codeigniter in the past and meteorjs now and bootstrap), I am able to develop fairly useful applications that actually seem to deliver value for the very few users I try to serve from time to time. They seem to be happy most of the time and so am I :-)

March 11, 2016, 07:38

15 years of experience in 7 separate companies - yup, I know the type.

Haha Permalink
March 11, 2016, 11:59

Good one

TI86 Permalink
March 11, 2016, 16:20

i know right lol. guy's a complete moron.

Brett Permalink
March 11, 2016, 07:48

Have you heard of "not invented here" syndrome? This article is practically preaching that anti-pattern.

Frameworks are about code reusability and not reinventing the wheel. Are you saying that you roll your own logging solution for every project? Refuse to use ORMs and prefer to write every SQL statement by hand when performance is not yet an issue (premature optimization being another anti-pattern).

I'm not sure what frameworks you've had experience with, but this sounds like a problem with the frameworks themselves or their usage.

Learning curves might be a downside, but the upside is that if a new employee already knows the framework, your project has -less- of a learning curve. As they don't have to learn your custom in house crap that does the same thing.

Christoph Permalink
March 11, 2016, 08:07

Could not agree more!

David Permalink
March 11, 2016, 08:45

ORMs are just making things more complicated. It's not a big deal to write SQL statements. Also logging is not a big thing, maybe you could save typing some code, but that would take only an hour or so.

Catman Permalink
March 11, 2016, 10:12

Hmm David, I would like to test your apps againt SQL injection. Would be intresting. ORMs are great when it comes to the point of code reading or efficiency. When you avoid ORM you just making your life harder.

Marco Permalink
March 11, 2016, 10:20

You don't need an ORM to avoid SQL injections. All you need is to encode the query params. And then? That's it.

The advantage of an ORM is *just* to make it look like a bad OOP language. Everybody should know that SQL != OOP. Each technology needs to be used appropriately.

ORM and efficiency should never be used in the same sentence.

Christoph Permalink
March 11, 2016, 10:45

Obviously you never came across the concept of being platform independant..

bro Permalink
March 24, 2016, 13:15

Can you please elaborate, like, how is SQL platform dependent and ORM is not. I don't understand where you are pointing with your sentence.

David Permalink
March 11, 2016, 10:36

I was using an ORM and I learnt SQL just yesterday and now I don't know what all the fuss is about. To defend against SQL injection you only need to call a function. So you have more lines of code, but that's it.

Goliath Permalink
March 16, 2016, 00:46

So basically you copy&paste that line all over your code?

Copy&Paste programming is bad, okay?
You are sure to mess up sooner or later, and if not you, then the maintenance programmer who has to keep your stuff running after you left the company (or the project or whatever).

Boilerplate code is bad, too, okay?
Ideally, each line of your code does something important, and functions and objects abstract away any details below the detail level of your code at that point. That (and a number of other things) makes code readable and maintainable.

At best your extra lines take up monitor space needlessly. At worst they distract from or even drown out what your program really is supposed to do. (IDE code generators are quite like snorting acids up your nostrils to deaden your sense of smell against the stink of boilerplate code.)

Finally, the *correct* way to handle SQL injection is always using place holders in your query (and binding any variable data to them).
Not only is that pattern distinct (and more noticeable when not used), it also allows the DB to compile, cache and optimize the query. That comes handy when you handle larger amounts of queries and data --- i.e. when bad database performance is most noticeable.

So the only defensible answer would be: "I use a single function/method/routine/... that handles all SQL queries and their input data and there all the data is escaped before it enters the query."

bro Permalink
March 24, 2016, 13:07

Wow, you heard of SQL injections. Here is a star, bro. Now, can we continue with productive arguments, please? SQL injection is not a problem inherent to use of SQL as such. It is partially relevant when user is able to compose their own SQL queries, for malicious or other use. Talking in favor of ORM because it eliminates the threat of SQL injection makes you sound like a cool weekend hacker on a weekend hacker conference. All the other hackers will clap and tap you on the shoulder because you namedrop all the cool buzzwords, but a computer scientist will just recall why he went to college instead, where he learned what potential advantages and disadvantages of ORM and SQL are.

"When you avoid ORM you just making your life harder." -- I think what you wanted to say was "When _I_ avoid ORM, I just making my life harder." Don't impose your limitations on others.

Also, read up on ORM mapping problems. I am sure you don't have them, probably because you don't take your underlying data model into account, but some of us do care.

Dave, in all honesty, I think you should accept Catmans proposition -- free test for SQL injections, man, that stuff don't arrive in the offer box every day.

Christoph Permalink
March 11, 2016, 10:45

Sorry but this is a very stupid statement. Then why use a high level programming language at all? C is not that difficult.

Abstraction is important.

David Permalink
March 11, 2016, 11:19

C is certainly not difficult, if you're careful enough. You don't need to learn a lot of concepts to understand it. You just need good coding skills to use it.

Use a high level language if you want more productivity. It's the same with ORMs: you can get more productivity, but then your software won't be so elaborated. It may be fine for some people. I would say that the difference is that there are more drawbacks of using ORMs than a high level language.

ryan Permalink
March 11, 2016, 17:42

You seem to be conflating libraries with frameworks.

I'm completely lost on the "use an ORM instead of SQL" to avoid premature optimization." What? SQL is an optimization now?
One could argue that an ORM is an anti-pattern.

Craig Permalink
March 15, 2016, 02:09

ORMs are not a framework, they are a library which the author doesn't have a problem with. Frameworks are overarching where an ORM is usually just back end.

bro Permalink
March 24, 2016, 12:57

First of all, there is a wide area in between rolling your own and using a framework. Libraries comes to mind. Second, ORM has not solved the mapping problem in a definite manner, there are still some open questions left, being tackled differently and with different degree of success by different ORM frameworks and libraries. There is nothing wrong with SQL, it has been around long enough and is considered to have met its design goal of facilitating data queries. Using SQL instead of ORM is arguably not premature optimization, but a system design decision. Third, I hear too many times people rebutting framework criticism with "I dunno, you must be using some weird frameworks". In my educated opinion, frameworks have you trade in development freedom in return for providing efficiency, but the problems this entails, as listed in the article, are *inherent* in the concept of frameworks, and to a much lesser degree in which particular framework it is. I.e., all frameworks suffer from the points the article outlines, but indeed the better ones are attempting to address them at least. Still, the median value makes the points valid, in my opinion again. Fourth, employees can and should be expected to know certain fundamental things as well, such as abstract data types and perhaps application of different programming paradigms and best practices, even controversial ones. The fact that they know React or Angular or some other framework is secondary to these other things, and if they know these things, your argument that knowing a framework is somehow beneficial is a matter of managements preference. If it's a shop that needs to save money and thus floats on frameworks all day, that's fine. But don't shoot the author down with a comparison to "in-house" crap -- like I said, there is plenty of things to choose from between in-house crap and a framework (which may be somebody elses in-house crap turned into export product).

Grant Parks Permalink
October 04, 2016, 16:51

Frameworks are the opposite of code reusability. Where can you reuse unless it's another project w the same framework?

Bashkim Permalink
August 07, 2018, 13:49

Lol don't be too hard on them, thinking for yourself is hard these days.

Anonymous Permalink
March 11, 2016, 08:36

Frameworks are useful. I agree with several points here. People do tend to use frameworks because of hype instead of use. But it is the same case with programming languages and libraries as well. Higher level programming languages are nothing but frameworks which abstract away how things which we don't need to bother much about - how variables are pushed onto a stack, garbage collection e.t.c.
If you want to write a web app. What would you do? You would first prefer something better than C++. Why? Because previously C/C++ was mostly used for CGI and it would create heavy weight processes and you would need something light weight to handle good traffic. If you choose python for automatic garbage collection and all the higher level programming constructs or ease of programming. You should still prefer to work with a programming framework like flask or django. Why you ask? Because you don't want to waste time creating functions to print http headers implementing cookies, sessions e.t.c. Also if you want your web application to be secure you not only want to be sure that the framework that you have chosen provides those guarantees but also need to know the framework thoroughly to create a secure web application. Libraries are generally modular(or atleast should be) so that you could plugin functionalities that you need. However, frameworks try to take the approach of being bloated and add all functionalities packed into one so that they add certain features automatically instead of the user trying to configure them(convention over configuration). Most of the time choosing to implement something on your own vs trusting other frameworks to do that job well is because of the trade-off of time vs complexity. Frameworks don't generally become popular because of hype. They are popular because they solve problems which people repeatedly encounter when trying to build a particular kind of application. Frameworks(especially those which are open source and popular) learn from mistakes of several people and embody lot of experience. There are scenarios where people get stuck because the framework was not intended to handle a particular use case and sometimes it creates problems for people trying to use it for that extra use case. However, as more people encounter the same use case - either a new framework crops up or the old framework gets a new feature in a new version. Newer version of frameworks fix bugs and not always add new features. Up-gradation of libraries for the sake of it doesn't make sense. However, if you are getting benefit out of it - interms of security or usability - I see no reason as to why it shouldn't be done whenever a new version is released, especially when the software/application is in use or production.

March 11, 2016, 08:47

Such a well written rebuttal of the notion of "framework"! (as opposed to "library" — we all like libraries) And then the comments...! Oh the humanity! Here I go...

@Brett — yes, you SHOULD write SQL from day one. Performance WILL be a problem and you don't want to rewrite large parts of your program when you discover that your appealing ORM makes hundreds of queries to fetch data that could have been fetched in ONE query. Embrace SQL, it's not that bad! (and I can say that from vast experience).

And the learning curve is a HUGE downside. Say you went to conferences, bought books, attend online courses to finally learn what Angular 1 is all about (service, factories, service providers and service factories, and let's not forget, transclusions! wtf is all that? and then you hire a large team to write an Angular 1 app (a small team won't do, because Angular) and you invest cash and spend years to get it done. And then boom — Angular 2 is announced, which is a completely different beast.

Wouldn't that time had been better spent learning what Web programming is actually all about? Start with HTTP, it's an important bit, then move to HTML, CSS, JavaScript and DOM. THAT's what you need to learn about, not transclusions and configurator service factories.

I can't believe people are taking Angular 2 seriously by now.

@Santosh — I have nothing personally against indians and I've met a few brilliant guys, but *most* of you guys just learn to glue pieces of code from the Internet and call yourselves programmers over night, and then work for ridiculously low prices, producing crap software which eventually will be the nightmare of other developers.

If you're not a programmer, as you say, you should stop writing code. And if you do want to become a programmer, then start learning some actual computer science rather than mixing together Bootstrap, jQuery, Angular and Code Igniter into that mess you call application.

@sol — the more "solid" a framework is, the harder I'd run away from it.

@Anonymous — If I were you, I'd first learn to write. You see, rather than writing a page-sized wall of text you should try to split it into paragraphs and meaningful ideas. People like you are the reason why the vast majority of Websites out there suck so badly. YES, dammit, learn about HTTP headers and cookies instead of using those frameworks you don't really understand.


David Permalink
March 11, 2016, 08:55

I completely agree. You can learn SQL in a day at most. And then we use different ORMs, each having a learning curve and taking more time to learn than SQL. Also the performance is not that great.

March 12, 2016, 03:49

Our company has a well designed database having several hundred tables. It has been refined over years to offer incredible efficiency and performance. It is remarkably consistent in making convention and use of appropriate types. It is not unusual, except in its consistency and elegance; nothing fancy or tricky, just solid, careful design. We interview hundreds of engineers having usually CS or Masters degrees, and many senior engineers with years of experience. We interview extremely smart people. Yet a very small number of candidates are able to successfully implement the basic SQL needed to query several tables. It's not because the sample is too hard, or because the candidates are dumb. It's because SQL is hard -- not the syntax, in particular, but, like C it's a very terse and compact language used to express more than a few, indeed arguably most or all, data relationships. I "learned C in a day" after reading the book. I learned SQL in several days. But understanding how to write software, and manipulate data well is my life's work. In my 50s now, having lead many engineering organizations and written much software, I have come to see that those having great hubris, disdain and impatience are typically blind to their own ignorance (often correlated with truly brilliant, yet utterly ineffective developers). Those humble (humbled?) enough learn how to use the abstrations that minds more brilliant have created are invariably the best engineers. Using their abstractions mindfully has helped me understand that SQL I learned in a day back in 1985 quite a bit better in the intervening decades.

March 12, 2016, 09:46

Now that the ranting fever is over, I will concede that ORM-s are useful, in the simple case where you need one or more rows from the same table (no joins). I don't use them to express 1-1, 1-N or M-N relationships, though, those would usually produce more queries than needed.

Bottom line is, with or without ORM-s, one has to know SQL in order to produce an acceptably fast and secure application; for example generating queries as strings and interpolating variables PHP-style, "select * from Users where id = $userid", should be strictly forbidden.

ORM-s are not frameworks, OTOH.

March 15, 2016, 08:38

That is a wrong assumption. The quality of SQL learned in one day will not give you any performance win.

sol Permalink
March 11, 2016, 10:47

Please provide a base for your arguments

Justin Winslow Permalink
March 12, 2016, 04:32

> hire a large team to write an Angular 1 app (a small team won't do, because Angular)

This is a bit silly. My 2 person team built a large, complex angular app that was paying our salaries after 1 year, to now (just crossing 2 years of development) paying our salaries in a month and steadily growing. I don't even like angular and I'm here defending it.

Matijs Permalink
March 12, 2016, 15:46

If you didn't (or don't) like Angular, what made you choose Angular? What problem you had did it solve that couldn't not be solved by other frameworks, or better yet by avoiding a framework?

March 15, 2016, 08:37

Although I agree with some statements, the way it is written, the lecturing style of super-programmer, is very unappealing.

Generalizations about SQL (what if I never use SQL and ORM at all), Angular as notorious example, rant about people from India (like this type of devs isn't everywhere), finally lecturing someone for "bad" writing style.


Will Permalink
March 15, 2016, 08:45

@Mihai, you know there are 1 billion people in India? It's meaningless to make generalisations about a whole country of people. There's a word for that.

Getting a bit off topic here, but I do know what you're referring to. There are surely some very bad programmers in India. And there must be some very good ones too. And there are also bad programmers in the US, UK, every country. The point you're making is more to do with global economics and culture than level of skill.

Silime Permalink
March 11, 2016, 09:01

Choosing a framework for a project is like answering a question: which one is better -- a formula racing car or a truck? The correct answer is -- neither. The best option is to use a bike… that can fly… pulling behind a row of train vagons filled with nitroglycerin and is able to land them safely.

In my eyes this is exactly the difference between using a framework and using the full power of the base programming language with lightweight abstractions. Yes, the cars are more advanced and suited for specific use cases. No, programing is not the real world -- the simpler solutions are always more powerful.

Side note: you may get a little wet when flying in the rain. Just remember -- you can always fly higher above the clouds ;)

Man Permalink
March 11, 2016, 09:58

No way man! This is the most stupid post i've ever read. Frameworks is the same as programming language - it is also a program, a tool. Seems you just don't know how to cook! ;-)

Catman Permalink
March 11, 2016, 10:15


March 11, 2016, 10:48

I mean that sometimes it's better to use only programming language, if it a short task and you are single developer - for me it's a great to use only programming language without any dependencies, when it's possible.

But if you gonna work in a team, i think, you would appreciate the role of frameworks. It's really hard sometimes to explain other people how you write, you have to explain or even write your own manual - it's your right to choose tool you like. Nowadays some "frameworks" are just rubbish, and i'm completely frustrated by some of them, but it doesn't mean that this tools cannot exist, one day they may save a lot of time for you, your project and your team.

Anyway it's good that you shared your point of view, i'd really appreciate this.

sol Permalink
March 11, 2016, 10:48

Exactly, library = abstraction, framework = abstraction

alexander Permalink
March 11, 2016, 10:02

Great article! I completely agree with most of points in this article.

Cat Minh Vo Permalink
March 11, 2016, 11:05

Well, I totally agree with you. I usually avoid a big framework in big project, and stick with libraries rather than framework since we need a library to get thing done.

Satish Permalink
March 11, 2016, 11:33

Well, the pain of the author is quite evident from the article but I would like to add that choosing the right framework and programming technologies are very important, right from the beginning, depending on the software requirement.
Usually developers just go with the most famous framework or the one that shows the maximum performance in the "benchmarks".
Frameworks do help but I like to chose frameworks which are lean and can be understood simply by going through the source code.
For eg., falcon/bottle for python compared to django/flask although former satisfy particular use cases. (API)

Raj Kamal Permalink
March 11, 2016, 11:33

say by "framework", did you mean "js framework"? cause I certainly have no intention of abandoning Laravel(php) or DotNet(C#) for (shitty & buggy) code written by me (and tested by none).

ares Permalink
November 24, 2017, 09:38

so encapsulating your shitty code into framework boilerplate makes it good?

March 11, 2016, 12:32

One problem i see is that this is driven by lack of knowledge from two sides. One side if Management which see frameworks as an answer to all their problems. They are not sure why but FWork XYZ blurb seems to solve all their needs and means anyone can do it and they don't need to pay high contractor fees as "everyone" can use it. No mater how many times they are burnt by this approach they repeat it. The other side is the 3 months out of college graduate or some other method of learning to be a "Web Programmer in 3 months" who can manage JQuery or has a basic grounding in (say) Zend or Angular and this make them ACE web dev, or Javascript Programmers or PHP Guru's. And this will not go away. Ever.

daniel combs Permalink
March 11, 2016, 14:18

I was actually talking to a coworker about investing in frameworks is a waste of time. If you have been in IT business for 15 know the shelf life of internal projects (from my experience) is 4-6 years. Then some new management/executives replace it with a IBM, HP, Oracle product and the cycle repeats.

March 11, 2016, 15:23

While I see your point, I'm concerned about the absence of standards and frameworks as it relates to application security. As an architect, my goal is to minimize the number of "gates" for engineers. Coding frameworks assist in that effort, because it means Information Security doesn't have to perform manual code reviews all the time and software engineers don't have to spend time becoming security experts. My goal is always to bake security in so that it supports the DevOps process.

NanoDano Permalink
March 11, 2016, 16:19

I disagree with most of the post here. Good frameworks are built on those small helper libraries and you do get to pick and choose which ones you need. It doesn't take *that* long to learn a framework (a week or two) and it would take longer than that to build those libraries yourself.

I have tried all the different approaches and I always go to a framework. There are small and lightweight ones like Flask and there are ones better suited for other projects like Django. On the PHP side I can't think of many micro/lightweight ones but Laravel and CakePHP are both good. I can't speak for JavaScript. I would say there are too many frameworks for that language.

TI86 Permalink
March 11, 2016, 16:31

op is a complete moron and has probably never programmed in his life. this is the stupidest blog post i've read. die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot die you idiot

Unknown Permalink
December 13, 2016, 17:28

^^^ Perfect example of a framework.

Badly structured, useless if you know how to do things the correct way, and full of bloat.

ares Permalink
November 24, 2017, 09:40

is this coming out of your controller factory controllers?

AeroNav Permalink
September 10, 2018, 18:11

what a copy-paste monkey

March 11, 2016, 19:04

"Good Coders Code, Great Coders Reuse." -- Peter Krumins when he came up with a name for his blog.

I normally agree with you Peter, but in this post you not only contradict yourself, but it seems like you've gone off the deep end. eZcomponents, Zend Framework, and Symfony; to name a few leading frameworks, are designed to be composable so that you can write the parts you NEED to write and reuse the rest. And leading frameworks are written by professional programmers, fully tested and already widely deployed and real-world hardened.

But you can start from scratch if you want to. You should probably change the name of the blog though. Something like "I wrote this v0.0.01alpha"

plucs Permalink
March 13, 2016, 09:42

Blog name does not need to be changed.

If there is good code there is the option to reuse it without needing to use a framework.

Mr. Key Permalink
March 15, 2016, 05:17

Completely agree with your point. From my personal experience it requires a lot of knowledge to understand that and to be able to understand the mentioned components/frameworks. Novices tend to do everything by themselves and that is a normal behavior in learning path. I would not name them kids, but they are not fully grown up to understand that time is a very, very limited resource, and it is not smart to reinvent wheels. This Peter's opinion is somewhat strange, biased and I can not take it seriously.

As a note. Recently I did not even consider job opportunity when CTO proudly announced they are using no frameworks, no commercial development tools. Kind of primitive cave culture? When reading this article I started to wonder what kind of developers are in a team which avoids to use frameworks.

Marty Gentillon Permalink
March 11, 2016, 22:50

Fundamentally, frameworks are essential to development. Nearly every application depends on one. You can hardly even do web development without a framework, and if you try, the first thing you will do is to write one. In fact, if you are an application developer of any kind, I strongly suspect that your application is using a framework right now. The only real exceptions I can think of would be if you were developing an operating system, or building an embedded system.

Think about it, In order to terminate a web request, there are at least a half dozen things that have to be done. Things that are the same for all requests. Things that you don't want to write more than once. Things like reading the socket, deserializing and verifying the data, checking authentication, taking metrics, recording logs, and handling protocol details. To add a new resource, you don't want to worry about these details, and if you had to, your system would be massively more complicated.

Enter the framework, to handle a new resource, all you have to do is write a handler, add a template, add a schema, update the routing, and record a few other details. Of these, only the first is really essential, and some frameworks will auto generate others.

The next question arises: what kind of framework should you use? Do you want something with an all included mindset like Spring? Do you want something with a composable slightly bare bones approach like Clojure's Ring and Compojure? Do you want something more in the middle like Ruby on Rails? Do you roll your own?

There are tradeoffs here, Frameworks like Spring tend to be complicated, limit one's flexibility, and require a bit more work to understand. Not an ideal situation surely, but, if your application's needs happen to match the framework particularly well, they can save you from having to write a massive amount of code.

Bare bones frameworks tend to give you more flexibility and are often better designed, but require a large amount of customization. Usually, this is a better tradeoff, as the increased flexibility will pay dividends, but it can result in fewer initial features, and slower initial development (as you build the framework up to the level you need).

Rolling your own framework from scratch is nearly universally a bad idea, requires an expert, and should only be attempted if you can't find something that meets your needs. Fundamentally, there are a large number of problems in developing an application that you won't know about until you encounter them. Using something that was developed by experts and has lived in the wild means that someone has probably already fixed half of these problems. Using something that has has multiple users means that when you encounter a problem, there will be someone to help. Don't give up these advantages trivially.

Remember, you are going to own your framework. So, pick it with care. How stable is it? How complicated is it? Take a brief look at the framework's code, does it stink? Take a look at the framework's API, do you like it? Understand the framework's features, are they what you need? Think about how your application should work, will this framework get in the way?

freddyf Permalink
March 12, 2016, 02:56

agree 100%. Frameworks are a crutch for inexperienced coders

March 12, 2016, 12:00

What i can say... OnceBuilder is new type of framework, it's just frame for websites, comming soon!!! :)

Marc Permalink
March 12, 2016, 12:30

If you are not picking a framework you are building a framework.

I too am a DIY programmer and I agree with everything in the article.

People that download some software off the internet and configure it are not programmers, they are configurers.

bro Permalink
March 24, 2016, 13:32

No, when _you_ are not picking a framework, _you_ are building a framework. Don't put us all in the same basket, please. There has been invested an enormous effort since the 70's to produce design technique for producing software systems that specifically avoid resembling the kind of system a framework is. There are several principles, from many people, so we're still working on it, but people like Robert "Uncle Bob" C. Martin have some fantastic insight, which may help you not build frameworks. I hope you find it useful, and please, please, please, don't propagate lousy engineering, for the love of your co-workers or whoever inherits your source code.

plucs Permalink
March 13, 2016, 09:36

Agree 100%. Things must be kept as simple as possible to write production code. Just use the core language features and program the bare minimum to solve the problem.

Frameworks are turd handcuffs.

March 14, 2016, 09:20

small, medium and large enterprises wants their software in frameworks and developers just want to adapt due to company request else you lose that customers or that job. i agree with you, you can create the same software out of the core language features itself without using a framework. frameworks are really pretty hard to learn, it's like learning a new language itself.

March 14, 2016, 09:50

I've yet to encounter a framework that isn't more trouble than it's worth.

A framework may make it initially seem like you are making progress fast - but it will almost certainly bite you in the arse.

I don't see how a framework is ever a good substitute for building your own codebase.

Anyone can learn a language and so use a framework. But having a comprehensive codebase of your own is what makes you a capable programmer and problem solver.

If you are solving problems using frameworks then you are designing programmatic bumble bees. They might be persuaded to fly but you'll never deliver the best solutions.

March 14, 2016, 17:11

the only reason I would agree with "no-frameworks" argument is, if you already have some level of mastery of any of this: Laravel/RoR/Django/Java Spring. Because the mere fact that you have huge issues in understanding the frameworks (not even use it, but at least know how it works internally ), I doubt you can mentally digest all the tasks needed to build a serious "core" codebase, and it will most likely end up with spaghetti codes.

mortenb Permalink
March 15, 2016, 00:37

Making an effective Core out of Spring is very challenging. You can cherry pick exactly what You need. I managed to build an app with only springboot and autoconfig saving 600MB from the initial Drag in everything maven pom that the original developer used.

March 15, 2016, 22:14

i think in my previous comment, i did not said he should build the core out of spring (or any framework). What im trying to point out is, before you head building your own core, study the internals of other framework, and you are right, cherry pick the features that you need.
that is to contradict the author's statement about
"Frameworks are hard to learn and this knowledge is generally useless"
which is not true, you can learn a lot from a framework, and if he have hard time learning a framework, how do he expect me to believe he can build one from the scratch?

i mean, sure, you can build your own bike by cutting down your own rubber tree for the tires and mining your own iron directly from the mountains to build its components. But how do you expect me to believe you can do a decent one, if you are having hard time operating a simple bike-spare-parts assembling machine?

master any framework first, before rolling your own.
dont go for "core", just for the mere reason that you are finding hard to understand frameworks.

ares Permalink
November 24, 2017, 09:46

"finding hard to understand frameworks."
understand what boilerplate? you ppl are brainwashed

March 14, 2016, 19:01

Firstly, I'm impressed the amount of trolls around here (no reading comprehension and just cursing everyone). Very odd.

Secondly, about the article's contents, I agree on most of the arguments but I'll add that sometimes there are business needs that fit perfectly well (or up to a good percentage) with frameworks and the team's skills set. I wouldn't say it happens a lot since in my experience, it doesn't, but when it does, it's a good choice that would provide much advantage on time and effort.

Thirdly, to those readers/commentators that see in this article a root cause given by a bad experience with frameworks, well... it could be true but that's a long shot. What's being explicitly put here is an example of a successful project that's being made with zero frameworks... I mean, that's the motivation, right there! Why would you think otherwise?

Finally, I'd like to stress the importance of choosing a framework or not given the business needs and the team you might want to put into the task. To me, a good framework would embrace typical business needs and add value to the solution by getting work done by the team in less time and with a high confidence level of correctness underlying on it (those are the things to evaluate). It's up to the developers decision to choose the framework's features instead of the core language to solve things that, like Peter said, were programmed like 20 years ago and they work just fine even now.

dogboy42 Permalink
March 14, 2016, 19:48

what's the best framework?

Kent Fredric Permalink
March 14, 2016, 22:18

There is rarely if ever "best" in IT. That question is, uh. best not asked.

There are only "good choices that work well with my other choices".

You always have preferences you have and trade-offs you have to spend.

"Best" is a red herring. You will at best find a "best for me", or a "best for my project" or a "best for my team".

Once you accept this, your ability to converse with people productively becomes greatly amplified.

mortenb Permalink
March 15, 2016, 00:22

I tend to agree, but I have deadlines to meet, and choosing the proper framework is saving me from lots of unpaid overtime.

I recently tried using a manually put together bleeding edge react framework, finding that some packages where outdated, I also found stuff like logging and exception handling suboptimal.

I myself prefer meteor.js, it is reactive, nice and restricted, only mongodb, but it provides me with well proven modules that integrates well and it turns out a very clean code.

Same with perl. I love Dancer I'm far more productive in Dancer than in Mojolicious or Catalyst, Just too much and poor integration with the JS DOM.

So it all comes to to productivity.

bigfun Permalink
March 15, 2016, 23:31

Author is definitely trolling us all, because no real engineer would do such horrible generalization without any proof.
Frameworks have their advantages and disadvantages, but saying that something is bad in general is a mistake that is a sign of a junior wannabe engineer, which I don't think author is.

Gelatin Permalink
March 16, 2016, 05:09

Well, I read above comment and all of them are opposing you. So are you serious about your article posted here?

Bhagwat Chouhan Permalink
March 17, 2016, 03:17

Ok. This sounds very good at first look. To me frameworks are really useful.

If you hate frameworks, it means you want to make all the mistakes on your own.

It sounds more interesting if someone shows creativity without using any software and just use bare hardware.

Nisanth Permalink
March 17, 2016, 04:11

Love the quote "Frameworks make you dumb", very true.

Davis Brown Permalink
March 17, 2016, 04:43

I use this framework "TemplateToaster". Some time frameworks helps a lot in saving time.

March 18, 2016, 13:04

In reading this, I've heard these arguments before, and they're scary.

How do handle configurations?

You say Frameworks increase dependencies... So how do you use dependency injection in your code to reduce dependencies? Do you just use static functions?

March 18, 2016, 13:15

The author is correct. Framework followers threw in the towel long ago and they feel you should, too. They will attempt to justify frameworks at all costs. They cannot go back, so they must convince you (and themselves) of the superiority of their decision. True knowledge and creative power does not matter to them as much as meeting deadlines and conforming with the herd.

ares Permalink
November 24, 2017, 09:49


Martin Thorpe Permalink
March 18, 2016, 13:30

Thanks for writing this.

It is something I have been saying myself for decades as the use of frameworks rose, basically they are a dependency you tie your project to.
You can't beat knowledge of a language for stability, future proofing and sharing work with other developers.
I agree that libraries can be handy and help to compound complex common tasks.

What they do enable is for people to get on the ladder and learn quickly without knowing how to code, coding for non-coders if you like. So that can be one benefit I guess.
But you need the coders with the language experience to write and maintain the framework in the first place.

March 18, 2016, 15:26

This looks like the short version of Jens Meiert's little book on frameworks. He argues we should focus on tailored, quality code, and that frameworks are to be used with care.

March 18, 2016, 19:21

Agree 100% !
Using a framework is like riding a mountain
bike with training wheels ...
And the Angular.js freaks are like scuba divers in the Alps.
Time will tell.

JSD Permalink
March 19, 2016, 05:55

Full agree with author.
Working with people who are "frameworkers"="spaghetti coders" for me was the worstest experience ever. People who don't understand what they are doing, copy pasting big parts of code from stackoverflow and saying that they are "great developers", but really knowing nothing about coding, performance and even how frameworks are really working, and WHY they was really created - are the worstest developers ever.
Instead of learning "core" language concepts, patterns, technologies, databases and performance (I am not talking about harder things like algorithm and cryptology), they learn jQuery, Yii, angulars and so on... (and learn it for 3-4 days :)) )
P.s. "Frameworks make you dumm" - like for a qoute!

March 19, 2016, 15:52

First of all, as developers the one thing we have to have in mind is delivering. If someone is using a framework to do it or his/her own code, it doesn't matter.
Client's don't care. All they need is a product on time. If it breaks because of someone else's code then it's our fault.

I must say, I don't use frameworks, I tried using one or two but I didn't like how all the things were working.
I am always taking some concepts from one framework to another and add them to my code or other libraries.

What I always have in mind is to abstract frameworks, libraries or plugins or whatever you want to call them, to the point that if I want to change them three days from now I could do it with 'ease'.

One way or another everything depends on yourself, the budget and the time you have to complete a task.


Tobias Permalink
March 21, 2016, 16:04

You are using JQuery on - Why?

Frankiee Permalink
March 22, 2016, 19:28

This was my thought exactly! While I agree with a few points - especially in regard to super opinionated and locked in frameworks like Angular - you also wrote: "You should prefer core-language solutions to small abstractions to small helper libraries to general libraries to frameworks.". And then you have things like "$('#web-subscribe button').click( ...)" all over the place? That kinda contradicts your statements imho. For me using jQuery is equal to not knowing what you really do. And it can do some quite nasty stuff you aren't aware of, plus its simply slow.

And what about writing a framework for yourself? I did that - actually more like a collection of libraries - and I learned a LOT about (modular) core programming and API design. No, the NIH syndrome does not apply since my libs can do stuff no other lib I found can do, and I am still in total control, and it gives me a much better way of structuring my app. If I hadn't this overall scheme / structure my app (about 45k LOC) would be a total mess.

Also, if you do more complex stuff, does it make sense to reinvent everything, for example recode requireJS? So I also use 3rd party libraries when it makes sense. What is really important there that you abstract enough, and use libraries only for defined and specific tasks, i.e. one library does basically one thing.

Ryan Permalink
March 24, 2016, 11:08

What quite nasty stuff can jQuery do that I'm not aware of?

What stuff can your libs do that no other lib can do? Why does it give you a better way of structuring your app?

Frameworks Are For Noobs Permalink
May 19, 2017, 18:49


Jquery is a Library not a framework..!!

mal Permalink
March 24, 2016, 05:33

In a situation where most of the coding is given to contractors, I prefer working with open source frameworks which others are using, rather than undocumented code where the logic isn't obvious and can only be learned via tribal knowledge.

Flo Permalink
March 24, 2016, 07:55

Let's take Java as an example... The famous Spring Framework. Of course, I don't NEED it. I could do everything it does myself. Of course, then my coding would take 10 times as long and my code would be 10 times as long - and much more complex. Of course, I could build my own Bean Factory, no problem there. I could code my own transaction managment AOP system. I could code helper classes to create my REST services. I could do all that - and waste my time by doing so.

Of course Spring only hides the complexity, but it hides it well and let's my actual code be much more concise. I can concentrate on the important logic parts and do not need thousands of lines of boilerplate around it, which makes the code a lot more easily understoof. Spring does not do something that I could not. In fact, I discovered it too late and did many thing myself that could have been done much more easily with Spring. I just don't see the need why I should do it. If I started working as a carpenteter, it might be nice to know how to make my own tools from raw iron and coal, but it will be much more efficient if I didn't have to spend half of my day actually doing that and instead can simply buy good tools.

A good framework is simply a tool.

Penn Permalink
April 13, 2016, 11:08

Your websites look like crap, you should try some framework.

Deepti Permalink
April 29, 2016, 13:36

Yes, i am totally agree with all these points, but still we want framework to develop any software fast. As per my experience we should choose framework and its bundles based on our projects requirements. Framework also help us to inheritance and update new feature anytime..!

Dirkey Permalink
June 22, 2016, 09:28

I'am not totally agree. The common problem with frameworks is to choose them before thinking about the problem to solve. Using "No framework at all" is only possible for very simple applications. For example: If you need to write a customizable workflow in a few months, you don't have the time to solve the customizable part (you need to implement the domain problem). So, choosing a workflow framework is the right choice.

But I agree, most developer (also in bigger project) are choosing there framework to soon and because of bias. This leads into many problems.

Demosthenes Permalink
July 01, 2016, 03:07

Hmmmm... I would agree with everything stated in Peter article except I would change "frameworks make you dumb" to "frameworks make you dumb and lazy".

Frameworks are anti-geek. Being a hardcore geek is about exploration into the science; not merely learning how to use x,y, or z's methods. Some would argue that you can't build structure without a framework - this in itself is true, however if you create something from ground breaking through to completion, you are in absolute control and truly all you need is the blueprints that you define, thus, have a solid 'framework' of your own, and only need to worry about whether your base is solid, and your construction is sound. We don't need to know about constructing ionic pillars, or wainscotting, or any other pre-defined methods because we build them ourselves.

Frameworks and the construction analogy walk hand in hand. There is the software that is built upon them which I would liken to standard, modern housing; they are all based on a similar design with a few embellishments to personalize it. Eventually these neighborhoods of cookie cutter dwellings will lose their appeal and fade to obscurity because it isn't the way things are done anymore. Coding from nothing, however, let's you define absolutely everything, and will lead to software that is more like the Eiffel Tower, the Parthenon, or the Pyramids and will withstand the winds of time. This or that framework will (!!!) change, and perhaps go away altogether; core sciences will not. If you feel that your developments will only last as long as the predefined framework that you are utilizing, then you should perhaps think about expanding your vision, or simply fade into obsucrity of the mundane.

Thanks Peter!

kambo Permalink
December 11, 2016, 14:24

I agree with you and for a long time i considered myself strange and doing something wrong by not using a framework. Now, i know its just the anxiety from not fitting that was bugging me.
Programming is complex enough without the need to learn another
steep opinion of how to do it.
That said, in my coding i find that i have to evenutally write my own frameworks. Though theyre nowhere as complex as those out there. They only occur because they helped in solving the problem at hand.

Lucas Lukaso Permalink
January 15, 2017, 08:36

You're 101.5% Right! You ask for a banana and you get a forest and a monkey holding it.

Joe Permalink
March 09, 2017, 09:19

Normally, I don't write comment, simply I just don't have the time ....

Our company is very tiny with one marketing guy, one support, two sales/directors and two developers: one driver developer for the core engine and me dealing all the GUI sides. Our company is not VC invested but with enough profit to pay the wages. With the minuscule human resource of my company and the recent explosion of Javascript, I would say I am lucky that I took the bold step to use *commercial* framework at the very early stage (since ExtJs 2). We pay for Sencha Architect + ExtJs framework purely for the reason of we need to build applications *quick*. I can keep up with the framework advancement (less scope & manageable) without coping with the insanity of Javascript movement, CSS, HTML, UX, design & look, etc. So I can *afford time* elsewhere, to write python unit tests to improve the product robustness, invest time to explore server side framework (like Php slim). Save me time and get more done, I have helped my company to build more products under my belt.

It's easy for you to justify and yeah, I would love to design & build things in *grand & noble* approach too. As life moves on, some of us just have to build applications that pays the bills, being practical, get things done and beat the deadline, staying competitive, and most importantly I get pay to feed my kids.

If you are working for Google, Apple, Microsoft, or some giant software company with lots of resources. You article is correct. However, the majority of employment is made up of SMEs.

Do you employ a developer so focus for the elegant or the 'cool' way to solve a task, or a developer will just always get it done and deliver within the deadline? This is purely depending on the nature of your business.

Ian Permalink
March 21, 2017, 14:05

I totally agree with this post. For true geeks, frameworks don't usually make sense. They offer layers of abstraction that a coder could implement themselves more seemingly. They overcomplicate projects. Most of them aren't scalable.

In fact, if you want to make the next "BIG" site, you'd probably not want to use a framework, because most are not scalable. Most frameworks are not lightweight. Maybe there is a conspiracy in place to prevent a developer creating the next big app.

For a generic CRUD application, a framework is probably the way to go. ANything more flexible than that, probably not.

Stan Permalink
April 27, 2017, 00:09

I totally agree with your article. I have been anti framework for quite some time and I've used a few of them over the years. For all of my projects I write pure javascript, pure html, pure css with a little skeleton, and pure java rest services on the back end. No code bloat and it runs great everywhere. The only problem I have is most jobs out there look for framework experience /expertise and view me as a heretic

Alp Yogurtcuoglu Permalink
May 17, 2017, 14:13

Thank you for this article.
I also read another article that said " libraries instead of frameworks" and imo that should be the point.

The problem is, these idiocratic useages of "frameworks" helps only HR to classify (how/whatsoever) of job applicants, and not programmers.

Besides, what is "advertised" to as as "industry standart" (actually more like HR's understandability standarts) are sometimes not much of a real work. Any programmer can program jenkins or bamboo given a reasonable amount of time. (Hint: look tomcat execution parameters and use ant)

I always prefer API & libraries over frameworks, no matter how many people are using it or elevating them to "industry standarts".

Simply put, I prefer to be a programmer, not a framework user :)


dolphonebubleine Permalink
June 17, 2017, 00:48

I fought this fight and lost. Using frameworks, to me, is like typing with gloves on. I can still work but man is it a pain in the ass. The concept of loading a webpage with no dependencies has been made inconceivable by "experts". It's like "what were we trying to do here again"? Why are we loading 10,000 KB worth of tools to get this little page to work? But it's blasphemy to even point out such a thing. It's so ironic that NOT wanting to use a framework frames you as slower/less-sophisticated/whatever. Just insert whatever canned argument for using a framework and that's the final buzzword.

Canix Permalink
November 01, 2017, 00:23

I'm always saying, why use some big framework if you can do something yourself with just time and maybe done even better or at least not having to use all the useless stuff in the framework that I wouldn't use anyway...
Stupid example, but bootstrap for example. People saying to me it's good etc. and that I do not understand, that is how must sites are done, the easier way... Like seriously? Of course that's how the sh*t sites are made, done by lazy people with not even a bit of own creativity and skill.
Also a thing, I understand stuff like jQuery, which is a very good library, but frameworks? Come on... I even do not accept Laveral...

IwantToPrivate Permalink
November 23, 2017, 04:05

I understand what you said.

Those who put comment with troll intention, they do not realize how cumbersome coding framework had made to programmers.

Just only look what came and gone wit Java: struts 1, struts 2, j2ee, ejb, Hibernate, spring all versions... Liferay is just another dead portal - though it is not a framework but it is very heavy.

To javascript there is angularjs v1 (v2 is not really die yet), emberjs, backbone js ...

Ruby On Rails, CakePHP is stepping on the same path (not there yet).

Not mentioned to other nonsense creation like CoffeeScript, Haml, sasss.

Those companies who behind them, they do really fool us around because they could pay anyway.

After putting your brain to process those framework, what left to those programmers is void.

Juzer Ali Permalink
December 05, 2017, 16:11

I can surely tell that this website didn't use a UI framework. Did it need to? That is a subjective question, and even a philosophical one if you will. There is no way to prove anything at all. If you know what I mean, look for advice elsewhere.

Juzer Ali Permalink
December 05, 2017, 16:12

Or else, depend on advertisements for paying your bills.

December 21, 2017, 03:01

Finally, someone gets it, thanks for writing this. I find the framework learning curve to be painful with only minimal rewards, and often everything I learned is a heap of waste when the next employer / team insists on a different flavour of framework.

It is frustrating though the number of jobs these days requiring framework xyz or abc instead of just the pure coding language. I find libraries and other tools sufficient for most tasks, and frameworks often increase the development time with learning and eventual maintenance.

I wish more people would share the same perspective as this post.

PS: My current plight is learning Laravel.

Alex Permalink
December 22, 2017, 18:52

Indeed. The hype around frameworks bloatware last years is terrific. We do see more and more projects that just bring servers to a crawl with only a small 'contact me' page.

Point 1. Libraries are good, they can be reused.
Point 2. Most general purpose frameworks are bad because they are in itself:
a) bloatware, loading over 50 files / utilizing over 50 tiny classes for just a 'contact me' page is pure hell;
b) dependency hell, unreliable and hard to track as it is;
c) limiting in all aspects, you're bound by a framework bounds, afraid to step out, some people avoid that by patching frameworks but it's even worse, given the number of dependencies;
d) turn attention from learning language specifics to learning abstraction specifics, resulting in ultimately bad code when it comes to doing something 'by hand' (and core application logic cannot really be abstracted, if it's not at the helloworld level - so here all the issues start for those fixate on frameworks);
e) make projects unportable and unmaintainable, if framework dies or severely upgraded, it's all lost for a long long time.

Alex Permalink
December 22, 2017, 18:53

And another (f) is that debugging a simple logic with frameworks can become hell, because framework code is usually heavily split and obstructed, usually with non-obvious call paths...

Anomynous Permalink
January 08, 2018, 09:13

This is a good writeup for great and successful future programmers. Many people calling themselves programmers can solve little problem like e.g(substracting any two number without using minus operator), yet calling themselves programmer. I think we the creativity programmer should build our own apis, functions and class by ourselves for code reusable. Thanks to the poster

Brian Permalink
January 10, 2018, 20:46

Facebook was created without a front end framework...... that is all.

Brian Permalink
January 10, 2018, 20:47

I am a very qualified javascript expert and all that sh** (Angualar, etc) is completely usless

Lucas Permalink
January 12, 2018, 11:29

I love this article. I'm tired of working on projects that use lots of frameworks and/or design patterns just because they are out there, with no real benefit. Days of work wasted to add something we could have implemented in a couple of hours. Just to have it broken some time in the future in a version change.

Sean M Permalink
March 05, 2018, 17:34

Reading through most of the 2+ years of comments here, I'm struck with how the pro-framework people don't address the points made in the article. Rather, they bring up two basic points: 1) Initial software creation is faster with a framework, and 2) Tested code is better than untested code.

I think everyone would agree. However, that's not the point.

Example: I currently work for a group who started using Ruby on Rails in 2009. It was great. The developers here spun up 38 web applications in about two years. Those applications solved a lot of people's problems. The programmers had to hack ActiveResource and Rails core because back then SOA was one of those weird edgy things that Rails didn't support. But the hacking didn't take much time, and development was very quick. So far, so good.

Fast forward nine years. The development staff has rotated out twice. Rails has moved from version 2 to version 5, shedding its preferred JS framework (Prototype) along with making numerous large changes. Our development staffing levels are set in stone by budgetary constraints, and as those 38 initial apps were joined by eleven more, the time to maintain and support those applications has drowned out our groups ability to keep up with Rails core changes --- not due to negligence, laziness or stupidity, but rather due to the simple element of time.

Yes, frameworks save time up front. Yes, using code reviewed by hundreds of developers and tens of thousands of websites is safer than hand-coded. And then comes the part that is utterly miserable: maintaining it.

You may say: you'd have the same problem with handwritten code.

I answer: no, you wouldn't. Here's why: programmers who know the technologies they're using will create a system that solves the need of their users (and not fourty-thousand other users). They do this with a programming language. While that language will move underneath them at times, their code will not change without their consent. IF (and that's a big if) the programmer knows what they're doing, using targeted libraries where it makes sense, and using what every programmer should have a solid grounding in (security, design patterns, coding for future maintenance), then their code is orders of magnitude less complex, more secure due to lower security target area, and needs very light maintenance.

In short, using a framework is fine for freelancers who can walk away from a finished product, or for corporations who can hire n newly-minted CS grads to keep up with framework updates.

But for those of us who have to live for years with what we create, or have to assume the responsibilities of others who walked away, a framework is a sanity death sentence.

Jared T Permalink
August 21, 2018, 23:28

Would your company be better off if instead of 49 apps to maintain, you had far fewer, built with no framework? Would you have ended up building an internal company framework instead? Would each of the apps create their own app frameworks that had a different flavor, requiring devs who hop from one project to the next to learn the unique framework for each project? How much of a nightmare would that be?

How many fewer projects would you have? 39? 29? 9? Instead of having maintenance headaches, would you be unemployed?

Can you give an example of time consuming / sanity stealing maintenance headaches?

The author also mentioned that needlessly upgrading something that already works is another anti-pattern -- what if you used old Ruby on Rails and didn't upgrade? Or forked open source to apply what few security/browser compatibility things came up that you may have needed to do on your own in-house project?

Basically, I see a lot of people in agony over hard to maintain frameworks, but I am not convinced that the alternative is better, or even what the alternative is. Can someone point to a list of open source projects that don't use frameworks and are successful?

Anyway, I'm convinced that you and the article author stumbled into some sort of maintenance hell -- okay, bad luck dudes, but I am not in the slightest convinced that framework avoidance is a virtue, moreso than avoidance of adopting any sort of risky thing (dependencies, webs of complexity) that are beyond one's control. Avoid bad frameworks, avoid taking on unnecessary complexity -- sure, but if frameworks can reduce complexity and are not bad (like I think Angular 1 was*, though I give it credit for being a thought experiment), then this doesn't have to do with frameworks -- it has to do with bad dependencies and bad architecture.

(* I thought Angular 1 was ridiculous, with its huge learning curve with boilerplate scattered everywhere, and love Vue's learning curve by comparison, though am still concerned how maintainable the npm and build and transpiling ecosystem will be over the next few years. (Aurelia may be a lower-risk and unobtrustive and long-term maintainable option) Though I think Vuex is ridiculous and half done, without vuex-pathify and even then still a mess -- but at least it is promoting healthy state management.) Also, maybe this discussion is web-centric? I'm relatively new to the web landscape and it is so convoluted it is easily shown to be hilarious by the tech comedians out there. I don't really know the bias here on web versus other: How many "frameworks" end up becoming universally used libraries, or core platform or operating system or cloud platform features that are used by everybody on that platform? If people avoided publishing frameworks, because "we have to avoid frameworks at all costs!", how many of those wouldn't exist?

Define framework. (Do frameworks own the application lifecycle, for example? Do they have black boxes of application logic flow?) Maybe a clearer definition would get at the real issues.

iain Permalink
April 13, 2018, 21:58

Ever worked on large projects? Having methods of encouraging certain ways of doing things (frameworks for example) helps reduce complexity. Its a trade-off, like all design decisions.

I'm not sure where all this hate comes from for frameworks. I could write everything in binary, its just impractical to the point of being impossible. Does this make me a lesser developer?

Think ill continue using the best tools for the job, thanks.

Leandro Permalink
August 07, 2018, 13:55

Frameworks and CMS are only good for one thing: some sort of guarantee/security for non-technical personnel.

Clients dread losing their developer. But if they made the project on X system, it's easy to replace the developer, just get another X developer and you're set.

On one side i can't blame them, there's a lot of idiots devs around. But then they spend 10x times the money trying to make their horrible generic website perform and stand out.

Most projects which are based on generic frameworks are startups led by non-technical personnel, or budget projects with no "5-year plan". This is a fact.

Jared T Permalink
August 22, 2018, 00:05

If the anti-framework people win, and nobody used them, or it was more on the rare side of things, can someone explain to me what the world would look like?

Instead of Ruby on Rails, we'd have a ton of applications built on Ruby on Nope?

Instead of ASP.NET MVC, we'd have "Just get me a .NET socket and I'll make my own custom ASP.NET Core MVC that's better than what Microsoft created, because I am a 'real programmer' who doesn't need a framework"? "This way, I won't have to upgrade MVC 3 to 4 to 5! Ha!" (Note: I do agree with article author on avoiding unnecessary upgrades.) "SignalR for real time client-server communication with multiple communication techniques and built-in fallbacks for older browsers? Screw you Microsoft, I can roll my own and do a better job, and I can replicate the tens of thousands of hours you put into this, make better quality documentation for my successive maintainers AND still come out as more productive in the long run." (I hope you can see how lost I am by this article's generalization. If you're going to tell me ASP.NET and/or SignalR are libraries, (or platforms,) not frameworks, tell me specifically what a framework is (bullet points) that makes it such a bad idea, and we can debate those bullet points rather than these vague terms.)

Instead of WordPress and Woocommerce and membership plugins, people would start blogs by doing 'vi index.html', and hire a 'real programmer' to get them a bug-free battle tested shopping cart and content delivery system? But since we are all pro library, can you cobble together a equivalent to a feature-rich ecommerce and membership Wordpress site with commenting using only libraries? Which libraries? Give examples (for WordPress or otherwise). Javascript's ecosystem has gone to the extreme of using libraries for tiny utility functions but that seems to have created its own brand of hell.

Would 'people who don't really know how to program' be out of jobs, leaving way more work for the 'real programmers'? Would there be too few real programmers in the world?

So which is it? 1) Avoid frameworks, roll your own, 2) DRY, use libraries as much as possible, 3) Adopt batteries-included frameworks. 4) Some sort of level-headed 'best tools for the job' objective reasoning on a project by project basis that is a balance of 1-3? (I like #4.) I think the answer is to not generalize, not flip out due to some bad experiences with some poorly maintained overly complex frameworks. If the industry leans to a bias of overuse of one style, then sure, point it out, but in favor of objectivity, not reactivity.

(Now, I like think the world could have done better than WordPress, (which is a CMS first, a plugin SDK second, and only very distantly an application development framework if you really want to stretch it to be one, and also a programming environment I basically avoid at all costs), if we designed better families of libraries that provided framework-like features without being monolithic. But I can't prove that. We do have inverted (though closed source) things like Gravatar for avatars and Disqus for comments and I would have liked to see things like WordPress grow in more of an dependency fashion like that, but in this and other landscapes, it may require some more standardization.)

This is a broad topic so surely I'm missing your perspective -- fill in your own examples of 'the world would be a better place if X Y and Z products used no framework instead of ___ framework', from any domain of software development.

Convince me using a story or many stories that your project was more successful because it didn't use a framework. Browserling is (allegedly) one example -- okay, I'm not sure how typical of a project that is, but if there's something to this article and train of thought, there should be hundreds and thousands of examples.

AeroNav Permalink
September 10, 2018, 18:05

exactly, whats the point i am trying to make in my comment below

AeroNav Permalink
September 10, 2018, 18:03

This is great article, i often say this but people generally turn their back on my words thinking that i might be a conspiracy theorist or something. I always say, these framework are not only making our brains idle and stop thinking about the important things, but they keep updating and changing on annual basis, and by the time I learned them the companies start to need time to learn a new one just so they stay ahead.
If programmers and engineers want any dignity left in their profession and to secure this profession without lowering the bar they must speak up about this, I have refused 2 times to learn angular and now they asked me for the 3rd time to learned it, I can do everything perfectly fine with jQuery but it is not good enough for them, I have done my part, I have been saying this to other programmers and by doing so risking my job which I can ill afford to lose now, but still I try, however my effort is worthless if others turn their back and continue to be everyday's sheep and don't bother to actually do something about it.
Assess the situation when you are asked to learn or being a new framework to the organization, assess the situation and ask yourself, is this necessary for the job?, does it worth my time to take my mind off important tasks that requires actual thinking, human thinking and innovation and instead learn a new framework which is likely to be replaced in a couple years?
If not, you will lose the dignity of the job, because guess what, this job's dignity comes from the fact that we are thinkers and solvers, take this away and you're nothing but a copy-paste sheep.
Thank you.

AeroNav Permalink
September 10, 2018, 18:30

I think it's about time programmers make a stand against the continuous employer demands to learn and bring in new frameworks to organizations, before the whole profession of programming is stepped over. Programmers mind are becoming idle, no innovation just learn new frameworks for productivity of the big corporation

Al3 Permalink
October 22, 2018, 00:25

Disclaimer - I do not write to agree, disagree with the author or the aforementioned comments nor I enforce my opinion towards the others. This is solely a comment.

First I would like to refer to you, who say "Author uses frameworks himself" - He never said his work is by any means perfect, but he evidently tries to minimize the use of frameworks.

Allow me to remind that the Author is a guy with many, many years of experience in a number of fields and most of anything - he launched and developed a succeeding business after many published projects. This does not mean he is right, but it surely must be taken into consideration before you say things like "You obviously have no experience".

Last fact - Anti-pattern does NOT mean:
1. Your projects sucks
2. Your frameworks sucks
3. You suck
4. Your entire life and family suck
Because I see that a lot of you act as if it does mean that.

Now let's get into the "opinion" part.
Under my observation, frameworks are very much appreciated from less-experienced users for obvious reasons.
Frameworks are very appreciated from lazy users for the same obvious reasons.
When it comes to deciding whether to use a framework in a corporative environment - things are a bit different. :)
Then, by the nature of the "Framework" per se you should stop and ask yourself - "Is it absolutely necessary" ?
Think a little - Do you like to be dependent? I can not think of any good real life situation where I would like to be dependent.
In the slightest, this is one reason not to use a framework.

Now I don't think the author "hates" frameworks, but in his professional experience, he found out that Frameworks are a little help, but a bigger burden, for him, his employees and the front-end users. I never liked how he presented his truth though and I, encourage you to use what you trust is the better option.
Have a nice days, colleagues.

Jonathan Permalink
October 25, 2018, 08:35

Sir, you left me speechless in the sense that I can't agree or disagree with you after your comment.
It is just the kind of truth and elaboration you can not deny.
You have to make blogs.

December 28, 2018, 17:44

This article was so refreshing to read. Simplicity is key; frameworks are usually unnecessary complexity.

Leave a new comment

(why do I need your e-mail?)

(Your twitter handle, if you have one.)

Type the word "server_508": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.