Earlier this year I wrote:
Why You Shouldn't Use A Web Framework
David Wickes ・ Jul 26 '18
...
For further actions, you may consider blocking this person and/or reporting abuse
I think you've got some really good ideas about a few things, and you've also missed (or not yet come to see) the problems that frameworks solve.
Writing everything from scratch is a great way to learn how things work. Maybe you want to understand what really goes on during the request-response lifecycle, or you want to write raw SQL queries instead of using a heavy ORM. The understanding that you get from doing this is super valuable, and every developer should certainly do it on some level. Also, because you have a deeper understanding of a concept it lets you debug other people's code more easily.
I think there are more and bigger downsides to writing everything from scratch though.
Writing from scratch is reinventing the wheel. Sure, you might come up with a better way to do it (maybe, but I probably won't, and definitely not the first time I do it). But practically every web application has a need to send requests and handle responses, and communicate with a database in some way or another.
Because these tasks are so common, people have written code to do the work for them. They have developed methods of dealing with them. You can think about the tasks as "problems" - they're things that need to get done in order for your application to work.
Using someone else's solution to handle requests and database queries just means that you're going to focus on solving different problems. The ones that your application has specific needs for, whatever that might be.
Learning how to solve these problems is valuable, but once you've built many applications, you may be tired of solving the same problems over and over again. This is why frameworks were developed.
Various frameworks might solve the same problems in different ways, but ultimately they do it so that you don't have to. Yes, you're limited to the choices the framework authors made, but in many cases that's okay because you're focusing on solving other problems. Yes, you have to learn how that framework solves those problems, but that's true every time you use code that you didn't write.
The main advantage I see to frameworks is standardization. this matters on bigger teams. You can hire someone that says "I know django and angular" and they can be productive on your project because they've already been exposed to the patterns that django and angular apps follow. They don't have to learn any new paradigms, they only have to learn your project's specific business logic.
I would also argue that frameworks (generally) scale better - not necessarily in terms of performance, but definitely when talking about code organization and design patterns. Having iterated and developed standards over time helps with this a ton. Working on a gigantic rails project is tough (though manageable), but working on a gigantic custom framework involves much more cognitive overhead, especially early on.
Anyway, no matter what you use, you're going to be solving problems. Which ones do you want to spend your time on?
If I want to correct one idea in this it's the idea that not using a framework means that I'll be reinventing the wheel. A lot of what you say about avoiding the duplication of effort applies to libraries. I like libraries. But why don't I like frameworks?
Use libraries so you're not 'reinventing the wheel' of HTTP message parsing. Maybe you'll use an ORM library to manage your database. Maybe you'll use a thin wrapper over SQL. But if you've abstracted the persistence layer correctly then you'll be able to change your mind depending on your needs and not the capability of the framework.
I agree that's true if you have the need to change things like that later. But in my experience, you have to go incredibly far down the road or have really extreme/specialized needs to not be satisfied with an off-the-shelf solution.
Your TODO-MVP has several good examples of how you can do some of these things with little code. I will posit an alternative - you can save yourself a ton of time by using a framework. You'll end up with more total code (maybe), but you'll also have more time to focus on other things.
You seem to be ignoring the time it can take to determine how a framework wants you to solve a given problem. We've spent considerable time on a CakePHP project trying to find the "right way" to solve a handful of problems which could have been solved with vanilla PHP in an hour.
I shy away from strong opinions because I'm as green as one can be in this field (green... field... mwahahah) but I'm guided by an excellent team and honestly, even when we develop in Rails, there are times when requests ought to be written in SQL, which is not only super educational but also makes (some) things faster, depending on how heavy the task is the gain can be huge. And I think that even using frameworks, knowing what's going on and having a curious/ tinkering mindset can allow you to slim down things a lot of times, avoid adding unnecessary components and such. I think what gipsydave5 says is not all theory. Again, a noob's two cents.
I think the "Vanilla JS" approach shouldn't even use any backend. The way you've set up the projects with the backends feel very reminiscent of 90s stuff where every action you took was sent and the page refreshed (I haven't run the code, so I can't say, but that was from reading the Node.js code). Having a global array storing the files, or even manipulating
localStoragewould be a 100x better way to compare this code to other frameworks.Just some thoughts from glancing at the project.
Yes. That's exactly right. You will be redirected after an action and will see a new page.
So what? What does it miss in terms of the requirements of a todo-style application?
Sounds like you're after a frontend only implementation - this project is explicitly avoiding frontend JS. Can I direct you towards the very worthy vanilla implementations on TodoMVC.
You make it sound like a bad thing...
Yes, it is. Networking eats time. Worse, the user experience is quite annoying on bad and unstable connections. Any smooth UX is doomed for people who is acessing the page from another half of the planet.
But not every site strive for smooth UI experiences for their users, which is ok.
Why are you asserting that you cannot have a "smooth UX" with this approach. What is not smooth about how it works now?
I'll tell you what isn't smooth, downloading megs of javascript and executing it on a low power device.
Because I was using 90xx web.
Page refresh doesn't happen fast enough as background interactions and rendering result as it arrives. This implies SOME logic on a client.
This is specifically true for remote sites. You will have at best speed of light delay before retrieving content. In worst case network fluctuations might give very annoying delay just to get new content. Yes, and you customer will be staring at WHITE page, because browser viewport have nothing to render.
This is why I am so assertive.
If you don't like it, fine - learn your way ;)
Modern browsers smart enough to cache your megs once and then transmit pure json back and forth, reducing overall need for bandwidth. Plus it happens behind the scene, so customer might enjoy that spinner animation or enjoy previously loaded content.
I checked the vanilla js TodoMVC... and I don't like it. Too much code for problems solved hundreds of times. Take for example the template:
And then using string operations the app is replacing values:
So much code... and the more you write the more bugs you may have... this is exactly what we all are trying to avoid - reinventing the wheel again and again.
Tadaaaa !!
Oh, I'm sorry, I misunderstood the scope of the project then.
Well as a pure UX standpoint it's very bad as doing anything will prevent use interaction until the state is synced with the server. It's like the AJAX "spinner apps", although those already used client side JS... So admittedly more modern than this 😜
But as a To-do MVP example it is an area where the was none before - and maybe I can contribute with a Django or a Flask app some time!
I'd love to see a Django / Flask / Python pull request from you into Todo-MVP (I'm not very experienced with Python). Please let me know if I can help in any way!
A thoroughly interested read. It's nice to stand back every now and then and ask "why am I doing it this way?" Usually the answers are terrifying "we've always done it this way" or "it made sense at the time". I'm totally for a proportional solution. Why build a rocket when you're only going to the supermarket?
We haven't always done it this way. We do it this way because we tried the way he's suggesting for years and it was proven hands down to be slower, more expensive, less secure, and infinitely harder to add new head count into...
Citation very much needed here.
Again people keep pretending that David and others are somehow not productive by not using a framework. You keep saying it but the evidence in his eyes (and my own) say otherwise.
I dont use a framework for the current project and i am very productive. I see another team using Spring, and they tie themselves in knots constantly trying to understand the damn thing. Who is productive again?
Writing new code is ALWAYS slower than not writing it.
How many people knows Spring?
How many people knows your solution? Only you? Ten?
If you are writing code for money, you should know it is not about your productivity. It is about productivity of people, who would support your product after you.
Usually frameworks wins due to popularity... and it is their core purpose.
There are bad frameworks.
There are misused applications of a framework.
I guess not your one arbitrary ad hoc example team. I work in a company with thousands of engineers and I've worked on teams as small as two and everything in between. I can cite dozens of ad hoc examples as well, but I'll go ahead and point to any job board and the percentage of jobs that state "We want you to not use a framework to work on this project." Any Fermi estimates of how many you're gonna find? I'll go with Zero. The industry runs on frameworks because they work and work well for 99% of what we do in real life every day. Can I think of some situations where a framework would be a detriment? Yes. Can I think of ways to cherry pick libraries to solve those edge case architectures? Yes. Does that matter for the vast majority of bog standard web apps that the vast majority of us churn out week to week? Hell no. Perfectly good frameworks in the wild today remove boilerplate, provide tons of affordances, have solid communities, and make it easier to focus on your use case specific code. Not to mention being able to hire new headcount that can be up and running on real work with very little onboarding. That's why they're used, as many have stated. The difference between you and me is not that either of us can or can't use frameworks to build applications, it's that one of us is on an esoteric quest an the other has better things to do than fiddle with library curation. If your article said, "I know frameworks are super useful but here's some use cases where you should consider not using them and here's how you'd go about it" you wouldn't be receiving all this flack in the comments. Your "This way or the highway because straw man imaginary problems" is why people are crapping all over it.
Actually I'd just rather not have to learn how to use a new framework every couple of years because that's what happens to all of them. I have better things to do than learn some other person's idea of how a web app should be built when in essence all i really need is
main function, start server, with router, routes mapped to controllers... job done.
The fact you are strawman-ing the argument in terms of being "esoteric" is pretty sad.
Re job ads, find any Go jobs with a framework and come back to me. All the job ads I look at in my area dont specify frameworks at all, shrug. They usually just look for good engineers with some familiarity with particular programming languages.
So you're building static sites? Because you haven't listed Auth, Storage, Caching, Queues, Jobs, Search, Web Sockets, API, templating, DI, or any other number of things that are used quite frequently if not 100% of the time on the apps I'm building every day. Your "Job Done" looks a helluva lot different than my "Job Done". And if that's your use case fine, but don't try to pretend that that's common. That's all choices that I can either take the time to make myself and then explain to dozens or hundreds of other people, or I can just say, "Here's the standard way the framework has chosen to solve for it, learn it once and use it for the next 100 apps you spin up. If you run into an edge case we'll flip out the stock solve for something that works for that." You make some super weird arguments my friend...
Chris, Rails has been around for 12 years. I think the first version I used was 3 something, we're almost at 6. It's essentially the same thing.
I think JS frameworks deserve a bit of your distaste but most server side frameworks don't change that fast.
There would be riots if they did.
All covered by libraries, if and when i need them.
Apart from DI, you dont need libraries for DI (although things like frameworks will trick you into thinking you do)
This is a fair point.
I would still contend the overall tone of it being wasteful/impossible to build non-trivial applications without frameworks is bordering on absurd.
Look at most Go projects, you wont find any frameworks there. How are people making "real" things with Go?
I think you conflated two separate answers by two different people 😬
I think both camps have valid points but I've only seen one or two people talking about the value of frameworks in equalizing the developer experience between different levels of skills or in companies with high turnover.
I don't think you always need a framework but I don't also think you never do.
Yes I was trying to reply to both with the quotes but maybe the UX of this site didnt expect such a nested flamewar ;)
I dont disagree at all. I feel like the main point of this post is that it shouldn't be the default position that you do.
I can hire a mid level developer and outsource the cost of teaching them the parts of my code that are just infrastructure and focus on the actual application exactly because I know that they know where the code is put.
How can I outsource that? By using a framework and make sure they actually know it when interviewing.
Could a good developer be brought up to speed in a frameworkless environment? Sure.
Will it always happen? Nope. I've seen the horror of multi year apps written "just with PHP" (I was hired to rewrite it in Django exactly because nobody knew how it worked and they just kept it there as legacy).
It really depends on the people in this framework less space. You guys are capable developers and made a sensible choice.
As a freelancer I came across small agencies with developers with variable levels of skills with unmaintanable apps using a framework. They would have had unmaintanable apps nonetheless without such framework. The difference is that the new set of eyes (me in that case) was able to just focus on the spaghetti app code, not also the spaghetti infrastructure code.
My personal experience of growing big with a framework is that you ultimately will end up just using it as a layer between your logic and HTML, the more your skills improve.
Something like
I don't see the big difference in the case of a well experienced developer like you are.
My favorite framework is Flask because it just does the boring parts of web apps and can be plugged with functionality pretty easily. Also has a neat concept called blueprints that allows you to put controllers wherever you want
Not if the code you are re-using is not fit for purpose.
Or if it forces you down roads that are not necessary.
Plus almost every framework that has any kind of popularity has books, books written about them. Does that not tell you there is a big cost to using them, at least in terms of understanding them.
True, but at the same time programming languages have books written about them, entire encyclopedias of books for just language semantics. The comparison does not seem entirely on point. Just so you know, I don't necessarily disagree with any of your previous points on the matter at hand.
I guess my point is more the supposed ease of picking up a framework with zero cost is false; some evidence being the huge amount of literature available for them
No one would argue picking up a new programming language is zero cost (there's books for them as you point out) and yet people think they can get tons of functionality for zero cost by using frameworks.
I think you should differentiate opinion and facts, the most reason framework are used is for good common standards that is hard to get as solo developer something like security stuff, I think if you are creating a simple toy app then that is cool as you can kill anytime.
That's your opinion. I happen to know as a fact that (a) I am employed, and (b) I am not using a framework when I build my applications. I do use a number of very nice libraries however.
If you're using a framework to enforce an architecture or code standards then that's a terrible way to avoid talking to your colleagues to reach an agreement on those (mostly bikeshed) issues.
'Security stuff' can usually be handled by either a library, or if you're worried about user data can be outsourced to another identity service.
And, please, although these examples are certainly toys, the idea that anything built without using a framework is a toy is ludicrous. 'Industry standard' and 'best practice' are often just ways of excusing a failure to think for yourself.
"often just ways of excusing a failure to think for yourself"
This is a very good thing!
Otherwise, you have to spend years of studying to do anything of significance. Or if you want to go into an area you haven't studied before, frameworks make it easier to do this.
So yes "think for yourself" but not all the time because you'll get less done.
I would hate to see a world without frameworks because the barrier to programming something useful would be higher and deter people from entering the field.
I feel its the opposite and youre maybe missing the point of the post.
In my view, the barrier to entry of programming looks worse than it is because of frameworks.
Look at the code Dave posted. It's not complicated or hard. The point he is making is the barrier to entry is already low, if you look past the hype of FOTM frameworks and just study the basics.
It's just there is a perception that you cant do something "real" unless there's a framework. Learning frameworks is so much harder than learning the fundamentals.
I agree you can do a lot without a framework. But you can do something more "professional" with a framework faster at least initially. To get to that uncomplicated code probably took years of experience. Most people even if they know the basics write bad code and it takes years to make it good and uncomplicated. A framework at least guides you along until your good enough to do those on your own. The real problem comes when trying to throw away the framework when you don't need it any more.
Abstractions are hard to get right. And an abstraction that has been vetted by a community and implemented in code is hard to beat.
Too right they are! Abstracting away a database - awesome. Abstracting away the underlying bytes of an HTTP response - I'm a fan.
But what does, say, Angular abstract? What is the underlying entity that is abstracted by Ruby on Rails?
In my opinion, they are not abstractions at all. They're tarballs of multiple abstractions, an attempt to generalize certain business requirements. I think you'll get so far with this, but in the end (as you rightly say):
I would love to see a discussion about what frameworks have a good off ramp when you have out grown them. Do they exist? Or what are some techniques to do so? Or which frameworks are the most flexible and let you interchange the pieces?
Now that is a great question. I think you could dip your toes by Googling 'How I migrated Angular to React' to get some idea.
I am not sure of who said that "the idea that anything built without using a framework is a toy is ludicrous". Even if someone did though, saying that "one shouldn't use a framework" is also as ludicrous.
Either has its place for the developer who understands. In at least one project for my clients I don't even have a library. In a few I use libraries and in some more I use frameworks.
They key is understanding the right tools for the job
I have been programming for over a decade. I can whip around the base language very quickly.
The requirement of a framework is actually a huge barrier for me because you have to know another language on top that obscures what is happening below. It also reduces performance, and creates a lot of abstract things to keep in mind.
I think learning frameworks first, language second is incredibly dangerous. I have known people who took that route and they've often abandoned projects because they didn't know how to do the difficult thing in the base language.
I have the opposite problem. Throw me some code written in vanilla js/php, and i can quickly grasp it and hack on it. Throw an unknown framework in the mix and i am completely lost due to all the extra abstractions.
Would like to know the list of libraries you use....Thanks!
Sure! I was using the lib HTTP4K - programming in Kotlin.
"why shouldn't use a framework" pretty much tags frameworks as bad news. As a developer who can code with or without a framework, I would say that it depends on what you are coding. Some of the frameworks are unnecessarily cumbersome, yes, but that in itself is not a valid basis for an argument.
For instance, if you to code a clone of a system like Yelp, a framework like Laravel in PHP would 100% be better off than coding it from scratch if you have limited a budget! A biography page shouldn't need an angular scafolding when vanilla Js or jQuery should suffice!
You can move 20 tons in a shot with a 18-wheeler, or you can make about 6-8 trips with an average family truck for the same loads.
Or, dare I suggest, just some HTML?
If just HTML would be enough, people would not come up with css, images, animations.
HTML is okay for info, but it sucks in representation. Fun fact, that any attempt to replace html with anything more suitable just failed (hello flash).
Yeah, you can use some HTML. But such pages have little chance to stand out. For a some weird reason, customers like then their pages look and feel nice.
I think what he means is that you can build your blog with nothing more than your templated HTML - no frontend JS needed. You still can make your page look and feel nice, but without resorting to doing everything on the client.
Exactly - two thumbs up!
You can, yes. Moreover, it makes more sense in serverless world to a certain degree.
One might even have a successful commercial html-only project. But I am confident enough to claim it as an exception rather than a rule.
You get the gist
You always use a framework when coding. The difference is whether it's written by you or someone else.
I'd really like to understand what you think a framework is.
Let's just say "all the supporting code and how they're tied together".
So libraries I'm guessing
So an 'architecture' in the loosest possible sense.
All code has libraries and an architecture. Sure, I'll buy that.
But not all code uses a framework. A framework is when somebody else other than me has chosen the libraries and the architecture for my project and is preventing me from changing them.
All libraries and architectures are chosen by someone. I'd just rather that someone was me and my team rather than the collected generalizations and compromises that make up a 'framework'.
This is exactly the reason I am not supporting "no framework" idea. You want to make archetectual decisions. Good for you. However I don't want to be that dude, who will be forced to maintain your product after you done playing the architect role.
Or, shall I expect your commitment for next 10 years or more? Should I expect great support for your solution going forward? Should I expect more and more solved technicalities? Will you give me a good documentation?
While I agree that any given framework might be too heavy for certain cases, they save time whenever anyone like it or not. It is too bad, that js offers too many half backed frameworkd and people choose to write their own.
Why franeworks any a necessity? Because every developer faces same technical challenges: DOM manipulation, templatization, communication via protocol, security, auth/authz, localization, event consumption....
Every project is different, yet some technicalities are the same. It is very natural to have shared common high-quality code to solve above with writing less client code. Which means yes - given up some architecture decisions to existing solutions.
But is that really that bad? Shouldn't you worried about solving for your specific client rather worrying for entire developer community? Framework solves for tech stuff, but it does solve for customer domain? What's the reason to increase backlog for yourself and people after you?
DOM manipulation? Use a library
Templates? Use a library
Communicate by a protocol (say HTTP)? Use a library
Security?
Auth?
Localization?
'Event Consumption'?
Absolutely. Which is why I solve the specific problems of a client rather than installing the generalized website solution software (which solves problems that my client may not have) and then spending the rest of my life hacking around to make it fit the specification.
That is a real issue; heavily customized 'framework' solutions which are neither fowl nor fish. Developers have adapted the framework so heavily to fit requirements that it's barely recognisable, giving you none of the benefits of the framework but none of the upsides. I think I cover this in my other article.
Lib-way works for small to mid sites, where functionality is segregated and don't overlap, sorry.
There is no one-size-fits all and pushing for a "no framework" feels like it.
Use lib X. Use lib Y. Use lib A.
Add glue-code.
After first year, add lib B and lib C
Oh, C depends on another version of A.
Add glue-code.
Oh, now these libs should be mobile friendly...
I would expect framework to guarantee consistency with API and contracts cross-functionality wise. It is expected to minimize glue and boilerplate code.
In the ideal world.
I certainly understand the frustration then new intent and requirement doesn't fit with old framework. Sh!t happens, time to migrate to more suitable tool.
... or change roles and go to java, .net, c# whatever. Those guys stuck with a framework for decades :)
You know that it's possible to refactor and change code right?
If you dont like the way Dave has architected the code (which btw, isn't anywhere near as big as you probably think it is for most projects) then you can just refactor it.
If you dont like how a framework has architected things, well good luck.
I am sorry, but do you understand that refactoring is not supposed to change architecture of an app? At least I call it re-work / re-write / re-fit. It usually insane amount of work for mid-sized codebase.
If architecture doesn't fit and it is too expensive to change it, I would discard it. No hard feelings.
It is not a question of "like" or "not like". Are we professionals or what? If framework doesn't fit - replace it. Customers doesn't care what exactly are you using.
Says who? Refactoring is about re-expressing code without changing behaviour. That's all it is
You only believe this because you are indoctrinated in framework-land where everything feels big and enterprise I suspect.
If you have sufficient tooling and tests you can easily rearchitect how a system is done in a codebase that has no frameworks. Source: Me.
o_O
Design != architecture
Also, refactoring supposed to improve one and only one quality only - maintainability.
Please continue reading and understanding Martin Fowler. I would also recommend to check out Uncle Bob's thoughts on it.
I have now decided that you're trolling me to ensure that I don't get any work done today.
But in case you're not, or anyone wants to take you seriously:
martinfowler.com/bliki/DefinitionO...
and
martinfowler.com/bliki/Refactoring...
If you so like Mr. Fowler, it will be good for anyone to understand his take on architecture:
kylecordes.com/2015/fowler-softwar...
You cannot easily do it. Architecture is too big of change that also invalidates good percent of your test base (integration, system, etc). I am not sure if we are on the same page or not, but I treat architecture as fundamental decisions written in code which defines core properties of a given system. You can change it, but certainly NOT during refactoring. Mostly due to addiction of new properties and removal of others. Switching stacks from java to serverless lamda javascript is an example of architectural decision. Show me code transformation steps from one to another.
Another example is switching MVC to messaging.
Design is more flexible in that sense. Please don't mix system architecture and system design.
If you have tests, you are the king. But I would expect any good mature framework to have more stability than your codebase, btw I have seen your acceptance test.
Don't put me in single camp ;) I am not a framework evangelist nor a binary simpleton.
Ill paraphrase Uncle Bob, "frameworks should be a plug-in and not the basis of an architecture".. if the first thing you do when discussing your architecture is pick the framework, you're already wrong. You also are "buying in" to said framework which could theoretically change at any time. You are at the mercy of the author(s). IMO, and how I design systems, architectures are just a tool that is lovely coupled to the core business logic.
While this is true and I agree, that choosing a framework should not be the first thing to do when starting a project, we have frameworks for a reason. You can't develop everything from scratch and it's not so easy to do some changes even if we are speaking about purely cosmetic changes like switching from bootstrap to material design. It's just like when building machines - their parts are carefully designed to be transportable... which in turn seems to depend how wide a horse's rear end is...
astrodigital.org/space/stshorse.html
Interesting stuff.
How have frameworks managed to kill businesses? was it due to having to refactor the code sitting under them to a new version?
Let me tell you my story.
I work for an online school and 3 attempts were made to rewrite the entire learning management system into symfony, codeigniter, and then laravel. The LMS was written in old school PHP 3 code that had just barely made it's way into 5.2 compatibility. The structure of the site was a loose set of scripts with a few global libraries and no object oriented stuff, relied on input globals, etc.
The codeigniter attempt had 2 super huge controllers but implemented at least 75% of the functionality before a wall was hit with that approach.
The laravel attempt only got 15% of the way there before the programmer gave up.
I got my job maintaining this legacy application and throughout the course of 1 year, refactored it to be compatible with 7.2 and beyond. Only until recently has it seen any object oriented code, which was just an experiment.
The other programmers sold the company on a rewrite by touting the benefits of these frameworks. Last time, the owner was told that we Laravel was great because it could do caching, easy APIs, database abstraction, and had an admin panel addon that would make redoing the backend easy.
None of this stuff materialized and the refactored LMS is running on a 1GB mem amazon instance without caching because it's written more like a C program and has the performance to match.
The laravel backend plugin was horribly buggy and crashy; but that might have been because we had a crap programmer. 100% of the laravel code was written off as a loss, because none of it could be used in the old system - it was too dependent on laravel.
I do wonder if the intense layering of abstractions and the scattering of tiny objects that have maybe 1 or two methods, adding up to 1000's of objects, is even comprehendable to the programmers trying to follow that ideologies.
I tried asking a SOLID devotee writing some popular upcoming forum software how he managed to trace execution in his program and he could not provide me with an answer..
Your node.js implementation doesn't sanitize static file path, allowing an attacker to load any file from disk. Framework would have likely prevented that :)
That said, I also prefer to plug in individual libraries into my own architecture rather than hack around some framework's quirks or, God forbid, try to glue several of them together. Especially in the node ecosystem, which lacks real batteries included mega-frameworks a-la .NET.
Your approach in that todomvc code of doing everything from scratch is going a bit too far for my taste, though.
Totally! It's definitely going too far. I'd probably add in a routing library too.
I'd love to see a pull request to add your Node implementation if you're up for it!
Sorry, it's not worth fixing IMO.
A framework that parses incoming requests and calls your code is exactly the right choice for the problem of responding to web requests at multiple endpoints. Not for every problem, but for this one, yes.
Thoughts
I think you may be missing a huge factor as well. A huge reason to even use a framework to begin with is standards. Everyone knows how to interact with the code and bringing on new employees is as simple as advertising the framework. They will be able to integrate nicely with it very quickly if they are familiar with it. If they are not familiar with but know the language it might take 3 months or so on a large codebase, in my experience.
If you are building your own applications from scratch and you expect your employer to higher people to come in and learn an entirely new application that was built from scratch with no prior knowledge or being able to work with it then you are going to cost your employers thousands if not tens of thousands of dollars when you leave.
You might not see it now because everyone knows the codebase but try to get some new people into it who may have never coded an application before. You're going to make their life hell and they are going to ask 1000 questions they don't need to which also takes away time, money and resources from other parts of the company. Again, talking from experience here. My first company I worked for did this and it was hell but she (the lead dev) thought nothing of it because she was the one who built it.
Bad Premise
Your entire argument is based off of the premise that a framework calling your code is inherently bad. You say your code calling the library is good but the framework calling your code is bad but you have no supporting argument to back that up? Why is a framework calling your code bad?
If you say it's because it makes you too restricted to how the framework does things then why is that bad? If you say it's because of the structure of the code or the methods you use is forced on you then why is that bad?
New Features
Also when you use a framework you have the benefit of tens or hundreds (sometimes thousands) of contributors working around the clock just for you and your software. New features? Sure! just check the roadmap and when new features will be added to your application.
Documentation
When coming to a new framework you have the advantage of having 100's of pages of documentation to come through. Masonite has ~550 pages. This allows new developers to reference the docs instead of ask all those questions. Noone needs to fire off a slack message "how do you set a session again? I can't figure it out".
They can:
There is much more to using a framework than being forced to code a certain way.
Hey Joseph - thanks for your detailed response, and for sharing your experiences. This is great. My experiences obviously differ to yours, but that's being human I guess.
Bad Premise
Why is having my code called by the framework 'bad'? Fair question, and I don't really address it. In a sense, isn't all code being 'called' from something else? Called by a compiler, called by an interpreter... called by the operating system. Something else is providing the environment for what I'm writing.
I guess my objection to the inversion of control I experience with a framework usually comes down to two things: it's hard to debug when it goes wrong, and it's hard to redesign it to fit your needs. It's harder to understand what happens when your code gets called as it's obeying rules that you're not aware of or in control of.
New Features
But do I need any of them? What are the benefits to me? I've seen developers add these features to projects when they're not needed... or worse, when they almost fit a requirement. They will use them, depend on them, develop around them until the codebase is distorted in their favour. And then, ultimately, be let down with them as the final feature never gets implemented.
Documentation
I'm not sure this is an argument in favour of frameworks, or of documentation. Good libraries have good documentation too.
it's not the library documentation I am talking about but how your application interacts with them. There is no documentation on "how to create sessions with David Wickes application that communicates with the B2C part" or "how to send a quick email with David Wickes application that communicates with the warehouse."
out of curiosity, how long have you been in industry? Not being rude but curious. Your experiences are your own and you are entitled to them and I respect them. I am not saying my experience overtrumps your experiences but as someone who has been in industry and have ran some big projects with $60M+ on the line for quite a while I can tell you that requirements always change and if you don't need that ability to send an email that was just added to the new release of XX framework a few months ago, when your boss come back and you and says:
"oh remember that wharehouse app you made to manage all those products? i need you to add a completely unexpected requirement of sending that email directly to shipping with all item details and who the shipment is going to"
Framework to the rescue because a developer coded that for you and you can easily send an email and package it up in a nice "mailable" class you can pass around all parts of your code.
But isn't that why you have framework documentation, Stack Overflow answers, Slack channels, community articles, online videos you can reference to help you debug that is not available to you if you build something from scratch?
I'll give this one to you. Frameworks generally can be manipulated in the sense of file structure but typically has only 1-3 way to do things like:
So yes frameworks make you do certain tasks a certain way but that's not a strong argument of why it is bad imo.
Maybe it is to you but having freedom to code the way you want to code isn't a perfect solution, it has significant drawbacks and maybe that's the point I am making is that this sounds good but it has a lot of drawbacks when you find the can you kicked down the road. I am genuinly curious on your opinion this time next year or 2 years from now or even when you switch employers.
I will be following up with you then 😈
Dito!
Frameworks are a result of an incredibly fast and competitive industry, with a lot of passionate people finding new ways of solving problems and sharing them. I like to see no-framework talk, but I think it's so important to know how much frameworks help when building dynamic web apps. Your server-only approach would probably be unaccepted nowadays, if the goal is to have a fast app with rich and dynamic user experience.
Things today are tough for sure. New developers have so much in front of them and jumping to a framework before being comfortable with basic web principles is a terrible approach. But things don't have to be that complicated. Getting started with a framework and seeing which problems it solves does not take a long time at all. Also, there are less opinionated frameworks (React!) that don't enforce architecture, besides the usual component structure that most frameworks nowadays adopted.
Yes. The industry of creating frameworks to polish your CV, the cynic in me would say.
Ah, but you know what clients really like? A working app in front of users - and quickly. One without the bells and whistles, for sure. But working, being used and making money.
I remember when React first landed, and the voices went up from the JavaScript community asking 'where is the framework?' 'Where do I download Flux?' they were all saying. Of course, you couldn't - Flux was just the way (some) Facebook devs were using React. Then (after a bit chaos) Dan Abramov branded a CQRS architecture 'Redux' and now we're lucky to have the hundreds of frameworks built on top of React.
Edit: I just realised, that you assume, that every developer you will meet is a highly capable, very well educated person (probably with decades of experience) who spends hours and hours thinking about every single line of code he/she writes. Meanwhile in the real world we have people with nearly zero experience, who try to achieve results after checking the first tutorial (probably even some portion of it) they find on stackoverflow or google. And this is OK, because most probably the end user need something to get their job done and they need it now, not a decade later.
I carefully read the article and didn't find any real argument against using frameworks. Yes I dismiss all your arguments especially the only real one: that we don't need them, but in fact they save lot of time and this is basically the most precious thing we have in our life. You can do something small like a To-Do list in any language, but when you keep adding more and more featured you will end up writing tons of code and solving problems, that others did before you. Most probably you will need other people to help you. The bigger your codebase is, the harder it will be for them to figure out how it works. This is why framework popularity matters - it's easier to find someone to help you.
Great article. I like the advice that you give here, and I am fully on board with you regarding JavaScript frameworks. Some frameworks are good and mostly necessary (ie., ASP.Net MVC, etc.) but these are backed by huge corporations and have support, tons of documentation, and will be around for quite some time.
I think that if someone knows how to write a web application from scratch, using only libraries, then they can easily pick up and learn a new web framework. (Well, I guess 'easily' is relative. Some of those frameworks have quite a learning curve, even for an experienced coder).
However, if a young developer learns web development using a framework, and then moves on to a new project where that framework isn't in use, then he/she needs to either learn a new framework, or actually learn how to code without relying on a framework. How to manage state? How to manage history? How to manage binding? Frameworks have implemented a lot of the boilerplate code to do these things, but they all do them differently.
However, one of my biggest hangups about web frameworks is their transient nature. What happens to that big enterprise project five or ten years from now when FrameworkX has gone out of style and no one knows it or wants to work on it anymore?
How many devs are out there struggling to maintain a big Angular.js application written five or more years ago, which was too big and complicated to convert when version 2 came out, and besides there was no compelling business case for management to allow for a conversion effort?
Now the rest of the world has moved on to the completely rewritten, new and improved Angular, and the company has to try to find developers willing to work on an old, out-of-date framework that no one wants to work on. I suppose this isn't so different from other frameworks of the past, but at least they had a longer shelf life (e.g., ASP WebForms).
And how does one find decent documentation when the frameworks change so fast the documentation can't keep up?
And please don't get me started on the thousands of dependencies these frameworks rely on. It seems to me like a house of cards ready to fall.
I get the arguments about standardization, etc. But that argument only holds so much water. The standards change so fast that the word barely has any meaning.
You can also do both, use server side templating and use JS to augment the website and cache.
Basically what dev.to is doing and being pretty fast at it too.
There's no single way to build a website anymore and that's great for everyone, yeah the complexity of frontend programming is escalating, but there is a lot of innovation going on at the same time
I'd just like to say @joeyhub and @theelectricdave that these are some quality comments that I've really enjoyed reading. Thanks!
Especially
I mean, this is brilliantly put.
I saw Ward Cunningham tweet this:
I feel the same way about frameworks and DSLs - they're designed to negate my generic programming skills and mentality.
You're welcome. I'm glad someone gets it. I've been afraid to even speak my mind on this topic because there is so much freaking resistance to not following php-fig dogma and object oriented fetishism.. It was reading joey's comments and noticing that he didn't get mauled that made me join.
This is the thing that sticks to me the most. Having had developed my own framework, i have a yardstick to measure other frameworks by, and they pretty much all fail to stack up to some of the pretty basic function libraries i've put together, in terms of how difficult the syntax is to type, how fast they perform, etc.
( the only framework i found respect for in this regard is the fat free framework )
I always come back wondering who finds these solutions acceptable.
A simple database call in laravel or symfony is about 3 times more complex than i'd like.
Perhaps these frameworks provide acceptable solutions for people who do not know better and are just average programmers. In this case, it might be better for them to be using someone else's solution.
With the code camps churning out hundreds of new programmers per day, i think the framework popularity will only continue over time. This may result in another phase of poorly written, unmaintainable php code - except this time, you also get to figure out what automagic is happening when you try to debug that mess after the original programmer hit a wall and walked away from / failed to complete the project..
Nice post Dave.
I do feel strongly that a lot of developers would be better served looking at this kind of code and learning the fundamentals rather than immediately diving into frameworks.
Hopefully this will prove to be a great resource for many
In my opinion one is not a developer if they don't understand the fundamentals. Frameworks and library solve different kind of problems but it depends on the project at hand. Saying that frameworks are just bad is an oversimplification, perharps a lack of understanding to some degree
Hello David!
Your 2 posts are actually what made me want to join the community to give my 2 cents to this. First and foremost: I do agree with everything you said and I did not take the original post in the negative way in which some of the other users did.
At work I have been dealing with the issues of having framework-less applications(In PHP of all things, which I like, but there are valid reasons why people disliked PHP so heavily and I see them on all of these applications) that would just not scale well in terms of adding new features. This has prompted me and my lead developer to discuss different ways in which we could do rewrites or structure the code for future implementations. At one point another developer brought upon us the idea of using some of the top PHP frameworks in the market, such as Laravel, CodeIgniter or Symphony as well as the all glorious repertoire of JavaScript front-end libraries. While I have absolutely nothing against these technologies, I chose not to. Being the head of my department, I know that such decisions could ultimately bring a lot of issues with developer time.
I opted for more native approaches while focusing on good practices that have been established by the community for a lot of time and building reusable components that would apply to virtually all of the other applications that we have. From authentication and authorization to database management as well as front-end server side rendering with the occasional AJAX magic.
The result has been good thus far, and while I understand the concept of "well you are practically building a framework" I also believe that doing things this way would keep developers on their sharpest by making them have a complete understanding on how the code works. I can either have them read and understand how Laravel's Eloquent ORM handles transactions etc, or I can have them generate proper PDO code from best practices to understand how everything underneath works. Countless times I have met Rails(admittedly newbie Rails devs, not the wizards that the community has and I meant that with the upmost level of respect and admiration) not understand what the underlying SQL is being used by their ActiveRecord ORM, the same I can say for Laravel developers(again on the newbie side) and many others.
Front-end I can understand, state management is a tedious thing to do for larger applications using Vanilla JS, this, however, does not make it undo-able, and for most intranet based applications we can do just fine with server side rendered pages. Note that I am not too concerned with heavyweight JS frameworks, I understand that low powered devices are a thing, but most if not all of our applications are used on standard desktop computers.
The one rule to the exception in my book thus far is Spring, I feel like with Spring I am just writing Java code and using an inversion of control container rather than a full featured framework that will generate things over a set of CLI commands. I know it is considered a framework, but it just feels like natural Java with a library to me.
Either way, cheers! Thanks for the great post! I will be looking for your other posts as well :D
Heartwarming read! Thanks and Happy New Year!
Thanks for this. Absolutely brilliant. I have always been against frameworks (apart from .NET) generally, although I recognise they have their place occasionally, and after another argument with a frameworker I decided to see if I was alone in this view and found your article. It pretty much says it like I would. Thanks again.
Much agreement here. What about svg? I see it as loading resources from many places depending on context. Hence all page formation is dynamic but atomically static.
Most frameworks stand directly in the way. E.g bootstrap can't do ajax well or makes it near impossible. More elsewhere...
Love the idea! I have rolled my own as well (github.com/crh3675/nodeii). The one thing that I have found with "roll-your-own", even with simple projects is that if the developer is not disciplined enough to write the appropriate documentation in README files or comment their code, then all others are likely to fail trying to work with their code.
I wish that everyone had the same tenacity, discipline and confidence to build their own custom solutions but the truth is, they just don't teach most of what we do in colleges. What we provide with our vast experience is exactly that, we are "hammer and nails" and modern developers are "roofing tool 3000".
In the hopes of trying to make things easier, smart guys like us have worked to provide our implementations of practices and better tooling - we have contributed to the problem; a simple psychological enabling scenario.
The smarter that 10% of us get, the dumber and lazier 90% of others become because we gave them all the answers :-)
Software Development has become so subjective nowadays where every developer that manages to bolt together all of the complex libraries that someone smarter than us created are now experts in their trade.
There is no one-way to anything anymore with software, there is no manual to build the most efficient website or application. It takes experience to "do the right thing" and if a framework is a colossal learning curve for a small team, then it is a bad move.
I appreciate your experience and dedication, thanks for sharing!
A lot to take in. Valid points from both sides. Thanks Dave
As several have stated, frameworks do provide a standard. They try to standardize the architecture and basic how-to's.
Pros:
-- restricts style
-- provides libraries
-- developers with experience 'should' be able to get up to speed quickly
Cons:
-- restricts style
-- adds a lot of unused libraries
-- developers still write 'logical mazes'
I do love Vanilla JS, jQuery, and can code in Angular, AngularJS, and Vue. What I'm finding is ... I still fall back on the vanilla and jQuery when it makes sense. Yeah it's good to not re-invent the wheel ... except a lot of wheels take turns you may not need.
So, what libraries would you typically use for most of your projects?
I am a total newbie at this. Having developed a couple of websites, and a web-app in plain PHP+SQL, I just learned that "frameworks" exist - literally days ago. Started reading on the topic I arrived here - and I am relieved. I don't have to learn all this stuff!
However, I have not yet used any library as well - what would be a good resource to learn about them? Specifically for PHP?
First up - I am not a PHP developer, I know very little about PHP.
But.
Well done! You've built an app, with a database, and you didn't need a framework. Kudos!
However, I think you're already using what I'd call a 'library': the PHP extensions that are used to access the database are just like libraries - bits of code that aren't used as standard, but can be easily brought in. It sounds like they work just like what I'd think of as a 'standard library' in another language.
So that's one hurdle! I guess the next one will be to get hold of 'external libraries' - from what (very little) I've read, I think that Composer might be a good place to start.
Good luck!
I shall keep it short...at a certain level of complexity, frameworks become very valuable. Having a common system of ideas to express ideas with your team that lets you avoid thinking about smaller details is a miracle once a project reaches a certain size. It's kind of like micro-optimizations...if I am sitting at my keyboard worrying about how many CPU cycles a method will consume with absolutely no context or profiling data indicating that I have a problem, I have gone down a rabbit hole and I need to come up for air.
And then there's maintenance...I can write some pretty clever and efficient code, but turns out some of my coworkers disagree about that statement ¯_(ツ)_/¯
What i have done is build my own basic framework, which i use as basis for my projects, but it is really tiny, so only has needed things that i always use in my projects, then if i need some other things ill write it then and there, and add it to my collection of additions, so i can quickly grab it and add it if needed, this simplifies my projects, keeps the code tight, while still being reuseable in other projects, for example, if im building a site for a customer, then throwing in the blog unit, instead of rewriting, and then its added, but i still know my framework down to the core, since i build it from ground up. so, frameworks are useful, but available frameworks, tend to be extremely bloated, since they have to cater to so many whatif situations
An application that has to reload the entire page just to mark a record as ticked/complete isn't going to cut it out there in user land, I'm afraid. Some people can over-rely on frameworks but unless you want to develop for people still using Netscape Navigator, the world has moved on and frameworks are a necessary evil. If the W3C could pull its finger out and come up with a combobox autocomplete specification and a decent data-grid, then frameworks wouldn't have to be so nasty.
Hi everyone. Really glad that this piece is inspiring so much enthusiastic debate. Could we all please try and keep it friendly and civil in the spirit of Dev.to
That TODO app looks really cool :) I have a similar app I want to build. Do you think it would be possible for me to somehow re-use some of the awesome patterns you've built?
Yes of course you can use these ideas. Don't do anything evil and have fun!
Note to self: add license to project.
Very opinionated, biased and low quality of post.
You didn't answer well "Why let them call you" is bad ? It's one of the most powerful idea in software engineering.
What's the purpose of the demo's source code ? To demonstrate you can re-invent the wheel ?
And you put your
websiteon a technical post like this, for marketing inside a technical article ?This is total crap and non-sense. I hope dev team should remove this post.
It's certainly an opinion, but 'total crap'???
There's no reason to attack anyone here, this community is meant to be an open place for developers, a place to expose your opinion (with respect, a LOT of respect).
You might disagree with David, but this sort of comment is destructive and must be avoided.
Treat this as my opinion. It's the kind of posts i don't want to see on
dev.to, yours might be different.That's a form of censure, not an opinion.
It's completely understandable that you disagree with David, but expecting that he doesn't publish his ideas is not and is against dev.to code of conduct:
Thanks for reminding.
The
crappoint is not about technical viewpoint, it's about the intention on marketing side on a purely technical article.Where is the marketing? He's not trying to sell anything
I believe there's been some misunderstanding here.
The problem is not that you disagree with him, or even think that he's doing something bad to the community (which he isn't).
The thing is that, if he had done something wrong or broken some rule, the ideal course of action would be to a) report abuse; or b) explain what rule is being broken and attempt to mend the problem.
Attacking his ideas and opinions is not the way to achieve a respectful and diverse community
I suggest you try this report and see how far it gets you. Just because you dont agree with a post does not mean it is "total crap" and should be removed.
It's total crap to me, does it make any sense ?
Try and use your imagination.
Imagine a developer who has lived in the world of frameworks, and lived in the world of building systems from libraries.
Now imagine they weigh up the pros and cons of both and have decided that they prefer not to use frameworks.
Those are NOT devs in the first place!
A developer SHOULD understand the implication at the "vanilla", library and framework level in the first place.
If you took most JAVA, C, C#, PHP,...developers today and told them to code in machine language, they would be like sheep watching tv.
There is a reason we have higher programming languages. Likewise, there are reasons we have libraries. See where am going with this?