Why You Shouldn't Use A Web Framework

gypsydave5 profile image David Wickes Updated on ・4 min read

What framework are you using? Are you using Bootstrap, or Materialize, or Foundation? Or Vue, or Angular 1, or Angular 2, or Ember? Or Ruby on Rails, or Sinatra, or Express, or Meteor, or Flask, or Korbin, or Hapi, or Spring, or...

Frameworks are all terrible. All of them. I'm serious - they are making you all into bad developers. Stop using them now.

Let's talk about this, as I may have lost most of you with that opening. Why do people like you like frameworks? Are you weak or are you stupid? Or both?

A framework means I don't need to reinvent the wheel

Sure, I'm building a bike. I don't need to reinvent the wheel, I'll just grab a framework with a wheel.

And a steering wheel

And a bonnet. In blue.

And an engine.

And a CD player

What, you don't have any CDs? Fine, just don't use it. Or just use the CD player to MP3 player adapter.

For your bike.

Which you're still building. But now on top of a car.

But it's fine, because AutocarJS has a modular plugin system to allow you to add bicycle pedals to your car-bike abomination. It's easy. Just type 'autocar scaffold add pedals'. Or edit the autocar.js.manifest.nightmare file.

This is much easier, eh?

"You don't need to reinvent the wheel" is fine under two conditions:

  • you know how a wheel works
  • you know how this wheel works
  • this wheel doesn't come with a whole bunch of crap you'll never use
  • you only want a wheel

It's easier for beginners to use a framework

Sure, if you're a Sith.

What? Yeah, a Sith Lord in a weird black bunker. You went for the fast path to ULTIMATE POWER, but you still don't really know how HTTP works. Or what a POST request looks like. Or how to write a form element. Or how to use a database without some freaky ActiveRecord nightmare layered on top...

And it's addictive, Because you don't know how anything works you'll spend your career chasing the NewShinyFrameworkJS because ShinyFrameWorkJS didn't quite do what you needed. You will suffer from eternal imposter syndrome because you don't know how anything works. You will get your job done, you will be a 'React Developer' or an 'Rails Developer' and you will wonder what went wrong.

True story. When someone interviewed for a position at a well known coding bootcamp they were asked to do the FizzBuzz kata in Ruby. First thing they typed at the command line?

gem install rails

You're Anakin Skywalker and all you've got to look forward to is a life where you have no idea how anything works and your career and livelihood is built on the sand of your ignorance. No, you're not Darth Vader. You're not that cool. You're Anakin and you suck.

Angry Vader is Angry

But it's really hard without a framework

Is it? Is it really? Have you tried to write something without using a framework? I mean, can you write a beautiful, complicated, client-facing website without a framework? Say something like GitHub...

Github has no framework nao


The web is a much better place than it was ten years ago - hell, ten months ago. You don't need a framework - you just need to spend a few minutes reading the docs on MDN. You don't need Sass, CSS has variables now. You don't need Bootstrap, flexbox or grid are your friends.

What about that server stuff? How does that even work unless I'm using
a framework?

Are you kidding? Have you seen how simple HTTP is?

Easy HTTPeasy

Look, an HTTP request:

GET /hello-world?framework=none HTTP/1.1
Accept: text/html
Host: my-hello-world-server.com

Does this seem too hard to parse? Really? You can read it like it's words almost. It's just a big old string. You should be able to extract out the which content type you want to accept, the method, and the query string parameters for this with any language you choose. If it's this easy, why are you relying on a bloated, opinionated framework to do all the work for you?

I'm not saying you should write your own abstraction over HTTP - almost every modern programming language has an abstraction built in that will do the heavy lifting for you. And if it's not built in then it's a readily available library. Go use one of them - an easier way of interpreting requests and responses over a socket. Which is really all you need.

'Abstraction over HTTP' is the key idea here. That's the bit that needs abstracting away from a stream of bytes over a socket into something sane. A framework is an abstraction over... a whole mess of things. It's usually an abstraction over somebody else's idea of what a website or a program ought to be. It's not your idea, it's not your product - it's theirs and it's limiting your creativity.

Learn the basics, not someone's abstraction

Stack Overflow is full of questions like "how do I do X in framework Y" with answers that range from "why do you want to do X?", "No, you can't", or "you can't do X, but why not do Z?".

It's because the poor dev asking was used to using a framework where the database was attached to the request object or whatever, and now they're using NewShinyFramework with a completely different abstraction. They leaned the wrong thing.

If you want a solid start to a career, don't learn a framework and a framework's abstraction; learn the fundamentals.

Don't learn Express's routing system; learn how HTTP works.

Don't get familiar with ActiveRecord hacks to make your queries faster, learn to write SQL.

Don't learn how to build React with Redux with Bootstrap with JQuery, learn HTML, CSS and JavaScript.

For 99% of what you need to do, they will be more than enough.

This knowledge will never get stale.

Unlike frameworks.


I wrote a continuation and response to this post:

Posted on by:

gypsydave5 profile

David Wickes


British. Strong opinions held weekly. No, that's not a typo. Teaches when and where and what I can.


Editor guide

I completely agree. I ditched frameworks 5 years ago and started writing everything from scratch. My OS isn't as secure as it could be and the TCP stack isn't fast but the HTTP parser took fewer months than I'd expected.

5 years later, I'm nearly finished with the login page and my client is furious. Hire me?


I think you are missing the point.

What I understood is that the author is not saying you should never use any framework ever. (the title is somewhat purposefully misleading I guess).

What I think he meant is:

1/ sometimes you don't need a framework
2/ you should learn how things work "under the hood" before considering using any framework, because frameworks change all the time but the underlying tech does not.

This is true for more contexts than web development by the way.


Thumbs up to this @Dimitri - this is pretty much what I mean. Sure, use a framework when you need to or want to. But if that's your beginning and end to your understanding of development, then you're setting yourself up for a bad time.

If you're not trying to do it without a framework, then you really aren't doing the simplest thing possible. How the hell do you iterate away from a monster like Rails?

Sorry but your title is completely misleading.

You're claiming that what you actually meant to say was that it's ok to use frameworks as long as you know what's going on behind the scenes?

So it's actually OK for me to use frameworks then? What about the people on my team who aren't as experienced? Do we only use tools that the lowest common denominator understands?

Should I write MVC from scratch for every project/client? Or should I create a set of re-usable modules and store them in a repository? But now I've simply written my own framework. Is it OK to use that but not someone else's framework?

When you use phrases like "all frameworks are terrible" you're framing your argument in an irrational way. I agree with the latter part where you encourage beginners to learn the fundamentals. This is good advice. Call your article 'learn the basics before adopting a framework' or something.

Hand-waving that "all frameworks are shit and should be avoided by everyone at all costs" is unproductive and not likely to convince anyone.

MVC is basically just separation concerns and does not mean you need a framework

Should I write MVC from scratch for every project/client? Or should I create a set of re-usable modules and store them in a repository? But now I've simply written my own framework. Is it OK to use that but not someone else's framework?

Try not making a "framework" but just well decoupled, testable code. You can get very very far with just that.

What about the people on my team who aren't as experienced? Do we only use tools that the lowest common denominator understands?

I think it's more dangerous to only use tools that only your best and brightest understand on a good day.

Should I write MVC from scratch for every project/client?

Should you use MVC for every project/client? Is it always the right fit?

You're missing my point. MVC was just one example. Also you created a false dichotomy: picking tools that only the best and brightest understand is not what I'm arguing for.

Should we as a team avoid using React simply because someone on the team isn't a JavaScript expert yet? Or is it better to just roll our own view rendering library?

The argument has no logic to it. Yes I agree that throwing some monolith framework at every problem you encounter is not a good idea, but that's a far cry from "don't waste your time with express, just do your own http!"

As Graham Lyons pointed out you might as well be advocating that we simply write everything in machine code.


I don't think I misunderstood - this guy is a fanatic. He truly believes the One True Way to program is to send a voltage into the motherboard. Or not.

No. The one presenting himself as a fanatic is you. Sorry.

It's true. It's very possible that I'll rush the stage at the next ReactConf screaming "free the monads!" or somesuch.


That's not what he said at all, though. He said they are all terrible and suggested that we are stupid and weak for using them.


Thanx, dat's insightful


What's worse:

  • Reinventing the wheel slowly and missing deadlines

  • Or endlessly changing the wheels of your car with different shinier, slightly flawed wheels trapped in programming purgatory forever?


That's a false dichotomy. How about knowing your craft and using the right tools for the job? That's what this article is saying in a roundabout way.

I could write my own version of redux to learn the inner workings of it. I'm not gonna. I'm going to learn the pattern that Redux is based on and use the library that is well supported and tested by thousands of other projects using it. Will I mess it up? Sure, will I learn? Yep. Will I jump to Mobx right away? No, cause I've been doing this for over a decade and I've learned the grass isn't always greener.


The first one. What's the point of developing if you never deliver?


Both sound pretty rubbish.

But someone paying my wages overheard the word 'deadline' so they're pushing for the other option


What's worse, buying high quality tires from the local tire store, or rebuilding modern industry from the stone age all the way back up to manufacturing tires yourself that aren't any better or are possibly worse in your back yard?


I think I say you shouldn't write your own HTTP abstraction, but it's such fun that I'm glad you did.

But, for reals, did anyone save any time and effort writing something in React?


Not in React, but i did save a lot of development time, cost, and effort writing something in Vue framework

This x10. I know vanilla JS, but Vue just kills it in performance, is super lightweight, and easy to learn. Yes, I know these are cliche words when it comes to frameworks, but with VueJS it's actually true.

Sure, knowing vanilla JS is helpful, but not using a framework is akin to using Notepad to code everything because hey, who needs syntax highlighting or code completion to make them more efficient?!

Tangential point, but I did hear of a few developers who use an editor without syntax highlighting. Can't remember why. Think Rob Pike might do it as he uses Plan 9 to write his Go. Might be worth a Google.

My take on stuff like Vue and React... they're great for SPAs. But I think SPAs are a bloated waste of time. Too many teams turn any problem into building a SPA without really considering whether there are enough benefits. Maybe what you're building might turn into a SPA. But starting with one seems like a bad idea to me.

Well, i think starting with SPA is not so bad if the team members really understand why they need to build a SPA.
But i do agree that having the "Let's just build a SPA because it's hot/cool right now" mentality often cause unnecessary problems.

I like completely opinionated view of making no point at all ...

There are teams who know their requirements and know very well what they are doing.

But you guys seem to just talk about websites, not applications.


I think that your article is cool to read but totally out of the reality. People does not build SPA "because is cool".

Throwing a front-end guy in a back-end project (framework or not) is complex and dangerous. Should the front-end guy take a course to learn all the damn basics of back-end development? I don't think so.

Frameworks are evil? No. Developers should look at the source and get how things works? Sure.

Said so, once you get the basics you SHOULD use a framework. A common web app is made of a lot of things (Authentication, Routing, Database, FileSystem) and you can not be good at everything.

You can even create your framework, but i'm pretty sure you will end up looking at the actual one to see how they solved this and that :)


You're saying I'm close?


Does an OS and a 'TCP stack' really count as a web framework? I think it's pretty clear what this article is going for. It's not totally unreasonable to write a website without using a web framework


It absolutely counts. I also braided my own Ethernet cables, but that was more just to illustrate my point.

I think Dave makes some great points in his deliberately inflammatory article and I confess that I haven't really rolled my own OS, TCP stack and HTTP parser and have manage to remain in gainful employment.

I don't agree with the title but then neither does the rest of this article. It is absolutely not unreasonable to write a website without using a web framework. However, to build a production application of any kind of complexity without using some kind pre-existing framework would be incredibly foolish and perhaps naive.

dude... Your all over these posts. You need to chill out. You are missing the forest for the trees simply because you are offended at a title. The author's overall point is simply that when you jump from one complicated framework/library to the next WHILE NEVER LEARNING THE BASICS you are simply hurting yourself as a developer. And he is right. If you never learn the basics very well then spaghetti coding a framework together is all you'll ever do. But if you do learn the basics then it becomes easier as you'll better understand what the third party layer of abstractions is doing in the first place. This article was not intended for developers that have a very solid foundational understanding of the basics AND are able to understand what these frameworks are doing. Why on earth do you find his title to be "deliberately inflammatory" simply because you would have worded it differently?

Hi Chad,

I'm chill, I'm chill.

I'm not offended by the title but I'm confident that Dave meant it to be controversial. And as I say, the main point of the article - which you've certainly got - doesn't agree with the title. Dave's not saying that you should never use a framework (even though he explicitly states that in the first few sentences - he's nothing if not a firebrand!) he's saying you should learn and understand what your framework does, and be discerning about what you choose when you start a project.

I agree with Dave.


Florian, this isn't a constructive comment and it comes across as very rude. Could you find a way to rephrase it to be more helpful? What could Dave do better?

Florian, we've removed your comment because it does not follow our Code of Conduct. If you'd like to leave criticism, please be respectful and ensure that your comment is constructive.


You have been surrounded dude. But to me this kind of article is made to get comments, likes and shares :)

There is nothing new in "learn the basics" but then you should not stop to HTTP protocol, you have to go all the way back to Assembly. How many of the commenter did that?

People tend to talk a lot, but i'm hell sure they are using tons of frameworks every day, without even check the source-code.


That's what you call a strawman argument.

If you're unable to finish the login page with just javascript in a reasonable time (4-8 hours) - then I'm sorry, you're not a web developer at all and I wouldn't hire you for web development job in a million years.


I'll clear my desk...


I don't really agree. I agree that people should know the basics sooner or later but I don't agree with everything else.

Your post, I might be wrong, has an undertone of "look at me how amazing I am because I write compilers in Brainfuck" and it's one of those elitists traits that are damaging in the industry in the long term because even if you don't mean that either generate anxiety to new learners or make us look we're some sort of gods on the mountain top.

You don't need to know everything about everything to be a good developer.

We developers think we are special but for many people it's just a job and that's perfectly fine. I do not think of my CPU cache or about the speed of light everytime I do something on my computer. We build abstractions because they improve our lives.

Should we dig deeper at some point? Sure. Should we know how to write a http streaming parser? Unless that's your business, who cares. Image processing is the perfect example. Should you know the difference between lossless and lossy? Sure. But that's mostly it. Just check the result works for you.

We wouldn't have most software if we started from scratch all the time.

I think your post is a little misleading, especially for newbies who just want to learn a trade.


Your post, I might be wrong, has an undertone of "look at me how amazing I am because I write compilers in Brainfuck" and it's one of those elitists traits that are damaging in the industry in the long term because even if you don't mean that either generate anxiety to new learners or make us look we're some sort of gods on the mountain top.

Oh believe me, I'm no god on a mountain. I just want to give a good kicking to the golden calf of the web framework. Not because I'm clever (I'm really not), or have mountains of computer science degrees or such. I'm genuinely annoyed that developers think that frameworks inevitable in their work, because I think they're more trouble than they're worth both in terms of using them and in term of the ignorance they promulgate.

And that's juniors and seniors both.

As to other abstractions - they're not my target. But I think that a web dev should be able to do what they need to do with HTML, CSS, JS and a server language of their choice. I think it empowers all devs to get more done.


This is how I took it, more of an empowering "You can do this" rather then condemning to people who use frameworks (myself included)

I'm glad you said this - it's what I was trying to get across (badly).

If that's the point you're making I'm fully behind it :)

I just try to put myself in the shoes of a beginner and understand how they will read a post like this. "You don't need a framework, anyone can make a great site without one" is a very different tone from "Frameworks are terrible and they make you a bad developer".

Imagine how you'd feel as a beginner if you struggled with something and someone experience told you that you were bad for choosing a certain tool?


I'm sure non brilliant developers exist, as I said it can be just a job, not everyone is in it to be a published author or recognized guru.

I also agree you should know the basics but I don't agree on the general assumption that ditching frameworks make you more productive. Ditching the wrong ones does so maybe we should teach juniors how to evaluate them.

For example: can you write a SPA without a framework? Sure. Should you? Please don't. Should you know how to evaluate the available frameworks despite the hype? Definitely.

Keep in mind that most frameworks are born in the same way: one or multiple devs tired of the options create a bunch of abstractions on basic code to be MORE productive.

You can spend a lot of time chasing quirks, I agree with that but choosing the wrong abstraction doesn't mean all abstractions are a bad idea.

I'm sure non brilliant developers exist, as I said it can be just a job, not everyone is in it to be a published author or recognized guru.

They sure do. I should know - I'm one of them. I don't like frameworks because my little brain finds there's too much to take in. However, I can speak 2 foreign languages so there must be something between my ears. It's the way I'm forced to think like a machine that I object to.

As for SPA, there's absolutely no reason why a framework is good. Wikipedia says "A single-page application (SPA) is a web application or web site that interacts with the user by dynamically rewriting the current page rather than loading entire new pages from a server".

You don't have to restart your browser every time you want a new page, so why should a web app be any different?

OK, so let's load parts of pages as they're needed. Good old AJAX. Load On Demand is so simple compared to building everything into a huge framework; even if you preload the entire thing all it really needs is a map where you can call items by name. Code as well as content, of course, so it works even better if code is supplied as high-level text that can be compiled on the fly. There's absolutely no limit to the size of website that can be handled in this way.

As for SPA, there's absolutely no reason why a framework is good.

But those reasons exist, there's evidence that frameworks can be helpful to build SPAs. We could argue about which is the best way to do it until the end of time but saying "framework = wrong always" is wrong in my opinion, because we can both easily find people who benefit from them. Maybe even just to build MVPs, who knows.

What we should ask ourselves is the cost of these frameworks and that has been debated a lot in this and other threads.

Sometimes it's worth it, sometimes it's not, sometimes unfortunately the worth or lack thereof will manifest itself later on. Sometimes it's even impossible to know. If someone builds a successful company or product and they do it with a framework and they manage to have mantainable code forever, should we care? If the company or product fails, is it because they chose framework X or because they were unlucky with time to market?

OK, so let's load parts of pages as they're needed. Good old AJAX. Load On Demand is so simple compared to building everything into a huge framework

A SPA is not just AJAX by the way: it's routing, browser history, app state, dom manipulation, probably SEO and maybe websockets if needed.

Can this all be solved by using libraries? Sure. But it's perfectly understandable why people end up standardizing around frameworks or popular libraries instead of doing it from scratch everytime.

There's absolutely no limit to the size of website that can be handled in this way.

Sure, but a lot of frameworks that are trendy now exists exactly because big companies had to find a way to standardize source code around huge code bases :D

It's always a question of worth vs cost.

Do I believe frameworks are always worth the cost? Absolutely not but I think this should be the argument, not "frameworks are bad and that's it" :)

We should educate people to make their own choices, telling them "bad framework, bad" is as damaging as picking up whatever framework is popular now and using it just because other people say it's cool without knowing the possible costs


I'm sure non brilliant developers exist,

this was definitely a poor choice of words to explain a concept, it was bad on my part, I apologize

No need apologise; I for one know my own limitations. That's one of the reasons I avoid complexity wherever possible, and to me frameworks heap complexity onto what is already a complex 'language'. I use the quotes deliberately as in my view JavaScript, Python and the rest aren't really languages at all; it's only the lack of a suitable name that causes us to reach for a term that is actually very misleading.

A true 'language' in the traditional sense of the word would have no need for either frameworks or even libraries in the sense we usually mean. The language would be sufficient in itself, just as English is to those who conduct business, law and a thousand other activities in it daily. Each of these domains has its own agreed meanings and 'extensions' that do the job of a library or a framework.

I've had a Damascene conversion. Inspired by HyperTalk from the 1980s I wrote a compiler for a source language comprising simple English sentences, and with this I'm able to take on any job I'm asked to perform. The details of things like browser history, DOM and the rest are encapsulated in extra vocabulary which domain experts instantly recognize as their own language. OK, there might be some cases that would cause problems but I can only speak for the ones I know.

My conviction is we're in a phase that will soon end, stuck in an endless loop furiously inventing and re-inventing frameworks when there's a black swan event coming; a whole new paradigm that will sweep them all away. I'm not smart enough to invent it but there are others out there who will.

That's one of the reasons I avoid complexity wherever possible, and to me frameworks heap complexity onto what is already a complex 'language'.

I agree on that, but basically everything adds complexity. What I don't like it's complexity for its own sake. Not everything can be simple, complicated things are fine, it's just that a lot of this complexity we're debating is a byproduct that shouldn't exist and I wonder if it's because we're marketing tools as a "one for all" when in theory they should be tools only for certain situations

A true 'language' in the traditional sense of the word would have no need for either frameworks or even libraries in the sense we usually mean. The language would be sufficient in itself

You should take a look at what the designers of Dark are trying to accomplish: What is Dark? and How Dark deploys code in 50ms - they are trying to work around this whole complexity thing that's slowly killing us :D

My conviction is we're in a phase that will soon end, stuck in an endless loop furiously inventing and re-inventing frameworks when there's a black swan event coming; a whole new paradigm that will sweep them all away. I'm not smart enough to invent it but there are others out there who will.

I agree in general. It's funny because most server side languages have been more or less stable for decades, it's not like frameworks don't exist, they live longer. The frenzy is mostly on the frontend side right now


I get your point and I mostly agree with it, but you've tagged this with #beginners and so I think it's wise not to speak in such definitive and harsh terms.

One of the most important things to stimulate the learning process and to keep people wanting to push forward is seeing results of what they do. It's why Hello World is the first thing we show usually with no other explanations than how to compile/run it.

So let's say we have a beginner wanting to learn webdev and they have an idea about the thing they want to make. Can they make it in vanilla html/css/js? Of course they can. If they know those languages inside and out. Which they don't. Because they're beginners.

So what if they take a simple framework and get their new thing out there? Does the world end? I'm all for people understanding the stack and not being trapped by a lib/framework's way of doing things, but there's a way to express that point without making beginners feel stupid for not being able to do without one for now.

Why is there always such a rush for a beginner to create a fully fledged website quickly?

Why is this always seen as so important? It seems to be the case because most bootcamps seem to start you off with rails or an equivalent.

Beginners dont have to rush in to make an amazing fully-fledged website. They should have the maturuity to realise that maybe it takes time to learn software development and running a few rails commands is not actually learning.

I can't argue with that but again it seems to me that the issue is not Rails, is the industry that's trying to churn devs that are not fully formed or teach them they just need to read a tutorial.

Maybe that's what we should rant against 😛


I think that's maybe the tone missing from OP but certainly what i get from it is that new developers would be better served learning the basics and making "simple" websites at first, rather than diving into a framework where the knowledge you learn is far less portable and sometimes quite harmful.

"Maybe that's what we should rant against."

That hits a nerve with me, because I think that's what happened to me. I raised my hand at work one day and said I'd like to help design and develop a new SPA, having only done one static site before. There was no one else I could learn from, so I went to a framework because they wanted the project (of unknown complexity) done in a certain amount of time. I needed a shortcut. Now, being that I didn't know JS, build systems, etc etc either, it was hard at times when I was stuck to know whether I needed to search SO or the framework docs, but the benefit as a new developer was the conventions and organization that the framework brought. Since that time 5 years ago, I've learned a LOT more about JS, and frameworks are somewhat easier to use. I think they are valuable when you have SPAs to build and low-maturity devs. And my opinion is that if you have a project of any complexity, and more than one developer, you will create your own conventions and your own system and unless everyone really knows what they're doing, it will be a Frankenstein framework anyway, so why not use a a framework like Angular, React, or Vue that already has established conventions and decent documentation, and then senior devs can help juniors identify where vanilla JS is the better option.

"So let's say we have a beginner wanting to learn webdev and they have an idea about the thing they want to make. Can they make it in vanilla html/css/js? Of course they can. If they know those languages inside and out. Which they don't. Because they're beginners."

That's kinda the point though. If you don't understand the basics enough to use the holy trifecta to make something. YOU NEED TO LEARN THEM!!! Why? Becasue all those frameworks and libraries use them. And adding another layer of abstraction on top of something you don't understand well is very difficult. I graduated from a coding bootcamp and knew React pretty darn well by the time I graduated. And now I work for a company building stuff in Angular 2+ all day every day. I find the thing that helps me grow the most as a dev is building complicated things with nothing but the basics. Learning to do that helps so much in equiping you to jump from framework to framework.


I share @NotARealDeveloper's sentiment - empowerment.

I'm actually going to look into the CSS variable thing - didn't know it existed... sass is what I know and like.

I will be a "master" when:

  1. I can assess if a framework is needed based on project complexity.

  2. I can tailor the frameworks - because I have better than decent knowledge of the underworking a and am comfortable to do so

This article is a nice reminder to deeply learn what's going on beyond the "yes it works" stage.


Your post, I might be wrong, has an undertone of "look at me how amazing I am because I write compilers in Brainfuck"

Disclaimer: I work with David.

A point he possibly didn't illustrate very well is that you dont need frameworks for most websites you'd ever build.

It's not showing off, it's trying to point developers in a direction where by just using the basics they can still make websites and in the long run the knowledge they learn will still be useful.

It's easier to avoid the temptation of frameworks and you certainly dont need to learn "low level" stuff. When making websites, if you learn the basics of HTTP, CSS, HTML and Javascript you will get extremely far. That's not low-level, its just without all the noise of frameworks.


Most websites though are basic CRUD, exactly what server side frameworks are made for. You still need to know the basics of Http, you still need to know CSS and HTML. I don't agree with your point because it looks like a blanket spread too wide to be actually relatable. Frameworks exist to save people and companies time, they are definitely not perfect but the article is a little too generic and bitter against them for me to actually relate, even if I can see frameworks pain points.

Are we talking about the issues of using ORMs? Let's talk about that. Are we talking about templating languages? Are they so much of a pain to deserve this post? I don't think so. Are we talking about MVC? As you said most websites are basic so MVC is not a big deal for them.

My feeling is that the rant started from a dislike of the proliferation and explosion of JavaScript frameworks and it took off from there eheh.

Again, learning the fundamentals is important but you can do that whilst using a framework nonetheless.

Ok so now he was just exaggerating when he said that nobody should use web frameworks?

EDIT: I don't have a problem with humor and hyperbole. The problem here is that the author sends inconsistent messages as to who should use frameworks and why.


Frameworks are all terrible. All of them. I'm serious - they are making you all into bad developers. Stop using them now.

READ: Frameworks are terrible and should be avoided. (no jokes)

"You don't need to reinvent the wheel" is fine under two conditions:

  • you know how a wheel works
  • you know how this wheel works
  • this wheel doesn't come with a whole bunch of crap you'll never use
  • you only want a wheel

READ Frameworks are OK to use if you know what you're doing and you've picked the right tool for the job at hand


Amen brotha'!

Frameworks have their place, and they should be used. But NOT while you're still learning.

Please people, don't be "$framework Developer", be "Developers" first, and add $framework to your toolbelt.


Sometimes (perhaps many times, especially for junior devs) you may not have a choice, either because you don't have time to figure out how you want to do something like routing, or the team is already using a framework, so you end up becoming an "X" developer out of necessity.


As a professional developer, sure, I'd say it's helpful to learn the underlying layer at some point but it doesn't have to be now, tomorrow, or a year from now. There's so much to learn with computers it's impossible to get to everything even in a lifetime.

Some people can be interested in the outcome of programming, they aren't here for craft or solving puzzles, and that's awesome! It means we've made tools easy enough for people to be empowered to create a piece of the internet they want to see, which IMO is more important than what they are creating with or how they are creating.


I've some sympathy with this position - I'm an outcomes oriented kinda person too! I much prefer to just get stuff done rather then argue about monads. Or project directory structure. Or where to put the bins out.

But I'd argue that the tools we build at the apex - the so-called frameworks - do more to slow productivity than to enhance it. How long have I spent debugging an Angular app I didn't need, or a Wepack compilation failure for a simple piece of Sass that could have been CSS?

This I suppose is the stronger version of my position: it's not just that we all ought to know the underlying layer, it's that the things we're using on top are often actively harmful to getting things done.


I think for the situation you are describing you're right, unnecessary middleware can make simple tasks more complicated than it needs to be. Although if a tool is causing more problems than it solves, it's either not working correctly (buggy software) or it's life has probably run it's course (old software).


Why do people like you like frameworks? Are you weak or are you stupid? Or both?

We got families to feed, duh! Many of us work for companies, we don't decide which language/framework/OS we're gonna use, etc, etc.

But I completely agree that you need to learn underlying stuff, especially the basic ones.


Its an old discussion but I must add. I am a physicist. I learned physics, from newtonina mecahnics to QM or QFT. If you want to be a physicist you have to know physics. If you want to be a web dev you have to know html, css and js. It is not to much to ask. Reinventing the wheel would be asking someone to invent new html or css or js not asking someone not to use a framework. I am new to web dev and I am wathing django tutorials and its a complete and utter chaos...If you are a web developer for real you should know your craft and your craft is html, css and js. Dont go to asembly of course...but frameworks seem to me as if I was trying to memorize physics and not understand it....If you understand frameworks and basics you should be able to make your own working pattern after some time and have your own shortcuts.


Yup - I like this idea around "memorising vs. understanding". Understanding is far more flexible and widely applicable. Memorising the individual quirks and tricks of a framework is fragile and narrow.


Yes and me being New to this it seems strange to me to use frameworks so much. Are you so bad at it that you can not develop one? Your own way of doing things I guess... Maybe it is really that complex and maybe frameworks are needed but learning django is driving me crazy.

In my experience (mainly of Ruby), some languages just don't have an ecosystem that allow you to escape a framework.

From what I hear Django is quite a heavy weight framework. Could you look for something a little more lightweight in Python?


This is the best post on this subject (or the only one) I've seen in a long while. Thanks for letting me know I'm not completely alone in the sea of framework-driven nonsense that has taken web development over in the last decade.

I kindly invite you to take a look at the pragmatic MVC approach in the appendix of my JS book: diogoeichert.github.io/JSwC.epub - where I demonstrate how to write a simple-yet-effective backbone for an SPA. No dark magic, no mystified concepts, just plain HTML with a little vanilla JS.

And let me add most web pages built with frameworks today wouldn't even need something like that, they could be simply server-generated, static pages. This MVC approach should be only used if the web page needs some serious dynamic interaction. Like app-level interaction.

The framework-first approach has become the new bane of web development. It over-mystifies the simplest building blocks, creating a new generation of DOM-blind developers.

And that's also why the WWW has become increasingly slow. What used to mean for the user loading a simple web page that could be contained within 10Kb of HTML, now comes with its own half Megabyte of useless famework wad. Meaning it should have been a plain static HTML page but it now carries loads of inert name-your-favorite-web-fads. And the scaries part of this is that almost no one is talking about the white elephant in the room.


Hi, I am relatively new to web development.

I have built projects with HTML/CSS/small amount of JS and I have also built full apps with React. I have no issues making something with react. But I really struggle making something purely with JS/HTML/CSS.

Can anyone recommend any tutorials where they build a web app or website with no JS framework ? Or anywhere I can learn how to implement my JS skills? I struggle with setting out the JS and where to use it.


Even low-level languages like Assembly are just frameworks to move electrons around with, and the same is true for Python or Ruby, only at a higher level of abstraction.

I realize the spiteful and polarised rhetoric is intended to illicit responses and start a conversation, but it's unsurprising that those responses will often be equally spiteful and polarised.


From 30 years of dev experience I couldn't agree more, David.
And yes, I have to deliver quality web apps (and underlying APIs) at pace.

I baulk at the argument that frameworks speed up development. I find that writing Plain Old JavaScript gives me so much control over what to do with the results, so I can 'fiddle with the minutiae' of coding to make a great web app as I have that deep-down control in the first place.

Sure, there are repeated 'patterns' in development which I'm quite sure jQuery has reduced to a $ call, but when I want performance and have it under my control? I just write the pure JavaScript myself.

My take? It's better to remember the JavaScript patterns for a particular task, always.


Sure, if you want performance then it is good to be 'close to the metal'. High performance is a non-functional requirement that not all of us need, and it is better to focus on the domain than reinventing Knockout, Vue, react, angular, or whatever buzzword framework you want.

I find it hard to believe that writing your own frameworks for large Enterprise projects does not lead to slower development times than using a tested off the shelf solution.

What we should be teaching developers is how to understand when to use the tools available to them, not the equivalent of constructing a table saw every time they want build some furniture.

I worked most of my career as a server side guy and this hostility to frameworks is completely alien to me.


Thank you Nick - you put it better than I could. Or in fact did.


Disagree. Completely. Especially beginners should use frameworks, because they teach you how to structure your code. You don't learn MVC by reading a book, you learn MVC by grabbing Rails or Django and getting your hands dirty. (The same is true for all the other architectural patterns.)

I don't say that you should keep using frameworks all your live in all your projects, but frameworks take away some of your freedom - your freedom to code bullshit. Frameworks raise additional errors, they complain about stuff that might be completely fine outside the framework, but is not in the framework. It's not enough to learn the language when using a framework - frameworks make you read additional tutorials and documentation so that you learn how to apply the language.


Well I disagree completely too - so at least we have that in common!

you learn MVC by grabbing Rails or Django and getting your hands dirty.

I think all you'll learn is Rails or Django.

frameworks take away some of your freedom - your freedom to code bullshit.

Sure. But, in the words of Jeff Goldblum, "Bullshit finds a way". Frameworks just mean you'll code your bullshit in new mutant strains around the framework's constraints.

frameworks make you read additional tutorials and documentation

Isn't this a bit of a smell? When half of the books published on programming seem to be about how to use a particular framework? Always seems weird to me...


I give you a "like" because of Jeff Goldblum. :-))))


The amount of sass in this article is incredible.

That aside, yes. Stick to the basics, so that, if your job requires you to actually work with a framework, you can point out what the hell is wrong with their code BECAUSE they used that framework.


The amount of sass in this article is incredible.

Its just plain CSS! 😉


I walked right into that omfg.


I agree with many of your points, such as understanding how the lower layers (HTTP, SQL) work.

But not using a framework will cause a lot of headaches. Writing code for a toy website is one thing, but writing one that supports real users and customers is another thing. No developer would want to write original code for SSL, user authentication, a templating tool, all those HTTP headers, a caching module, session handling, a custom ORM, etc.. Writing original code for authentication alone would be extremely risky and prone to security flaws.

I "get it" that developers need to understand what's under the hood. They should have CS fundamentals down. But not using a framework and trying to write all new code for a website is a bad idea for 99% of projects.


I think some people are reading what was said too literal here.

I know what the post says but don't read it too literal. Think about what it says.

He's not saying you go out and write your own parser. He's not saying you go out and write your own web socket implementation. He's not saying you go out and write everything in pure machine language.

He's saying to think about what you're coding. Think about what is going on. Think about things before you even write code. Think how it fits with what you're currently doing.

When you start to do this then you actually can pick the right tool for the job. There is no 100% rule them all framework. Don't think there is or think you HAVE to do it in this.

That is what the post is actually saying. I know what it looks like it is saying if you just read it word for word, but like most things there is more too it.


Yes. But it's also tagged #beginners who don't have the experience or confidence to read between the lines and get at the gist. They will read it literally and be dismayed because it makes it sound like they need to write their own everything before being a good developer.


That is where I think I'll have to disagree.

I've been a beginner (we all have) and I remember vividly being a beginner. I remember the advice I got as a beginner. I've had some of my favorite nentors and even the one person who changed my entire life and got me interested in software development in the first place give me advice very similar to how this is written.

I believe part of being a beginner and learning is figuring out and taking the time to think about what your should do vs. researching "how do I do X an Y in Z framework."

So I'll stand by and say I've had similar advice when I was beginning and it was some of the best advice I ever got.


David, sounds like you need to check out Vanilla JS framework. I bet it will become your favorite framework after looking at it for 5 minutes. Maybe in even less time.


I'm its biggest fan!


time to learn the basics, son.

Lol - hoisted on my own petard...


The last sub-header of this post is: "Learn the basics, not someone's abstraction". That should have been the title of this post.

But the actual title, which is more polarizing, definitely caused more pageviews. So dev.to should be happy.


True, it would've been a much better title. If I'd proofed the piece and let it sit for a few days it probably would be the title. But it was a hot day and I wanted it done by lunchtime. So it goes.


Wow... So much hate for just trying to say "maybe understand JavaScript a bit more before you become a JavaScript framework Dev". Like David said, frameworks will come and go, the basics are the same, learns those. And to boot, he is literally saying it because he wants you to be a better Dev!


just trying to say "maybe understand JavaScript a bit more before you become a JavaScript framework Dev"

Indeed, if this is all the author said, then any real backlash would be an over-reaction.

He set the tone by opening with insulting both people's work (the frameworks) and then people themselves:

Frameworks are all terrible. All of them....Why do people like you like frameworks? Are you weak or are you stupid? Or both?

If you call people's work terrible and then imply that other people are weak and stupid - what reaction should be expected?


I guess I just took it as hyperbole.

I think this might all boil down to British humor that isn't coming through for all the readers (myself included).

It is the mix of hyperbole with actual advice that make it difficult for me to understand what is intended - education or satire.

I just try to take everything as positively as I can. Frameworks are great but junior devs often get mixed up about what is JavaScript versus what is framework. Learning JavaScript will help you be able to use the frameworks better.

I love British humor over American humor. Maybe that's why I could relate! Haha


I agree that a good developer should have the foundation, knowledge and skills related to basic development first. But there's absolutely nothing wrong with using a JS framework. Majority of developers code for a living, for a business, where productivity is always measured. A decent framework will usually aid most solid developers with their productivity. In 2018, if I see a developer not leveraging frameworks or whatever tools are available to them, I'll question their ability to deliver solutions within a reasonable timeframe.


Thanks for keeping things relatively civil in the discussion, folks. This sort of thing definitely riles people up. Thanks for the contribution and discussion David!


I do agree on the js, but not on sass. Sass is still good, because of utterly-stupid-mixins and placeholders. Specially placeholders. Placeholders are amazing to make someone understand what inheritance is, when it can be a so-called pain in the butt, when it can save you from writing about a hundred lines. A lesser known benefit of sass is, it is a very gentle was of introducing someone to command line.


I've been meaning to reply to this comment all day, because it really stuck in my head. Thanks Samia.

I've never really considered people moving in to development via CSS as their first step. Yes, in this sense Sass makes a lot of sense - a more complex language with more things to use. I wouldn't want to get in the way of a pedagogical technique - it's great.

But I guess my counter point would be that I would want to demonstrate some of those principles you mention above in a more general purpose programming language like Ruby or PHP.

But it's really about what interests people sometimes; if you're very in to your CSS, Sass could be a wonderful thing to learn and use. I think I'll have to think more.


You're welcome. Since we are talking about newbies and people slightly more experienced than that, I hope this comment gives you some more food for thought.

a lot of people, including programmers who are experienced in other fields, starts their web programming with HTML and CSS. Now, an experienced programmer knows how scope and inheritance works (really, once you know some basics of management; yes, management; it's common sense. so newbies can know it too) and it's very natural to them by the point they start web programming (I only know PHP and not a lot of it, so I may be wrong) and they absolutely rebel (ok, I exaggerated, but bear with me) at the idea of having a global scope for gasp everything. They then think of conditions, but oops, CSS doesn't have it either. but they can't escape CSS, their site won't look so nice and shiny without it, so you get three different classes that do the same thing slightly differently. If you are teaching someone, scope and inheritance can absolutely be demo'ed using general purpose language,but in the context of web programming, specially if you are not going the js heavy route,it's perhaps not a very good idea. Because, well, debugging. Debugging a global-variable-gone-wrong in any semi-complex code is very, very hard in javascript (YKJS has some very nice examples). In PHP, either you look at your screen, baffled at why your program is behaving that way or you get an error. But CSS? it's easy. it's not a programming language, but you can make it behave (somewhat) like one. Add Sass to the mix and you get an almost programming language, loop and if-else is back in business and you can finally write proper local scope without the code looking like a pile of a random-language-dictionary. Debugging is still difficult, but now you don't have to go through all the code you've ever written and while debugging, a light-bulb goes off in your head and you realize global scope is "actually" very useful in CSS, perhaps a lot more than in any general purpose language. it goes the other way around too, someone who doesn't know the first thing about programming principles can quickly catch on because they can see the problem (the entire language is the scope problem) and the solution, all in one place.

Also, let us talk about CSS variables. They are incredibly useful, but they don't really makes sense, not yet. I know it is controversial, but read on. I say this because there's no "operation" on them, not yet. CSS has no loops, no if-else, no functions (I'm not counting calc()). So I get this question a lot "but, I can just write them there, right? won't that be easier?" It's like the new shiny gold heels in my wardrobe, it complements my dress fabulously but I could just as easily have worn the dress with another pair. But variables in Sass makes sense. you can just hold a value or you can hold a value and run operations on them. So when you write "You don't need Sass, CSS has variables now." it does not show the whole picture. CSS feels restrictive to a lot of people, which in result makes them want to use frameworks to "just get it over with". Sass can make them learn the fundamentals, which is the whole point of your article.

So my point is, even though general purpose languages can be used to make someone see the programming principles, when you are web programming, CSS and Sass are the easiest choice. And CSS by itself, is not very interesting to programmers who already had a lot of freedom with other languages, which in turn, encourages them to "bootstrap their site to death". Sass can actually make CSS interesting and in turn, they learn how it works, write better code and don't use unnecessary frameworks.


I completely agree, i have seen bunch of people in various projects what they thought were front-end/full-stack devs. First thing they installed bootstrap and jQuery and spend hours of stackoveflow-ing how to use it, ended up in CSS/JS/HTML in the same 1 file, not scalable, testable nor maintenable application/web. Having tens of ($)plugins what are doing the same thing, but why not use every time different one? It's so easy and convenient, but having no idea about synchronous javascript and calling yourself a developer is out of common sense.

When i introduced CSS/SASS/Vanilla JS they were completely lost, they couldn't understand any of the OOP or Classes nor "this". Idea of having JS/CSS/HTML in separate files was completely new to them. Funny the same developers were pushing to use React or Angular - very scary scenario.

Having a deadlines or doing your job is not an excuse for anybody's knowledge! I would not trust doctor, surgeon, painter, construction worker... if they would have no idea what they are doing but they can somehow deliver because it's their job.

If you want to learn and be a developer don't expect your company to pay you to learn - as it was mentioned you are there to give them solutions. If you want to learn about development take your own time for it, read, watch curses - whatever is the best for you, just don't expect that somebody will tell you at work to take time off to learn how to write code.

I have taken an approach in our team to completely strip and get rid of anything jQuery and re-wrote it in Vanilla JS. Now i can really see what is the maturity of our team and once we get the basics right we can think of a framework what will embrace our work and our effectiveness.


It looks like the real issue is the learning material or the will to learn by devs, not the existance of frameworks on some internet page 😛


This guy gets it.

The entire discussion here is a red herring: "the noobs use frameworks as a crutch because they can't code good, therefore frameworks be bad"

We should focus on teaching juniors good programming principles instead of trying to convince everyone that frameworks are a bad idea.


If I had no budgetary constraints in most jobs I held, I would code in assembly


I've seen this same article theme rehashed many times, but never quite this condescending. The whole premise is a fallacy because "Someone's abstractions" IS programming at every level, all the way down to the hardware. The message just boils down to "Learn Browser APIs", which is fine, but they are just "frameworks" built into the browser and that knowledge will get stale too. In the real world, almost every serious app uses a framework because they save time, save money, and just produce better products than vanilla browser code.


Being a dev before the css/js frameworks hit the scene has jaded my views on frameworks. Basically, learn the underlying language then use frameworks. Nothing worse than wasting time interviewing a candidate that knows Angular but cannot write a simple array and filter in JavaScript.


I can see both sides of this. Although I don't think it was worded as well as it could have been in the article, I don't think frameworks are always necessary.

Being a person who learned jQuery before I really learned javascript, I can understand why it's appealing to learn a framework so you can make something work. Eventually jQuery either wasn't challenging enough or I wanted to know what was going on under the hood so I learned javascript. I don't know that I would have continued with web development long enough to reach the point of learning pure javascript if I hadn't started with the framework and seen immediate results.

On the other hand, knowing how to do things without a framework is definitely a capability to have. Understanding both the reason for the framework and how to use the framework is much easier when you know how to do things with plain old javascript. It also means you can appreciate how much of the heavy lifting the framework may be doing.

I really just think it depends on the person and what they are motivated to do. If you're a person who wants immediate results to see what you can do with it, go with the framework and learn the "under the hood" stuff later. If you want a better foundation before diving into the framework, learn pure javascript or whatever.

Just do whatever makes you most excited and you'll eventually figure it out.


Hey, thanks for the well reasoned and polite response!

To address your point about jQuery/JavaScript directly - I honestly believe that the capabilities of JavaScript in a modern browser make a library like jQuery redundant. I don't think you need to learn the 'under the hood' stuff later - I think that it's powerful and simple enough to do what you need to do, for both new developers and seniors.

Just do whatever makes you most excited and you'll eventually figure it out.

This is always true.


I agree about the redundancy, but when I learned it things were a bit more difficult. Not to mention for someone just starting out, I want to build things. Learning if/thens, variables, and calculations are cool, but it’s not directly apparent to a beginner how to make an offcanvas drawer slide out when you click a button.

The sheer popularity of jQuery made it very easy to find code/tutorials for this. Heck, I google an issue I’m having with vanillajs and the first 5 links are jQuery solutions.



if you work alone, yes you don't need to use any framework. Build up your basic first and as long it works, don't give bug, and the client satisfies with it, it is ok.

but if you work with a team, you need a standard structure for people to working together. for me, that is the point of having a framework.

I have been in a company that doesn't really use a framework, any framework, they just hate it when I mention about changing their development method from vanilla to framework. The manager will look at me like he will kill me if I mention any framework.

oh heck, the even don't use OOP approach.

for 8 years, it is pain in the a**.


but if you work with a team, you need a standard structure for people to working together. for me, that is the point of having a framework.

Have you tried talking and collaborating with your team? Is it really neccessary for a framework to enforce a collective sense of what software should look like?


It isn't necessary, it just costs time to roll-you-own. Which means money (salary mostly) and opportunity (time-to-market mostly).

When you use an existing framework you save time in at least these areas:

  • Writing documentation and keeping it up to date
  • Getting a new hire up-to-speed
  • Implementing new features
  • Guarding against security vulnerabilities^
  • Getting answers to questions without costing the time of a teammate

^ Security is a big one, Rails for example has a bounty program for finding and reporting vulnerabilities. Is your team paying someone to find security vulnerabilities so you can patch them before they are exploited?


If I could like this more than once I would!

The web has changed so much in the last couple of years, and the first thing I tell new devs is to not fixate on these frameworks and learn the fundamentals.

From now on, this is the article I will send them too! Thanks!


The day I heard someone talk about "Native Javascript" I realised the level of idiocy to which front end web development has come. I guess that's why some people say they're "coders" instead of "programmers"...


We all have anecdotes about people who have said stupid things. I've met some extremely incompetent back-end developers too.

But if you genuinely believe that all front-end development is idiotic then you're a bit out of touch. Maybe try to find a community of serious front-end developers and open a dialogue with them instead of just writing them off as mere "coders". You might just learn a thing or two :)


WOW!... You missed the point completely... That was no anecdote: there is a whole host of people talking about "Native Javascript".
Plus, when I say "some people" I expect you to interpret this as "some people" and not "everyone". It never occurred to me that I would have to explain this to anyone.
Try learning a bit of English. You might just figure out a thing or two.


This is a disturbing article. Does anyone seriously claim that it's easier for beginners to use a framework? Like, if you don't know how to write a form element without a framework, you'd have to be a masochist to try to learn to do it with one. And, if you've managed to figure out how to make one with a framework, going back and learning how to do it without one will seem trivially easy.


Hello David,

Thank you for sharing with us your thoughts and feelings about the usage of web frameworks.

I've noticed recently, that web frameworks become a new life style in web development. Tutorials, dev camps, cons, everywhere we talk about them. Corporations and sponsors promote the usage of frameworks and their whole ecosystem, and attract developers, mostly beginners, in my opinion, for one reason : "Sales".

But, as a developer, novice or expert, or as a team, do we really need web frameworks for our projects? I don't think so.

Web frameworks give you "wings", like red bull, but enforce you a specific way of how "to fly". They are useful for rapid application development (aka RAD). It's a double-edged tool to use with caution.

We are missing solid and robust libraries to make the jobs done. That libraries handle simple issues, like cookie serialization, HTTP request parsing, middleware dispatching, etc, and let you mix them as you like and how you like.

An all-fit framework doesn't exist, and will never be.