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 Rail...
For further actions, you may consider blocking this person and/or reporting abuse
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
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.
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?
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.
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?
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.
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.
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.
You're hilarious
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.
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 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'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.
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.
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?
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.
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
BTW
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.
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
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
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 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:
I can assess if a framework is needed based on project complexity.
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.
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.
Summary:
READ: Frameworks are terrible and should be avoided. (no jokes)
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).
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?
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.
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!
I think all you'll learn is Rails or Django.
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.
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.
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!
*its
time to learn the basics, son.
Lol - hoisted on my own petard...
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.
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.
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 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.
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
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!
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:
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
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!
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.
IMHO,
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**.
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:
^ 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?
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.
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 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!
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.
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.
Thank you David Wickes
May you live long.
I do choose frameworks. If i can not use HTML, CSS, JavaScript, PHP, ASP, SQL, and C#/Java; I should try another career path.
This has been my own rule since day one and I keep to it.
For the first time I find a bold article clearly written about a decision I made years ago.
I am more comfortable with the good old Notepad for all coding, and sometimes the MVS IDE.
I still use DOS commands to manage my directories.
Yes, I am not the best out there, but the little I know gives me joy.
Your article, Sir, gives me the courage to continue learning and applying.
I also understand you did not say, 'do not use frameworks'.
Thank you so much, it means a lot to me, I feel energized, because I like digging things to their root. I like knowing what things are, why and how, they work.
Thank you David Wickes, I am following you from today onward.
I am Mr. Chieki Chukwuezugo
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.
Thank you for this. I recently worked under a developer who used frameworks for everything. His thinking was completely governed by them. It was awful. Seeing people defending frameworks as a solve-all tool is a depressing reflection of the state of our industry :-( . "Know what you're doing" (a bit) should really not be seen as elitist.
It's funny because I feel like the dev out of the "cool kids" block 'cause I've always been doing programming in plain HTML, CSS, JavaScript (a little bit of Jquery) and Java and C for that matter. And all I hear around is the people talking about NodeJS, React, Angular, web frameworks for Python, Ruby, Go and God knows what else will come after.
OMG thank-you for this. I hate everything about the current state of web development. The arrogance, the zealotry and the emphasis on trendy frameworks. It's so infuriatingly stupid that people create a rube goldberg level of complexity in order to use a screw driver to hammer in a nail.
While most of the people doing this probably don't know any better I can't help but think this is an indictment of the entire profession. Back in I think it was the Baroque Era of music musicians figured out a way to use complexity as a wedge to keep out amateur musicians. They would purposely write sheet music in extremely difficult keys that only very experience musicians could play easily. Then when someone in the aristocracy asked for a certain song to be played they needed to have a very experienced musician in order to play it.
I can't help but think developers have done the same thing with web development. Everyone has created these massively complex and overly specific frameworks on top of relatively simple underlying code. Solutions are really just band-aid that break down quickly as soon as any element in an overly complex system is updated. Instead of creating robust solutions developers become these religious fanatics for their framework because the more people who use their framework the more marketable their skills become.
Man, I have so seen the light. Since MSFT decided to ditch their browser and go with Chromium I've come to believe that webcomponents and no frameworks are the way to fly for the VAST majority of projects. I took up your TODO challenge and knocked up an app with multiple components all chatting away to each other - and async to the server - in 400 lines of JavaScript (complete with EvilBoss adding pointless meetings). And nary a framework in sight: github.com/petercz1/todo_no_framew...
The only extra bit I had to master was how pubsub works in JS. Now I have that cracked I know what's happening in every line of code. Can't say that when you do npx create-react-app wutevah...
I was -really- skeptical until this line: "...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...". After that I was sold.
You points are all valid. To much today is abstracted away from the base technologies.
Well written article, well stated points, great ending.
Thank you for your writing.
I would like to address my personal point of view at the problem describe.
That's remind me of the saying of one friend of mine:
I could not agree more with the second. What I do not agree is that using a framework is not necessarily making you into a bad developer.
The exemple of the "right" framework for the task has already been introduce into the comment so I'll arg on another one: Sometimes, you do not need to understand more than the gross picture. For exemple, one might realize an application making real time image through a webservice. The "most" important part is the rendering. He migh use an http framework getting care, at least for the short term, the web part and concentrate on the rendering. You don't need to know how a car works inside its engine to drive it.
That being said, the gross picture (at least) should be acquired.
Also, even if framework may come with a number of tools useless to you, sometimes it is still the right fit (like QT for C++).
And then, arrive the professional question. You have deadline and possibly an existing environment. If a company use React (more Library than framework) it may be counter productive to ask the newcomer to not use React to learn how to make a renderer lib themself.
Same kind of problematic with deadline.
Of course, it works also the other way around, sometimes we got the times an resources and no particular need of an existing framework.
On another subject, I think it's not appropriate to attack the author credibility with terms such as "fanatic". The discussion is much more interesting without "ad homines" attack. Sorry if it sounds bold of me, but I think someone who put work into writing deserve better.
I also find amazing the rampant epidemic of strawman and other fallacious remarks in the comments.
If you are sane, you will decide on wether you should use a framework or not based on cost/benefit analysis. Obviously.
Most interesting. A lot of discussion about libraries vs frameworks, but there may be a third player; the DSL. Is a language - SQL, for example - a library or a framework? It neither calls your code nor is called by your code; it is your code.
In regards to missing deadlines, etc, if you don't use frameworks: No, it would actually be faster, and the code would be smaller, because you can design it intentionally (more on this in a bit).
There is skill in knowing when (for each thing or at each layer) to use a well designed tried and true library versus rolling your own, but in either case that's about composable units that you use to fill in holes of meaning (aka abstractions) in your program.
With frameworks, it's the reverse: You fill in the holes of something that's not the thing you are designing (how could it be?), and which must deal with 1000 other things that do not apply to your project, but affect what you get and how you must use it.
In either case, the software being developed exists solely to model and enact some specific human value, which must inevitably be designed and delivered.
So the real problem is actually not about frameworks per se, but that that design is rarely ever direct or intentional. Instead you get (in either case) a mess of mechanisms & patterns from which the desired model/behavior is supposed to emerge (e.g. by slicing it up among these things and rigging it to trigger in some clever way). It doesn't have to be either a bunch of kooky pattern(s) and mechanisms or a framework that does it for you. Just regular old programming paraphernalia, and good old abstractions of the actual human value.
Any decent program can be built on a simple foundation of abstractions that are fairly 1:1 with the human understanding of what the software is, and what it does (which are two separate things, btw). And those upon lower level abstractions, etc. But at each level, you are making components that compose like libraries, NOT a framework, and not a clever wire-up of a bunch of "patterns" (e.g. AOP).
But as soon as you break any of those rules, you get an incoherent mess. And unfortunately this stuff (which should be basic fundamentals) is not taught or understood very well, and many programming languages, paradigms, patterns, tools, and frameworks violate and/or encourage you to violate one or more of these.
And so frameworks only solve an artificial problem, while making it more impossible to address the fundamental problems they fail to solve, because the backbone of your software is now this framework instead of a codafied model of the value it's supposedly designed to deliver.
Right:
"Frameworks are all terrible. All of them. I'm serious - they are making you all into bad developers. Stop using them now" ...
All I can say is, total rubbish, biggest nonsense I've ever heard.
If I'm on a project or a job and I have to pay my bills at the end of the month, then the only thing which counts is "does it get the job done". If it does, then just keep using it. If it works, it works, it's that simple. In many (most?) cases it's not even for me to decide whether or not to use a framework, or which one for that matter.
If you have such a strong opinion about this then don't preach - show!
Convince me that it's so easy, and realistically feasible for a person with deadlines and without tons of time on their hands. Show me the absolute minimum CSS (and JS) that's needed for a real-world website, covering (amongst others) CSS resets, viewport, typography, color scheme, layout (grid, responsive), accessibility ...
When I see a convincing example of something that takes care of all this (and doesn't take weeks to put together), then I'll gladly drop my frameworks.
Oh and don't get me wrong, I'm 100% for learning and mastering the fundamentals, but that doesn't mean that not using a framework would be realistic or even a viable option on many projects.
I partially disagree with you. To know the basics and the lower level layers is very important, that makes you understand how the framework is doing X or Y. But when we're talking about product development, not software, that involves business value. And business value cares about result, and a framework can help you with that.
By finding the right tool, you can solve a specific problem. The problem is to find the right one.
Created an account just to comment here. Ended up here after some frustrations on working with materialize which no one knows why its included in our projects. Everywhere devs are utilizing frameworks without even analyzing whether they ctually need it or not. And for God-sake change the background color of your follow icon or the follow text to something less contrasting and pleasing to the eye. I cannot read the article at all without zooming in to get that button out of my sight!
You're the first person ever to mention this - it was deliberately horrible, but I will change it now!
Hello everybody,
First of all, thank you @DavidWickes for this post.
As others, I agree that the 'title' might be misleading but once you read the 'body' or let's say, the article itself, the misleading is clarified and solved.
To add some value to the discussions and put it simply while reinforcing the article: I agree and recommend what David Wickes states BUT I would separate it in two differing paths:
1) If you have never learned to program and want to be a programmer or related to it (software engineer, tester, architect, user...), then start as he mentions, spending 3-5 years learning the fundamentals.
Do that by:
1.1) ask yourself what topics would you like to specialize: are you going to be a Data Scientist, a Web developer, a Mobile developer, back-end, front-end or full-stack developer? Kernel developer or FW developer? Low-level languages or high-level languages? Compiled or interpreted? Caring of memory issues or let the choosen-language do it for you? Long etcetera. It might take you even a day or more to decide that but is worth it to spend some time to decide your future career and professional life.
1.2) do you want actually to "specialize" or be more a "generalist"? Meaning, do you one to pick-up one environment (mobile, web, business-process, business-apps, database-mgmt...) and be a master/guru solely on that topic(s) or do you want to be a programming-polyglot where you can program in 3+ languages, know OOP, algorithms fundamentals, etc and being able to apply to practically any job/environment but without getting deeper on those topics?
1.3) once went through them, start by learning fundamentals on that direction as suggested by the article:
1.3.1) search algorithms.
1.3.2) sort algorithns.
1.3.3) pseudocode usage.
1.3.4) design principles.
1.3.5) http
1.3.6) database & SQL.
1.3.7) one programming language that feeds previous decisions:
1.3.8) c/c++ for OS, kernel, cross-platform & performance needs.
1.3.9) java, python, ruby for non-performance needs, high-level needs.
1.3.10) JavaScript, PHP, CSS, HTML (long etc era and also the ones in 1.3.9) for web development.
1.3.11) IOS or android for Mobile DEV.
2) you are already an experienced developer but that relied too much on existing frameworks without first jumping to the fundamentals, then please go throw all points listed up in the 1) and 1*). It is time perhaps for you to go throw it deeply.
Hope it adds some help to what @david maybe (and I say "maybe") not that correctly wrote in the 'title' but that expertly described in the article's body.
Kind regards
The average business user is way past standard HTML … They want word/excel in their browser … just ask them … "I want it to work just like word " … if I had a nickel for every time ive heard that crap from business users. Well guess what dude … This isn't word … its a HTML and there are tons of limitations and reasons why you cant have word in your browser.
OMG! No kidding, I was crying after reading, may be the 5th paragraphs. Look, I am not 100% against using frameworks. But there are many situations that we don't need one. And, I have a hard time understand why we would need one for most content based websites. 99% of the time, when a comment site needs major redesign, whatever framework you have chosen to use would have be so outdated that you will have to get rid of it completely, which, of course, defeat the so called "benefit"of using a framework.
My biggest complaint about any framework is that they make developing simple site/app complicated. Take Vue as an example. It is supposed to be lighter, simpler than React, but it is heavily relied on using the cli if you ever seriously into creating components. The problem is that the moment you start using the cli, you lose the simplicity of web development. Your client side code suddenly won't work at all without being built! What makes things even worse is that, some people don't even realize that! They look at their codes and sees that they are using "import", but they don't know that the "import" they are using isn't exactly the same one from the web standard.
I agree somewhat with your article. Sometimes frameworks are a little bit of overkill, specially on Javascript where you can do many things with Vanilla javascript instead of jQuery I specially dislike frameworks when you get an error that you have no idea why it's happening and it ends up being a framework error.
That being said... Frameworks are pieces of software that have a very active development cicle, where many developers have tested and fixed bugs in all its iterations, which is why they are 10 times more secure than any pieces of software you write from scratch, specially for beginners.
For example: One of your requirements is to build a backend protected by a login on PHP with social login and user roles. You can use Codeigniter, Lavarel or your choice of framework and create a secure robust backend or write everything from scratch, taking twice as long and leaving it very insecure and prone to your errors.
This is why I immediately turned away from jQuery when I first started learning to code.
At the time everywhere I went to learn the approach offered was write this jQuery, it will take care of all the stuff for you. Ok cool, but what's the stuff?
It became clear that if you ever want to actually know anything about the code you are writing, you've got to walk in the gutter and learn the underlying language.
This doesn't mean you can never use a framework, but you defiantly should not start there. At least not in isolation.
I don't get all the hate, the author receives in the comments.
People bash almost every program language there is (JS, PHP, Java .. and so on), but all of the languages have their purpose and were (and will be) a great solution to a variety of problems. It is the same with frameworks.
Of course he does not mean the frameworks are all bad all of the time. It's only that, to become better yourself, is to learn how every bit works (even if that means to understand the path of the electron on the silicon board).
Of course he does not mean for you to experiment, at the expense of the active project, you have in your company. Most companies have a well tested and well documented code base already, if your team is comfortable with that, than by any means use that. Choosing the right tech is always a team effort, but the message I received from this article (and live by), is to always be curious.
Good marketing with the click-fury-bait title. Lovely article by the way, it is very amusing to see how developers can not read between the lines and start arguing with the author. People are so overzelaous on sarcastic generalisation like it is a new shiny framework they wanna try out. Funny but still to the point article (for those who don’t get upset immediatelly).
This guy is obviously a Gungan. I also think people are crazy for going to a grocery store when they aren't going to buy everything or even half of the things. Why don't they learn to milk a cow or grow their own fruits and veggies? The same principle applies. Because having things you don't need is the American way!
I don't disagree with your point of view, but I would disagree a little bit with the execution of your post.
From the beginning my blood began to boil, not because a WHY, but rather because of how it is written. Just as soon as I read your conclusion my view of your post shifted and I totally agree. That being said I would recommend another approach for this kind of posts.
It is truly sad that nowadays I meet a lot of pseudo-developers that just know how a framework works but they don't know what lies beneath the hood. It is stupifying how sometimes they gloat in the fact that they are masters of REST API's in Django but they cannot even grasp the concept of something like GraphQL. And they believe the learning curve is too steep because they need to learn another library like graphene just to understand. Sometimes this type of developers just waste a lot of resources because reading http requests, MDN, or even the underlying code of the framework seems too hard.
I fully agree: You shouldn't use a framework until at least you grasp what it does underneath.
But I totally disagree with trying to generate an emotion in the reader to have a greater impact.
Hey, I'm sorry I made your blood boil! It's far too hot for that. Maybe I was too hot when I wrote this post... but thanks for the response and feedback.
Thank you. An interesting take on the use of frameworks. This is quite a polar approach though. I think there is a place for frameworks because of TTM but you do need to take the time to understand how they and how the underlying technologies work.
Working this way has stopped me from programming by coincidence
While I don't completely agree, I think your thesis does have some merit.
I think using a framework/library (like React, or Express, or Flask, or SQLAlchemy, or Rails, or Spring etc.) isn't inherently a bad thing. In some cases it speeds up development a lot without really having any major down sides. If the cost is something like a performance penalty down the line, as the application begins to really scale, I'd say that falls into the "good problem to have" category.
However, it's true that the current ecosystem is just rife with frameworks, libraries, addons, plugins, extensions, and so on. It's very easy to reach for one after the other. Below are some ad-hoc guidelines I've built up for myself over time:
I've run into situations where I try an extension or plugin, and discover that to use it, I have to install at least one more extension! When that happens, I generally will remove the initial extension if at all possible.
Another scenario that happened to me recently: I tried using an extension and found a bug in it. When I searched online to figure out what was going on, I discovered that the proposed solution was to go back to an earlier version of the code. Furthermore, the project appeared to be completely inactive for several years with the owner not responding to any issues. Of course I removed this dependency from my project.
Boilerplate is one more thing that I think one should watch out for. Redux has some interesting properties, and it looks pretty good on paper. But When I tried using it in my project, I discovered that I really had to create a lot of confusing boilerplate to do simple things. For now I've removed Redux in favour of the new React Context API. It's not perfect either, but it did simplify my project a lot.
More generally, as one adds more dependencies to a project, all of the above scenarios become potential problems later on, even if they might not be a problem right now. So I think developers and teams should indeed be very cautious about just throwing more and more dependencies into a project.
The first questions should be "Can we make our own simple implementation that will do the job for the time being? Can we do it without taking too long to develop it? Can we do it without creating a lot of complex logic in our codebase?" If the answer is "yes," then don't use the 3rd party code. If the answer is "no," then it's more likely worth considering that external dependency.
I got the idea. When I started in web development was from zero and using windows notepad. Learned the basics and much more, I build what I want and exactly what I want.
My friends started with dreamweaver using the design tool without coding and everything was a mess.
In every project I reinvented the wheel in many forms and making mini-frameworks. using frameworks I learned a lot more complex things, also frameworks doesn't helps, you have to do the work anyway.
Where I work they do a test in the interview, a simple small crud, I was like "that's all?" But a friend only uses frameworks, she didn't know how to make a db connection, a crud or pagination, but she is an expert in many frameworks and she work really well and fast.
So It's important to know the basics and then learn a framework. I love to code from scratch and love frameworks too.
It is very easy to throw mud, to speak like that when you are in powerful position, already have a good job, know some CS and studied for years web dev.
First you need to understand from where they come, what difficulties they have, maybe some of them are starving, are in war zones, some of them are just lazy, most of them are just uninformed.
Let's speak about the root of the problem bootcamps and courses.
Instead of blaming the students we could do better, let's start making free or paid courses and online workshops, better than the bootcamps.
Let's teach vanilla and then frameworks, let's take them trough the entire process of developing a framework. You will soon realize that you cannot do that in 4h/week, in a few months, so you need to cut things out. Put yourself in the teaching position.
Let's make solutions, just saying.
PS: you also have to change how companies hire, they do not care if you know vanilla or frameworks, what is sequential allocation or a pointer, they hire engineers to solve their problems. What is the fastest way to learn how to solve problems? By learning frameworks. So again, let's find a solution for this problem before you throw big words.
Well yes, it takes years to be good at it.
Yes, some of them have good reasons of doing it wrong. This doesn't mean we should sugar coat it. They have to be aware, even though they can't change it now. But they will have the option of fixing this later, and they need to know that it's an actual problem. And there's a crazy number of devs that don't see an issue with this "framework-first" approach, that's who he was aiming for.
He's not blaming students. He's blaming the approach, wherever it comes from. The students shouldn't feel called out, they're, at best, the victims here. But they need to hear this.
Yes, getting good at programming takes a year of 8h per day. Yes, you can cut corners and start making something sooner. But you have to be made aware that yes, you took a shortcut, and you should come back to vanilla as soon as you can to fix this.
That would be great, if learning the frameworks solves the problems. Devs without vanilla knowledge (like basic OOP for example) that go straight for the framework cause more problems in the code they work with than they solve. Companies have hiring requirements, yes, but young devs don't need to aim straight for big companies. Start smaller, freelance sites, projects for friends and family. They can get better before applying for tougher jobs. Unless the company is hiring for an intern/entry level, they should get some experience first anyway. But yeah, that's a separate problem onto itself.
I do agree with the gist of what you wrote, the students are not to blame. The post writer wrote some things for effect, but nobody should feel called out for it, he's just speaking the truth in a colourful way. Students, as you call them, have the resources needed available online(for the most part) and they should take the time to learn, and it takes time to get good at anything.
I'm blaming the same things, so we are all good, I just want him to reconsider his hate approach and move into a more constructive one.
I'm speaking with junior web devs daily, I have studied the same problem in the last 2 years or so, I've seen the gaps they have, I'm not surprise if questions like "how to sum 2 numbers with react" exists on stackoverflow :(.
As a fresh mentor, I quickly realized that my "main duty" is to filter the resources. I think the today student problem is not the lack of good material, is the abundance of the lower quality material, and when you are studying you don't know the difference, you learn the "highest rated" personality or course.
After a few months of production, the "damage" is done, you cannot say "you learned the wrong way" because the answer is "but how? I can build websites, I solve problems". The best way to "fix the gaps" I have found is to get into the trenches, when they are stuck and explain them how and why they got it wrong.
Instead of "learn Big O and optimization techniques" we can say:
"Your view component is slow because: you see these 4 nested fors? ok, let's draw them on the table and calculate how many times these operations are computed. Now how can we improve them? ...."
Another good way is by example, I found that just by sharing my screen, they learn a lot, like how to use their tools (IDE, dev tools), how to approach a problem and so on.
Good on ya for fixing this from within the trenches! I try to do the same, I have a basics course in PHP set up (in my native language) and we start from the nitty gritty.
People struggle with looping through arrays in their first months, so no wonder they can't really grasp what a framework does. But they definitely need to be brought back to basics.
I've hired juniors, and I had better luck with those that knew "just" html/css/js/php, than with those that "knew" "Laravel/jQuery/Bootstrap", because with the former we had a base to work off of. With the latter they weren't able to navigate simple OOP relationships, let alone debug the first Exception their favorite framework throws up.
The industry is a bad place. We need thousands of develpers today, so we try to rush people through this. But that doesn't work. What you describe is the way to go. But I do agree with the original post as well. And I think it's more about the ones with about a years worth of experience that need to hear those harsh words, just so they're not complacent.
I think one of David's points is you don't need a framework and that's half the problem with this industry.
People immediately dive into a problem by picking a framework and you see it all the time with devs on various forums asking "what framework should I use".
@gypsydave5 , as one of my coworkers said after reading your article, "Using the right technology for what you're solving... revolutionary!" I live by the "KISS" it philosophy. If you want to get the most bang for your buck, do the least amount of work to get the biggest return. Sometimes that's using a web framework; sometimes not. I also wrote sort of a rebuttal to this on dev.to. Check it out on my profile if you want. Cheers!
As a 20 year dev that just got into the job market, I feel like I have a few things to say. For starters, I studied 3 years in web development and multimedia in a Québec college (Cegep) and we started with learning the basics (JS, CSS and HTML php and MySql later). Later on we leanred about JQuery, SCSS and Laravel. I believe that this is the best way to learn about the core first and then learn about frameworks later on. Frameworks and libraries make it easier when you've learned about the basics first. New devs should learn the basics first, life is gonna be much easier after that. Sidenote, In my current job, we're using AngularJs, and I was able to pick that up pretty easily even if I never touched Angular before. Sorry for the rambling, Have good day and have fun coding!
Make sure you don't live in a house either. Find a cave, kill the bear in it with your bare hands (using tools is cheating), light a fire somehow and try to survive. Then let the natural selection kick in.
Could I kill the bear with the bear hands I still have left over from the last time I did this? Just asking.
Sure! The question is will preaching around the village how using tools to kill a bear is stupid make you a first-degree or second-degree murderer.
This was amazingly accurate and hilarious. Tomorrow I'm going to share this at my company and watch the hate roll in: it's a Java shop and for some reason, Java devs tend to love their frameworks.
I think the comments will be similar to what they were here: many people following the slippery slope fallacy, not realizing that this is a satirical argument, that presents the absurdity of contracting a factory when all you needed was your neighbors toolbox.
So, do you have to do some work? Yes. It's a job that you are paid to do.
Do you need to spend the more part of your time figuring out why the aforementioned factory is on strike, or do you yourself twist that screwdriver?
I'll tell you what I'm going to do: borrow the tools and ask him to show me what's worked best for him. Maybe I'll learn something new. Maybe I'll just be a little more familiar with a neighbor.
Bollocks.
Well I get the point of “you should learn what’s behind”, but no one ever said that because they were using a framework, they’d never need to learn the underlying technology.
I started with AngularJS and progressively learnt how it works behind the scene. I learned new patterns and coding good practices, I learned its strengths and shortcomings, what to watch out for when coding things on my own (even outside of AngularJS).
So in retrospect, I’d encourage newcomers to actually use a framework so that they get a glimpse of what is recommended to do, what is comfortable to use, so they can slowly get up to speed on what they need to know about the web without shoving their head into a wall of bricks, because right now that’s what webdev is to the unwarned newby.
If I said “Don’t use any of that, do your own stuff to better understand”, I’d expect them to probably do shit, get frustrated at their unmaintainable and buggy mess, do some more shit, get frustrated again, quit and go become a carpenter or something.
You know what, frameworks are the reason I say I'm not a front end dev.
I can do nearly anything reasonable, and some less so, in sql alone-just give me enough time ok?
Today we had to duplicate a spreadsheet of aggrated results with um.... Just html and the result set. This set is a table whose entire content is a single result. 216 cells worth.
We generated the entire table in maybe 30 lines of c# and some dog simple css.
Its really rather nice, it's readable, we can maintain further pages this way.
And yet we are novices at html, css, and hardly ever touch javascript.
The work is worth money to someone.
Over complicating the front end is what my perception of frameworks is. If all I've got to do, to be a front end dev, is do a decent job of generating reasonable html and know my css, I can manage that.
Once, back then in 2012, I was working with a customer. We where making the bussiness case for an integration between my customer's ERP and their logistic's vendor WMS.
We met with the vendor's CEO and he told us he was finishing the development of their own operating system... Then I thought, "He must have misunderstood what he is buying".
Anyway, later that week we meet with the developer... And indeed, he was developing a whole operating system to support the warehouse's operations. He was leading that development since 2010.
Time has gone by, two years later I mounted my own software shop so I lost contact with the case.
A few months ago, casually met my customer... He is still struggling with that integration and his vendor never implemented his software.
This post reminded my that case, even if it's not the meaning of it.
Hey David,
Awesome article. It inspired me to try writing code with less frameworks. It exposed some holes in my knowledge as a dev but also helped me to gain some important skills and insight. Keep it up.
You can view my code at the Github link below!
github.com/devguykyle/LessFramewor...
thanks. I'm endlessly fighting against the opposite theory, i'm tired of people who say: "why do you reinvent the wheel?" I don't want a car. I want a damn bike. I don't want to destructure a car to get a bike. I know well how to use javascript, css or html. And I hate jquery. I understand "ajax" is not "jquery". I know what "querySelector" is. I don't need 10 levels of abstraction just to write some text in a div.
Very true and great to see someone say this. Even if a bit harsh. I’m an author of a framework and agree as my framework is an extension vs a abstraction. But I built it for use as an extra to fundamentals vs replacement.
But let’s talk about the elephant in the room, hiring.. recruiters and hiring managers value framework proficiency over fundamentals. Most won’t even look at a resume without react or angular. They won’t even care if you can’t spell javascript if you can speak to react apis or some basic concepts. Sorry but this is “our” fault as a js community. I don’t have answers or a solution but just something to think about.
Your development workflow depends on the project. If you have lots of time and resource, build from scratch. Less time, use a framework. I feel there's an additional layer to this with low code platforms and web app builders such as Budibase or even no code platforms such as Bubble.
Very interesting read, developers need to look at the claims made by Framework promoters. Take React — the constant claim made is that the DOM is slow therefore we need a virtual DOM to speed things up.
However, independent tests conducted by Paul Lewis showed that rendering time was up to 10 times slower in React than in JS. JS also got faster under heavy element load, React got slower ... very slow. Netflix recently dumped React from their frontend and saw a significant increase in speed ... How could having a separate virtual DOM to render and compare to the DOM be faster than merely just changing the DOM ... nonsense.
The other claim made is — we need React to keep data in sync with the DOM ... what? Who has ever had this problem, I haven't! Furthermore because React batches changes, guess what, user data is often not truly in sync.
Lastly there is the claim that development is quicker with frameworks ... is it?Speed of development must be offset against cost, cost in terms of learning these frameworks, the difficulty in debugging them, the time spent trying to override restrictions, and lastly, the cost to the business from their slow loading times and poor performance. Research conducted by Amazon a while back found that just 100ms latency cost 1% in sales. In tests by Paul Lewis, React/Ember/Angular etc ran at 500 - 2000ms latency for initial rendering for a very simple page compared to 50ms for JS.
Would Amazon use React?
Frameworks appear to me to be pyramid selling schemes. False claims made, purported problems that don't exist, solutions offered that actually cause more problems, get everyone locked in, technical debt escalates, we have no choice but to use the framework and the purported solution becomes the only problem.
GitHub spent over 5 years removing JQuery because of technical debt issues, React/Ember/Angular/Vue would have been virtually impossible to remove. Use a framework if you want, but know the costs, nothing is free!
So for ExamPro I don't use javascript frameworks at all just plain javascript. Though now considering puting angular in some parts for richer functionality but I know why I am putting it in there.
My own concern is juniors reading this and thinking you don't need frameworks. When I'm talking to bootcamp grads and juniors I urge them to use frameworks and learn complete ones such as Rails, Angular so they can see all the pieces involved instead of inventing their own bizarre code.
Also, Mislav to be the one removing jquery sounds right. I remember at a conference he just started editing my javascript code removing all the semicolons claiming it was cleaner.
Ideally use and don't use them. Lots of my vanilla-work has been inspired by ideas from frameworks and libraries.
When interviewing, I try to keep the topic on fundamentals, because I assume if those are in place then you can work on all kinds of projects.
Where I get mad is when non-developers (like sales and marketing) are trying to force usage of a certain framework, just so they have a cool buzzword to throw around. I needed to justify more than once why the e-commerce-pages we do don't use Angular/React/$SPA-Library. Spoiler Alert: BECAUSE IT DOESN'T MAKE SENSE FOR A SHOP!
Amen - there's a whole other post to be written about how frameworks become poisonous buzzwords, especially in recruitment.
When do you really need a framework? Hopefully never, but that's actually not the point.
When would you want a framework? When you are working in a larger team (or with multiple teams on the same product) - then a framework will provide a layer of abstraction that allows you to be on the same page without a lot of learning, discussions, etc. - but never let your knowledge of frameworks replace your knowledge of the underlying APIs and processes: that's the point.
I convinced my team to write at least the pages that the user needs to see fast in vanilla JavaScript, though. The rest of the application is currently being rewritten in react (the legacy code we are replacing is in durandal/knockout).
I write things all the time without a "framework." And there are other things I use a Library with. And yet there are large multi person, multi team projects where using Angular, or Polymer or Golang or some other framework is smart. It's more about your willingness and ability to build and choosing smart tools to achieve and then maintain the objective. IMO.
I used to make fun of frameworks until my nightmare during my computer science final year project. I went against all advice to use laravel and other frameworks and being a fluent php javascript coder I decided to hard code a CMS from ground up. Meanwhile my other colleague who had an even more complex project than mine went with laravel and within a week he had completed a prototype. I presented my prototype in the third week and it took me over a month to finish my CMS and it was littered with msny bugs. I paid dearly for my stubbornness and since then I hv come to learn that clients only want a robust and working application. They don't care how u developed it. Also the faster you are with your working deliverables the more u gain a good reputation. I hv now adopted an attitude of learning a language then follow immediately by learning a popular framework of that language for rapid development. It has paid handsome dividends.
I saw this article and it helps me to learn more the basics and documentation syntaxes on MDN more than using the frameworks. It'll help us to build easy but when the debugging comes to development we'll never know what will happen.
Big thumbs up for this! ✌
React is pretty neat. Just gives you access to a declarative programming model which can be functional. Meaning easier to reuse and understand. It's like, hey, I need a bike. So I made some wheels, metal, and a bike. Now I needed to make a car. So I reused the wheels and made a car. See? Pretty simple if you ask me.
Recently I fired off a new react app and then ran tokei on it - 2 MILLION lines of JavaScript - and I haven't written anything yet.
And I'm supposed to teach Bootcamp students how this all works? Can anyone claim they know how 2 million lines of code work?
Anyway, I started fiddling around with web components after watching Vaadin's video, and after a morning's work I had a bunch of components all maintaining state and yakking away with each other - in 274 lines of code, and not a single framework (or library) in sight (demo)
Since ES6 and the demise of Explorer/old-style Edge, I can't help feeling the whole giant front-end frameworks business is in it's final days.
Anyway, great work and excellent points.
p.s. had a quick shufty at your TODO project - looks like fun, I'll see if time permits!
This is why I think I use frameworks...
Because I'm a lazy bastard. Only in a few personal projects I've built things from scratch (backend), And I did that because I was really interested on building those systems the best way I could and because that specific feature was really the core of my project and the one I thought it should not depend on third party software.
When you have deadlines and you are going to forget everything about that project after 12 months. It does not really matter how you build it and how much effort you spent on it. You just need to finish it.
Only when you are your own client you are critical enough to build things from scratch.
I like this reply, as it focuses on where frameworks shine: short term, quick project based work for a client to a deadline.
But then I remember this tweet...
I think all will use framework, knowing basically is a must. it will take how long to work on a project if we work without framework.
in the framework there are many thoughts of people we may miss, maybe a security issue, effective code, bugs, etc.if you do not like the existing framework, create your own framework and enjoy yourself.
Good read with strong sarcasm.
I see many people are against your approach to pass the bitter truth but your message was clear.
As a teacher and a group's moderator, i see many beginners struggle with frameworks.
95% of the times, its because they haven't learnt the basics of a language or the stack (html, css, js, http, database mgt et al) needed to build stuffs.
So they can't really tell if its a framework or a language problem.
I don't really pity them. If you want to become an engineer, there are steps to take.
Skip....and you'll pay the price someday. The benefits of knowing what happens behind the scenes outweighs the cost of not knowing.
Good stuff
Github is hardly a shining example how things should be done. First of all, the simplest things does not work in somewhat recent browsers. Maybe it was better to keep jQuery? After all they still use bootstrap, and deliver 600k of JS-code, 500k of CSS, and 100k for a very simple repository landing page. Seriously, the page could be done in 100k total with mostly pure HTML and a few drops of JS.
Well, I finished refactoring my first major project (that wasn't a static website), and now that I've gone vanilla, it's simpler to maintain, easier to use, and a heck of a lot faster - 76% faster.
Oddly enough, the amount of vanillaJS it needs to work is less overall, as I'm not fighting to make an unnecessary framework function properly anymore.
This is good community because people can say something against mainstream. I agree 100%.
I see this all the time ,
:before
"It is good, i have UI , calendars very easy , copy paste "
:after
"7d for route, 10d to move button, 6m to make form , no support for x..."
HTML/CSS/JS is already constructed to be ultimate simple.
I spot something strange :
the more complicated syntax => the better
the harder = > the better
If you use framework than explore it to the end .
As a beginner, I appreciate this post because I tried to develop my very first website following a Django tutorial. I managed to finish it but I realized I do not understand how the sqlite, the HTML files and the Python code actually worked.
I guess I need to focus more in the basics in order to understand how the frameworks actually work.
This is a huge problem in the web development world. I find myself writing up libraries in javascript, simple things like listening to scroll wheel events, or making a cross browser compatible animation with basic sine trig math. But I have co-workers that are just baffled by the idea and don't understand it, then try to convince me to use libraries. And I backwards engineer those libraries and present to them, do they really want to use a library with a butt load of dependencies and thousands of lines of code vs a 20-30 line script using native javascript functions? Everyone is so willing to learn how frameworks and bundled libraries work when it comes with so many example scripts you can copy and paste, but learning actual javascript and reading API reference docs? Way too much to handle. Programming is puzzle solving, frameworks and libraries are cheat codes. You should only use cheats when you have solved the puzzle already.
Guy A: 12 = 4 x 3
Lady B: 12 = 6+6
Guy C: 12 = 22 + 2*3 + 2
Framework noob : C is definitely simpler,better, and more elegant than B and A because I can clearly see the Quadratic property in there!
😂
I agree with this article and also appreciate the points made in the comments.
When I first started out in my career I used frameworks heavily. I knew there was a lot under the hood that I didnt understand yet. When I became comfortable enough with a variety of frameworks I took a step back and decided to learn how everything actually works. Was kind of a big eye opener for me.
I appreciate how frameworks can make things quick and easy to develop a project, but I personally like to look at what a framework has done well and use the individual components I actually need and create my own libraries. I dont like relying on things that might fade from existence sooner than later and prefer to use the language these frameworks are based on.
David, you seem to be one of too few who really understand the KISS principle, and I salute you for it. You make several valid points in your article, and quite a few more topics pop up in the huge discussion that follows it, so because I haven't been through the whole lot I may be repeating someone - apologies if so.
I don't use frameworks. Never have done. Admittedly, I don't work in a software factory - I tried it a couple of times and it's not for me. What I do best is self-contained front-end projects, and most of these recently have been web apps that are 100% browser based with a small REST server to handle the outside world.
The coding language I use has no need for frameworks - in fact it's an alien concept - but it manages to cope well with anything I throw at it. What's that language? English.
There are few user interfaces or business rules that can't be described clearly in English. If you can't describe a UI in English it's probably too complex for anyone to use. It'll also be too complex to maintain economically, so for me the key starting point is a good understanding of the requirements, expressed in my mother tongue. The other advantage of English is you can speak it out loud with a good chance your listeners will understand. Just try that with JavaScript.
When we encounter a new, strange concept in English we invent a new vocabulary for it. Words like laser or smartphone are instantly understandable. I suppose it's kinda like having library functions except it's seamless.
OK, so if English expresses the problem perfectly why don't we code in English? The answer is partly because the industry is hooked on complexity and isn't looking for simple solutions. If the effort currently going into designing new frameworks were applied to creating variants of English that can express the essence of any website then compile and run it - preferably all in the browser - we'd see a lot more productivity. You commented somewhere that relying on the most talented of coders is not a good thing, and I completely agree. We should be broadening the base of coders, not narrowing it. There's a world shortage of programmers, folks, so why do we go on making it harder and harder to become one?
Soon after Apple launched the Macintosh they also created HyperCard and its English-like HyperTalk programming language. Suddenly, anyone could program a Mac, so we did, and created some amazing stuff. Sadly, since then the whole idea of inclusivity seems to have fallen out of favor but for some of us those times left an indelible impression, one that runs completely counter to the idea that things are only good if they're complicated.
JavaScript is blazingly fast; so much so that it's now a viable system language with which to write higher-level, domain-specific languages that remove the need for most of the bloat we currently have to endure. I've done it for my own needs without being a professional compiler writer, and there are people out there far cleverer than I am. So instead of churning out variations on a tired theme, can we not move on, to a new level where software is really language and language is software?
The problem is not one of structure; it's one of language, which successfully underpins our entire society. It's about time computers were taught to speak OUR language rather than forcing us to train as machines, as we do now.
And that's my strong opinion.
You can ask yourself - will a company hire a "Vue.js/AngularJS/ReactJS Developer" or "JavaScript Developer". One assumes you've mastered the basics and the other entails you already gone pass that and moved onto more things.
Thanks for validating my opinion on this topic!
Somehow, that's not how it seems to work in business world, and I am speaking in a role of job applicant.
Companies seem focused in the number of frameworks one "know" instead of the quality of software one can build.
I've been having some trouble finding good enough jobs because I don't know as many frameworks as companies require me to. On the other hand, I know the languages behind those frameworks, way above average.
And if needed, I don't think that a framework is that hard to understand. Actually it is quite easy after you know the basics, but employers don't seem to get it.
Of course I know a few frameworks that I used to work with, but it can also be a problem because frameworks can sometimes enforce us to write bad code, poorly designed and hard to maintain.
Recently I started to feel the Imposter Syndrome, even though I was the best in all programming classes in college and, I can solve problems that some of my coleagues can't even grasp.
It surely feels reassuring when I hear someone say that the language is the most important and only then the framework.
I must not be completely wrong.
I don't like the sand of my ignorance. It's course and rough and irritating, and it gets everywhere.
Memes aside, I agree with what you're writing (although maybe taking it a bit too far). You shouldn't ditch frameworks altogether, but choose the right one for the job — which might be none at all, something small you put together yourself, or BigAssFrameworkV2 if it fits. I'm a bit allergic to people who start with a framework and then go "now what do I need?"
I really wanted to react (pun intended) to this because it's a very interesting debate... but I'll be honest: there are already a lot of comments and "reading" most of them got me a headache so I'll keep it short:
A good dev should be able to do both.
But anyway, this kind of debate, while "fun", is irrelevant, because one little thing: reality. You make it sound like being a "<whatever framework> developer" is bad or insufficient, but hey, what are most companies looking for? Yup. People with actual experience with <whatever framework>, not "Captain Vanilla Web". And since the time and energy a dev can invest into learning things is limited, learning something that might seem irrelevant when searching for a job is not a viable option for everyone.
I'm not saying you are wrong or even that I disagree (truth be told, I would have been a 100% with you a few years back). Learning the basics is certainly useful and will make any developer "better", but still, given that it's not always an option, being a "framework developer" is actually a good idea too. And frameworks can actually learn useful things to young developers, but I've seen that point covered in others comments so I'll keep my 2 cents about that.
Guess how I feel! 😂
Captain Vanilla Web sounds like a fun comic.
I think recruitment is another mess that needs sorting out, and is probably related. These days I'd just lie on a resume in order to get to the interview stage (where they ask you to invert a binary tree on a whiteboard, then hire you to do something completely unrelated to all of the above).
It's ridiculous how some (or many) of these xxJS frameworks advertise themselves something like "get your SPA up and running in just 5 minutes". Umm sure I guess, but if that means for an actual web app I need to fill a 200 lines config file then I'm out.
I think the point of a framework is really so that we can have our development team on board when it comes to how to write an app. It also makes it easier to integrate newly hired developers on to a project right away. As a developer that has dabbled with many frameworks, I believe you can still learn what goes on under the hood, to some degree, by looking at the concepts that most frameworks have. For example, in back end development, most frameworks use an MVC architecture. Over time, this architecture should help you easily pick up new frameworks, or code your own from scratch. Thing is, we all have deadlines to meet so a framework really helps us to get things moving quickly, knowing we are using well tested tools for the web.
Learn the basics, not someone's abstraction, that's the best line in this article. But if you are near deadline and need to get something complex done quickly, nothing is wrong by learning and using frameworks. Just remember to come back and have a solid understand about the basic. Basic is not always the easiest and take lesser time to learn and understand but is a compulsory process if you want to be a rock star.
As a beginner I'm confused about this whole discussion.
What's wrong with:
I load a framework some libraries .... write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
I mean, I learn the underlying stuff from debugging my shitty code and at the same time get things going by using tools that some (for me) experts made.
Have you heard about dead-code elimination? Tree shaking, which does it, is a standard and is enabled by default in major bundlers like webpack. You'll never include code you never use.
Also, I disagree that you can easily get by with just the standards. Unless you include big polyfills, you will have problems with browser support, hence, you betray your users. If you include polyfills, what's the difference between including a polyfill and a framework? Often they are comparable in size and performance impact on your users. For example, what's the difference between including Custom Elements polyfill and React?
Another great benefit of using a framework is that it helps you have a proper architecture, which is a point you completely missed in the article.
We can go much deeper learn how assabley work . But we need build something great on what our predecessor have done or are nothing different then chimpanzee cus they can't learn new things with communication
Brilliant post! I never wanted to admit it, but I can't stand frameworks. I guess I didn't want to face that fact because I've wasted so much of my life learning them and convincing others that I knew what I was doing.
I'm keen to reboot and go back to the fundamentals. I really like modern JavaScript, but I certainly don't feel the need to have 20k+ Node modules sitting in a folder before I've added a single line of my own code.
Eject Webpack, don't eject Webpack, JSX, dependency conflicts, broken libraries, Git security warnings, IDE plugin squigglies...to hell with it all I say (as well).
Rebooting certainly won't be easy, but at least the rehashed knowledge will stay with me and I won't feel like a fork getting lost in a plate of spaghetti.
Well that's the right emotion!
Me too! The browser is almost a joy to work with when you use a modern API.
Frameworks as Multi-level Marketing... well, now that's a thought...
Good luck!
Just build everything in C, but remember to build your own compiler!
Everyone should know ES6 before they use frameworks and know how to build a webpage without a framework. I used to think like you about this.
Then I realized that predominantly writing JS instead of HTML made me a better developer away from the front end and stopped me from questioning my life as pointless.
I know how it all works from assembly and binary to the headers on http requests, how packets work, sockets and machine learning and frameworks like React will keep a person that likes programming more than document making less likely to contemplate drinking themselves to death...
I'm overreacting (pun intended) a bit, but it is the way things will go, and frameworks are only evil if that is all you know or care to know.
If the dev.to publisher chose the title for this post, then OK; but if you chose it, then shame on you --- it's nothing but clickbait, and sadly, I fell for it.
I've been developing web applications since the beginning, and my experience is that, for anything but a trivial project, a good framework allows you to concentrate on the important problems, because they handle most of the common issues in a simple-to-understand way. I say this having just completed a pair of projects: a (mistaken) requirement for the larger one was no framework allowed; for the smaller one, we chose to learn and use Vue. Guess which has cleaner, more maintainable code?
Yes, of course yes, learn and understand Javascript, HTML, DOM methods and philosophy, and CSS. But don't be afraid to learn how to use other tools to make it easier for those who follow you.
Or should we all still launder our hand-sewn clothes with a washboard and a rock, down at the river bank?
Totally agree. I'd even take it one step further and say that we should be writing web applications in C. All you have to do is read RFC 2616 (tools.ietf.org/html/rfc2616) to get a good idea how to start writing an HTTP server. But it's important that people know how HTTP works and writing the server yourself is the best way. This isn't re-inventing the wheel. This is having an actual understanding of the protocol driving your application. Not to mention a lot of people fail to implement their own relational databases and simply rely on the likes of PostgreSQL, MySQL or worse, a no-SQL solution.
I totally dig the idea that the author and some people in the comment section simply know best.
The bike analogy makes it clear: If i want to have a CD player on the bike I am building, I‘ll add one. If there are already tools available helping me achieving my goal, I’ll be glad to use them.
What a load of self righteous crap.
Yes yes, why use invented, tested, high quality already manufactured wheels perfect for your application when instead you can spend countless hours recreating the same God damn thing the same way purely for the sense of pride and accomplishment.
This is like saying, "don't learn to ride a bike, learn to change a tire. Sure when you're done you still won't know how to ride a bike, but at least you'll have gotten your hands dirty, or something."
Learning to use frameworks in general is a skill. Learning to use a specific framework is a sub set of that skill. Learning to build the underlying code or css of a framework is yet another skill that does not teach you how to use a framework, or how any particular framework works.
Point being, that if you want to build a website today, the best way to go about that is to never learn to build a framework, so long as your project does not require it. Instead learn to use tools appropriate to the task at hand if you do not already know them, and just do it.
There's no fucking point in tightening a bolt with your bare hands out of some kind of misguided sense of nerd machismo, which is all this is.
I know the article is kind of old but I just saw it. I believe the man purpose of a Frame Work to create a disciple dev environment. Also, it makes hiring developers easier. Therefore, I believe the back-end must have a know FW however for FE you can write your own FW and release it to public domain to get feedback. Creating a FW in a vacuum is very bad idea. It will corner you.
The frameworks have become like politics, if you want to keep a friend it is better not to discuss these ..
An example is to see the comments of this post and others like those of Vue vs React.
This is insane.
Yes, you should absolutely learn to build things from scratch. The operative word here is "learn". When you're just starting out as a new developer it may be easier to grasp basic concepts in a structured environment where you're more empowered to create, such as within a framework. Then, learning the basics makes you a much better engineer. But mastery of the basics without framework proficiency would make for a very unproductive employee. Your perspective is strikingly academic, overlooking the fact that programs are tools meant to accomplish an end. If complete knowledge of how a tool works was necessary to use it, it wouldn't be a good tool. Sure frameworks aren't always the best tool for the job - if you aren't building anything significant.
And jQuery can only be deprecated because vanilla js has absorbed jQuery's most useful features. I seriously doubt GitHub is now running on firmware
Should be: "why you shouldn't use a framework until you know how to use the vanilla of what you are frameworking(tm)."
Haha.. great post! As a newbie my first 7 months have been going crazy over how many things there are to learn.. but now I have a clear path of what I need to learn AND actually make things in between learning them! (especially with vanilla). I almost even quit! But now my plan is set in stone and I will not deviate for other sexy languages or frameworks until it is mastered! haha
I see too many self thought devs jump to a FW without knowing why they even need said FM and also so many learn Mongo bc I guess it is easier to teach so most courses are MERN or MEAN... why not SERN or SEAN?
So..
Frameworks BAD, yes. Frameworks GOOD, also yes :D
Peace
I use syntax highlighting but I loathe code completion (just let me type!) I don't know, but I don't fathom how anyone can tolerate code completion as it's so visually annoying. I use Textmate and get a lot of flack from VScode users, but then I can run circles around them with vi because they can't actually remember anything they need to write.
I had a hard time with syntax highlighting initially as well (distracting) but at least I could find a least annoying option I could get used to. It might be an autism thing, and given coders have a higher prevalence of autism than the general population, this could be why some developers avoid these unnecessary bells and whistles. It's not efficient when your flow is broken by a clippy-level distraction.
What's going on that really sucks is all companies seem to have some stupid notion that if you do not have the latest framework on your resume you couldn't possibly know front end coding and be top notch at it. I've been coding for over 30 years with the last 10 spent using the design patterns that provide for very modular object oriented Javascript, so I consider myself an expert at creating readable reusable code using only vanilla Javascript, CSS, and HTML, yet I'm finding it nearly impossible to find work since I am not a React or Angular framework guru. In fact looks like I'm usually being screened out for this deficit of knowledge with these frameworks. It is a sad day when low level knowledge is perceived inadequate compared to having framework knowledge. I've spent time looking at how you code with these frameworks and it makes me nauscious...seems they prefer to extend HTML over writing clean modular Javascript that can dynamically render out HTML for custom user interfaces.
disagree. I can see some of your points but what you describe has not been my experience at all.
Using frameworks has helped me focus on the parts of my app that are different, and helped me grow as a developer too.
Can you point me to some GitHub repo which implements things this way??
I believe that framework lead you to violate your own separation rules and make you mess with dependencies, resulting in a high coupled code, hard to change.
But solution could be programming the logic outside of the framework and then make the framework use your logic.
Instead of getting rid of the framework which takes care about low level details that you don’t want to deal with on daily basis.
Such as security caching asset serving routing
Completely agree.
I love development. So when I started with PHP (my first language was C++), I was really enjoying, and yes, of course I started with fundamentals. I still remember, how I tried to build perfect login system all the time, but then, all of them (around me) started to talk and use frameworks or CMSes. I didn't want too, but I started to build my own. That way, I learned how other frameworks are built, distinguishing good from bad, and more important, it's much easier to start using another framework, new one, if requested from clients.
Nowadays I use Laravel a lot, also because of clients' preferences, but I still like to do things by myself, like having standalone database layer, for different databases, or classes (PDO, MySQli, MongoDb,..) and it's kind of useful specially when I start to develop prototypes for my own projects. I like to use Vue, but as standalone framework, with webpack, so I'm less limited in case I'd like to switch backend from Laravel to ExpressJS or any other framework/language. I did similar with AngularJS, etc.
Also, there is a lot of plugins out there and many time I find a plugin, which had to be costumized so much, that is senseless to use it, so I write my own.
Fundamentals are the key.
Not everyone who uses frameworks is completely clueless about what they are doing. Yes, if you are a beginner who doesn't know the basics, you should not use a framework. But if you already know the basics and how things work, and the wheel doesn't come with a bunch of craps that you don't need, frameworks mean efficiency. You don't need to work hard if you work smart.
You are not justified for calling everyone who uses a framework weak and stupid. After all, we don't know whether they already know the basics or not, nor do we know if they are forced to use it for their job, nor do we know if they didn't have the fortune to be informed that understanding the fundamental is more important.
We should encourage others to learn how to write in vanilla HTML, CSS, and JavaScript, but everyone has their way of doing things, whether they are better or worse. I agree that vanilla HTML, CSS, and JavaScript is a better option, but that's only because I know how to use them. If other people only know how to use a framework, but can get their work done, let them be. We should only encourage them to try the better method, but they are definitely not stupid or weak just because they know less about one method than how much we do.
(I made an account just to post this)
I do use web frameworks.
But the web framework I choose to use is just an implementation detail of the web plug-in.
It's still my code which drives the entire application, the web framework (or any other library or framework for that matter) is just sitting in the back seat.
Or in the trunk :-)
I 100% agree with this. I was working with a startup and we had built our interfaces without a framework. New guy comes in and says we need to use frameworks "because they reduce lines of code". The only problem was not a single framework we could find would do what we had already implemented.
This is so purist but I totally agree! In fact, I have been building websites without a framework (no CSS framework & vanilla javascript only) for 2 years so that I feel lacking the in-depth knowledge in React & Redux because every job description is asking for those now. 😂😂😂
i read somewhere that the most important use of a framework is for maintainance especially in large projects....developers in companies come and go... if your codebase is written without a framework it will be very confusing even for a veteran to undarstand what the former developer wrote...as we all know we can all write code in 5 or 10 or 20 different ways but still have the same result..if we have a framework it will be easier for all to adapt and the speed of development will be better
remember time is gold especially to the investors and business owners..they dont care if youre code is written in framework or not...the most important thing is to deliver on time and make everyone one on the team in the same page
Using frameworks/library is not as bad as this article describes it. I remember when I first started to learn Javascript, I never understood why they use document.selectElementById or selectElementByClassName or QuerySelectorAll or QuerySelector instead of just using $(".element"). jQuery made it easier for me to reason about why I loved Javascript. I was able to deliver something very quickly (that gave my client confidence to rely on me, plus made me feel more comfortable with javascript). If you start developing in a core language at first, you'll suffocate because of the complexity it hold for you as an inexperienced developer).
You willbecome a better developer if you dig deeper into the concept of a framework.
React now a days is doing a very good job in teaching you the core concepts of Javascript.
You will become a good developer when you start learning about the frameworks.
The better advice I would give to a newbie is:
My opinion here is...
Do you want to learn? -> No framework
Do you want to work? -> Framework is required
Using frameworks is great. Not understanding what is happening in the background is not.
You should not reinvent the wheel, but that doesn't mean that you shouldn't study how the wheel was invented and just use it without understanding it.
I don't think it is a matter of speed, when people says that you are reinventing the wheel. Is a matter of quality and security.
Most of the frameworks are opensourced, reviewed, audited and improved by a lot of developers that are probably more experienced than you (or me, or whoever). In fact, using a framework for a long time, reviewing its guts and understanding how it does its magic will really help you a lot to understand edge use cases that would be a nightmare to face just with vanilla and no experience.
Although the author appears to be a raving lunatic, he does make at least one good point. Developers in the Novice and Advanced Beginner stages, referring to the Dreyfus model of skill acquisition, should focus on learning the foundational technologies like JavaScript and SQL instead of trying to learn a framework.
Despite being hard to read, what with the pompous tone and many, many Star Wars metaphors, the message is true enough. If you only learn a framework then you really don't know anything besides a very narrow set of specific use cases across several technologies. It doesn't behoove a novice to learn a JS framework. Instead, they should focus on mastering JavaScript, specifically es2015 and beyond. In the long run, learning how to interact with the DOM, add and remove event listeners, work within the event loop with promises or async/await, are all of greater benefit. Once you understand how the underlying technologies work then you can decide if you want to use a framework and which framework may be applicable to your use case. However, to say that, "ALL frameworks are terrible" is simply ignorant.
What is a framework anyway? Well, if you create websites or web apps you'll often find that you have a certain set of requirements that continue to come up again and again. There are certain components that can be shared across different projects, for example, a navigation bar or pagination list. Having a set of well designed pre-existing components can not only save you a lot of time but greatly improve the user experience.
Should you use a framework? Well, like the answer to many of life's questions, it depends. Each use case is different and I would caution anybody to do their due diligence before making any commitments.
I agree to an extent. But von neumann architecture computers, the internet, an os, a browser and all the things it implements (http, css, DOM) are "frameworks" too: collections of technology that implement things in a way someone thought they should work. Heck, society is a framework for how life is supposed to work.
Up to which point do we want to resist the frameworks?
Disagreed, we need frameworks to evolve and make better bikes. And yes some frameworks only exists because the current language in the marker can't cope with the requirements of today business.
But, yes, I can agree that frameworks bring an extra layer of unnecessary functionality, but if you really understand what you are doing, you can use a framework and native code to get the most of it.
If I have the budget of GitHub, I'll probably go native, but in the real world we need some layer of compromise and allow frameworks to help us build solutions; good solutions.
I do use different frameworks at the enterprise level, and they do bring stability, philosophy, methodology and level of continuity in the code base.
I'm a big fan of few frameworks, and I'll rely on them until they prove to be obsolete rather than expending my coding career trying to build a bike from scratch when I can bring a proving bike model into a new level of form...
I believe the main reason, why we use frameworks - is saving of development time. How you can sell to stakeholders the fact, that your team will spend more time, because you decided to do everything from scratch without frameworks?
I was (trying?) to be humorous. I've been told my sense of humour is a bit hit and miss - so maybe that was a miss. Oh well... guess I'm just adding to the number of angry people on the internet. Sorry about that.
There are pros and cons in using frameworks and they do seem to make your life easier. However, learning the core of everything; although requires a little time, helps in knowing what's going on.
In terms of web, I do believe in 3-4 years frameworks might not be needed. All that abstraction will go away as HTML and JS standardize and add more features and abstract the complexities for a developer. There will be a time when SPAs will be built using only standard HTML, CSS and JS. You won't need to manipulate the DOM using jQuery, you won't need a framework to manage page history, you won't need redux to manage a store, you won't need a rxjs to manage real time communication with the client, you won't need react to bind objects with your HTML elements. That's when this article will seem more valid.
I agree with you, ditch frameworks for the web. At the same time, dev teams kind of build dedicated frameworks for the scope of the projects. Also jQuery is not a framework, readers may get the wrong idea of what a framework is, the GitHub removing jQuery example induces the idea o not using external libraries, witch I disagree. I do not think frameworks are "limiting your creativity", people should realize that when working with a framework you basically write your app inside another app. Your code gets invoked by the framework, you must obey the structure and logic provided by the framework and the features it is offering, with libraries, you call them to simplify your life by using code already available.
Hi, Mr. Wickes. I work at codigofonte.com.br, a Brazilian website about programming and developing. I would like to translate, credit and republish your amazing article. Can I have your permission?
I just read this article and in particular I noticed that you would diminish Spring.................. Holy crap I don't want to see your interpretation of that or work with whatever sorcery of half-baked thing you're doing. Some frameworks are there for very, very good reasons.
This is a troll, right?
Frameworks are good because of many many reasons, just to name a few:
I'm not really sure I ever suggested we go back to banging the rocks together to make a website.
Maybe, as you've heard of Motte & Bailey, you're aware of the naturalistic fallacy? It was put rather nicely in this history of Lisp at the NASA JPL, which is worth a read anyway. I'll quote the bit I like at the end - my emphasis.
I hope I'm clear; I think standard practice in web development is not best practice.
Like what? Seriously. What could be more important to a developer who writes software for the internet than understanding how to parse an HTTP request. Not writing a parser for one, but being able to read them when, say, they appear in the dev tools popup for the browser of your choice. What could be more important than the glue that holds the wonderful world of the web together?
To be honest, this is fairly hyperbolic. Sure, the framework comes with car parts on top of bike parts; however, the mere presence of stuff you don't need is not reason enough to avoid said framework. If all you need is one TINY piece, then sure, ditch the framework. The places I would agree with you more is when facing power, space, or bandwidth constraints. Then the framework is setting the floor for your application/ website/ whatever.
I agree with the basic premise - that people jump to frameworks to accelerate their productivity as a crutch, rather than taking the time to learn the basics. And I believe its effective - hence the popularity. But it's a double-edged sword. If that framework goes out of fashion - many of the things you knew how to do evaporate with that frameworks popularity.
So yea, don't ankle bracelet your effectiveness as a web developer to any one tool or library.
BUT, there is one big problem with this viewpoint. The job market. What do you tell a web developer trying to find work who is only seeing postings for "React Developer" or "Angular Specialist". I think the economy and start-up execs are making these decisions, not the average joe developer. So what does the average joe developer do in a world where they need to get a job, but > 50% of companies want experience with a framework? I think most people simply accept, "if you can't beat em, join em." We all need to eat. What do you recommend?
The thing I get from this article is this: Wanna use a framework? Sure go ahead, BUT make sure you understand the basics of how the web works so you can understand how this framework is really helping you. I recently got interested in web and from an Android developer perspective (native Java and Kotlin) it looks like madness to me. So many Tools so many plugins, so many frameworks, and tbh from an outside perspective, it looks pretty scary. Although I'd say with some time and some deep digging it all makes sense eventually. Yes knowing the building blocks of web dev is important, it helps you understand a bit more what your tools are doing and why some things might work or might not. BUT saying that all frameworks are horrible to me is a bit of a stretch. All those frameworks do at the root is trying to make development faster and as somebody who had to prototype a web app for my job, I'd say VueJS was easy enough and helped a lot. Do I know everything about HTML and JS or CSS ? No. Did I get my product up and running in no time ? Yes. Did I learn a lot in the process? Heck Yeah 🔥. All that to just say that use any framework you want, as long as you either learn something using it or know how it's really helping you.
I get the part of learning basics, which is the most clever thing to do, but frameworks help in getting work organized and following coding standards, in a manner that everything is beautiful and manteinable
oldie but goodie
😂😂😂
I also think it's a generational thing. X and millennial think they know everything without making a single contribution to the society. That's the general theme, and a college degree validates all of their view points in their eyes. It's falling out of popularity according to statistics.
While I get the point of the OP and agree that people should at least know some fundamental basics before being wrapped in a framework (which do have their place of course), everyone grasps and learns things differently of course and some catch on faster than others regardless of career.
I come from an extensive culinary background and within that industry there is a great saying...
'Even Master Chefs can learn something new from their new dishwasher'.
Anyhow, I thought that wisdom would help in some way in this case. 🤘
It's true! And what I'd like master chefs to learn from their juniors is that they don't need their frameworks! I think people who are learning are the best placed to see through the unnecessary cruft and just write a program to do a job - tbh I think some senior developers are the worst at just grabbing the nearest framework they're comfortable with and starting from there.
Great saying - thanks for sharing it!
With respect to David and the time he took to write this post, I find dev.to's clickbait-y titles more and more offensive to my intelligence and a loss of my limited time to reading. I also find these purely opinionated posts not really helpful.
As to the main point, to be honest, the biggest problem I've seen in teams is not the use of libraries and frameworks but engineers who are spending their clients' and their coworkers time and money trying to do exactly that - reinvent the wheel.
You think you're Senior enough and you feel a specific library has too much for what you want? Fine, fork it and customize it.
That been said, Frontend is a world of hypes, and we suffer from that ourselves. First Angular this, then React that, now React Native etc. That's one aspect of Frontend I never liked.
Woow I was thinking about it all my life, I hate when someone ask me 'and you don't use jQuery?' why like develop in JavaScript and don't use JQuery...this people thinks that they knows a lot because jQuery do work for them, if you use jQuery but don't know develop in JavaScript you are not developer, you are a user of libraries...I hate jQuery and such libraries...sorry for my bad english
After 3 days of fiddling with React, I realize you may have a point. It's like building a website with Front Page in 2020, only backwards!
A lot of good points in here. Pity you had to drown out all that in sensational buzzfeed-like garbage.
The negative comments you're getting are due to the 'tone' of your article. Focus on the content and you'll have much more productive conversations.
Of course, if you were trolling, then congrats - a mighty effort!
Different projects come with different constraints. Some projects have delivery date constraints - if you don't use a framework (or a scaffolding/boilerplate), you're not using the right tools for the job. You're bang on that you should not rely on frameworks and that you should definitely understand what's happening underneath. I don't think a single person in the conversation has disagreed with that.
An awesome way of learning something new (web development) is to use jQuery and Bootstrap and see how easy it is to build something. To marvel at the power in your hands to create. If a beginner gets mired down in the details of DOM and JS and HTML and CSS, they're likely to feel discouraged that it takes so much arcane knowledge to do something cool on the web. The key is, and I want to believe this is the core of your post, that's not where they should stop. The next step is to learn how the magic happens. Pundits say you should have good knowledge of one level of abstraction below where you generally work. So it's absolutely fine to use these frameworks and also Wordpress (I sense the collective shudder 😉) to deliver, while understanding their shortcomings, and being prepared to extend or replace them when needed.
A lot of beginners to the industry read these posts - please preach pragmatism rather than peddle hyperbole.
I like the article.
I found myself in a position between testing frameworks, saw that non are usable efficiently in our team so I built our own.
By doing this I have created a team of people that can't handle app errors on their own...
Nice clickbaity title ;-)
I'm going to refer you to the Merriam-Webster dictionary (since 1828, very not framework).
merriam-webster.com/dictionary/red...
merriam-webster.com/dictionary/hyp...
Both words that if they had to be categorized into buckets of 'Framework' or 'Not Framework', would end up in the Framework bucket.
There are all kinds of reasons why frameworks exist, why they get used, and why they will continue to be the way most software is built.
You have some very good points though. Hopefully, your sentiment is received. Understanding basics, abstractions, and when to use the right tool.
All in good fun. Thanks for posting ;-)
Yes yes yes yes yes yes yes.
I'll be showing this to every University graduate who comes to me looking for a job after having "learnt" Bootstrap.
You shouldn't have mentioned ActiveRecord.
Now you summoned this video, and it will DESTROY you:
I am new to development. today's my 2nd day in android.
How should I proceed? I want to be among top 1% developers. Any suggestions on what and what not to do?
I also feel the same about frameworks- That they can make a program super easy but can never make you feel the true taste of programming. The time and effort you spend in creating little things develops your intellect- a thing which frameworks can't do.
One should definitely go for frameworks provided that he knows the logic behind them.
I was thrilled to ditch Bootstrap in favor of Grid and Flexbox. For starters, my HTML code got more readable. But mostly I enjoyed the FREEDOM I got with Grid and Flexbox.
GitHub uses Rails.
Thank you - weird that you're the only one pointing out this inconsistency.
The basics ARE someone's abstraction.
This Article is Gold. I mean in the end of the day its just his opinion anyways. I'm missing the point of all that rage
I agree. I've moved away from Bootstrap/etc to just things like Tailwind CSS. It's still a framework, but it's not anything predefined, it allows me to build my own UI style for my website. Although I still use Flask-like things (like Quart) for backend. (Because I'm not gonna write my own HTTP library with server.)
Такой бред. Автор просто любитель накинуть на вентилятор. А может даже "коуч" какой нибудь.
I've never been insulted in Russian before - I think I like it! 😍😍😍
This is not an insult to the author personally :). This is my attitude to such articles. If you wanted to write "learn not only frameworks, but also the basics", you should have written it that way.
I'm so glad I came across this, I'll make it short and sweet, there are going to be plenty of nerds in the comments over here defending their frameworks but I'm glad someone mentioned the elephant in the room, the people who wrote the languages you're using obviously didn't use frameworks and by coincidence they're writing better code than anyone in the comments here, most people obviously don't understand what's going on behind the hood and think they're programming when they use frameworks, I personally hate them all, i like my code to be optimal and don't trust whoever is writing these frameworks to be as good as me and that's why i didn't move into web development since I would have to use something like react which is so cringe. 100% agree with this, if i could write code with this guy I would.
autocar.js.manifest.nightmare 🤣🤣🤣
Divorced from financial imperatives, frameworks begin to sound much like strains of the Emperor's new clothes...
If you realy mean what you've writen, then you should ditch programming languages and write everything in machine code.
Since any thing else is just a very complex framework at the end of it.
In a way, isn't everything just a very complex framework? You. Me. Reality.
No we are not and also not everything is a framework.
A frameork is only a framework if it's a linear transformation, meaning same input (or inputs) will always result in same output.
But this is not the same with you and me or for any biological system.
That's what good about frameworks, you can rely on them to do what they supposed giving you use them the way they were designed.
Good article even if the title can be misleading.
Frameworks, libraries,...all have their place, PERIOD!
If you choose to ignore that fact, I have my doubts!
I think I heard my heart break. But I needed to know that. Thank you.
Signed up just to say how much I appreciate this MUCH NEEDED perspective.
Yep, the post title is a bit misleading. Strong words like joining a cult.
I loved everything about this post. I'm going to print it out frame it and hang it on my wall. I will make every developer I hire read this and memorize it. Fantastic!
It's a good reminder but very utopic
🎼You may say I'm a dreamer
But I'm not the only one 🎶
Simply, thank you!
Thank you!
Solve your client's problem ... Start with a framework to abstract alot of the implementation, then evolve over time
Ummm... why not solve the problem, then extract a framework if it looks like you've built one.
Which I don't think you will. Unless you're DHH.
Oh yes indeed, what I have learnt is that most problems have been solved - so I need to build on top of that as I do not have the time
Rather than extract and drive my own framework, better to contribute my existing problem approach to another framework that solves a similar problem.
RIGHT on the money. I feel like you reached into my brain and said all the things I've been wanting to scream out loud. Thank you!!!
Foundations first! And even if you, at some point, want to explore other frameworks the basics help you understand the higher level (often opinionated) principles that some frameworks are using.
Coming in a bit aggressive but I kinda agree with what you are trying to convey, especially with today's native javascript capabilities.
guys, jquery is not a framework (it is just a library)
and removing it is probably the worst argument anybody can imagine to prove your main point
Yeah, jQuery was a way to deal with browser inconsistencies at that time, which is very different fom what frameworks are today. People sometimes do refer to jQuery as a framework, though, probably because it has an ecosystem of plugins.
@david Wickes - I totally agree with you. I never learnt a framework. Always wrote bare neat code. I recently moved to a new place and every job I apply for needs me to know all possible frameworks. They are least interested if I know which is the best data structure to solve a problem or which approach will take the least amount of time to execute and deliver an exceptional user experience.
How do you swim against the flow when the entire indutsry is determined to talk to you only if you know the stupid frameworks. A new one arrives every few months to make you feel miserable again!
Doesn't GitHub use Rails? netguru.com/blog/top-10-sites-buil...
Used to be, but they moved on... I don't know the current state of the stack.
theregister.co.uk/2018/08/16/githu...
I've been saying this for a while now. Thank you for writing this post!
I agree, and will learn nodejs without any framework. I know node comes loads with a lot of good stuff out of the box.
I did not like it but I liked it. 😂👍
Great post (Y)
All the love in the world for this article... you nailed it :D
Great article, it made me think a lot about what I'm doing. And for all the people who made negative comments: you don't have any degree of autism, you understood everything correctly.
Yeah well... but do they hire you without knowing a framework?
But yes, learn CSS and then Sass, lerns JS and then React. That's how it works.
Programming languages are all garbage too. Get your stakeholders to fork out for you writing the app in 1s and 0s next time 😂
Stop buying your cars from big automakers, only drive a car if you built it from the ground up in your garage and understand every detail of how modern internal combustion engines work.
I'll just leave this here. The next guy to develop a solid new language will probably be asian, indian, or europian.
Yeah!
Just throw all the frameworks in the bin and reinvent the same wheel everyday.
Clients can wait.
Cherish your moments with the code. That's more important 🤣😂
Ok fine
Best. Response. Ever.
This title is used lure people to read this article, I don't like this.
How about "Why You Shouldn't Use A Web Framework As A Beginner"?
But I totally agree with the points of this post.
Some new ones popping up look promising for speed and simplicity
github.com/Apaezmx/Concorde
Fundamentals and basics is must for more deep understanding. Besides, fundamentals gives your God like power in your subject.
Boring....
LOL, this belongs on Twitter, not dev.to.
You can use the axe if you want; I prefer the chainsaw.
it's tempting the idea to use an 'magic box' where you put some sugar and other magic things and 'booom'!!!! you get everything done, but doesn't imagine where it's come from.
I highly recommend you tweak your title, it's misleading.
Shake my Head...
Clearly, people are not going to avoid frameworks. A middleway could be - use the framework, but develop customize it often, that way you'd be forced to know the things under the hood.
I come from the future and everyone here is a MERN Stack Developer sadly ;___;
I never used Frameworks only libraries. Have a nice day.
Reassuring.
Just get a girlfriend
'Learn the basics, not someone's abstraction ' That hits pretty deep. Hugo is the way to go
Some guy said it'd take 5 years to create a login page wow. Some people just join for a dollar bill, others like what it is that they do.