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?
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.
You're wrong! You miss the point... And he's not surrounded. If you take a look at this comment section you'll see there's a ton of people who fully agree with him. Because, again, he's right.
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?
What's the point of delivering if all you deliver is Little Caesars? What's the point of developing if your client can do it themselves?
Learn to code? You might as well learn to lie like a journalist. The age of homogenization. Music, movies, cars, houses, art, ideas, speech, content, and websites. But, hey, it's all about the $$$, and if you're makin' it, keep on keepin' on. Until I sell your client a higher quality website for cheaper.
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.
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.
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?
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.
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.
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 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 :)
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?
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.
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.
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?
You're saying I'm close?
You're hilarious
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.
You're wrong! You miss the point... And he's not surrounded. If you take a look at this comment section you'll see there's a ton of people who fully agree with him. Because, again, he's right.
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?
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?
The first one. What's the point of developing if you never deliver?
What's the point of delivering if all you deliver is Little Caesars? What's the point of developing if your client can do it themselves?
Learn to code? You might as well learn to lie like a journalist. The age of homogenization. Music, movies, cars, houses, art, ideas, speech, content, and websites. But, hey, it's all about the $$$, and if you're makin' it, keep on keepin' on. Until I sell your client a higher quality website for cheaper.
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.
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 think you're a skillful dev... That's the idea you have been passing around.
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.
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 :)
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.
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.
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
Try not making a "framework" but just well decoupled, testable code. You can get very very far with just that.
I think it's more dangerous to only use tools that only your best and brightest understand on a good day.
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.
Thanx, dat's insightful
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.