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!

Comments

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 http://www.workingsoftware.com.au/page/Kill_your_index.php.html

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.

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.

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 (https://github.com/zurb/foundation-sites/issues/8324), it is easy to understand how the author came to the conclusion. I'm living it as we speak. Zurb Foundation 6.x (http://foundation.zurb.com/) 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.

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.

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?

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? https://twitter.com/mcbazon/status/401019899901792256) 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.

END OF RANT.

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.

Disgusting.

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

Agree!

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).

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 years...you 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

March 11, 2016, 19:04

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

I normally agree with you Peteris, 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 Peteris' 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.

https://www.youtube.com/watch?v=QHnLmvDxGTY

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.

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 Peteris 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.

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.

Cheers!

Tobias Permalink
March 21, 2016, 16:04

You are using JQuery on www.browserling.com - 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?

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 Peteris 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 Peteris!

Leave a new comment

(why do I need your e-mail?)

(Your twitter name, if you have one. (I'm @pkrumins, btw.))

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

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

Advertisements