I wrote my first web app with Django. And then Rails. These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware).
Now, if I wanted to, I could build my own application without Django or Rails, as long as I had something to accept incoming HTTP requests, make responses, and a library to make DB calls.
But I wouldn't have gotten to this point had I not learned Django and Rails first.
I think using a framework turns many "unknown unknowns" into "known unknowns".
I can read my framework's documentation and learn it has built in logging, so logging is something I need to think about when building a web app. It lets you filter sensitive data from logs, so that's something I need to think about.
This is why I was building a type of application I didn't build before, I would look for a framework I could use, or something like it.
I'd use go kit for building a microservice for example. I don't get many of the concepts involved with building a microservice (circuit breakers, service discovery, etc) and hopefully the framework would help me learn them.
> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware).
Well, that's how they could be structured. There are many other ways. MVC is only one option among many, and it has its drawbacks too.
Your application doesn't need logging until you have a problem that is solved by logging. It's possible that you never have such a problem. If that's so, then building a logging subsystem is a waste of time.
> I don't get many of the concepts involved with building a microservice (circuit breakers, service discovery, etc)
This is because you haven't really learned how to think about solving a problem with code, but have instead learned to apply a framework to any problem. If you try solving the actual problem you have first, which involves really understanding it, then you'll probably find that the framework solution is vastly overspecced for your particular situation. Because the framework has to cater for a much wider range of situations than yours. If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution.
> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution.
Only if you know what you are doing.
I have read smart people admit that at some point they realized that the compiler had outsmarted their clever inline assembly hacks and I fully expect this to be true in a frameworks vs homebuilt scenario as well.
Also: The number of people who knows my or your brilliant solution will always be dwarfed by the number of people who knows Rails, Django, Laravel or Spring, meaning as soon as you need to hire you are at a significant disadvantage.
(I've seen brilliant people running frameworkless also, but I wouldn't necessarily recommend it for more ordinary people like me ;-)
I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude.
But the framework maintainers aren't looking at your specific situation. I mean sure, if you're writing yet another CRUD system for yet another SaaS product, then fine, use Rails, that's what it was designed for.
But if you're not building Basecamp, then your application is eventually going to want to do something that Rails wasn't intended to do. And then you're going to have to write your own code. And if you're not confident that you can write that code, because you don't think you can write good enough code for this... then... why are you doing this?
> I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude.
I don't think that's the actual message. I think the real message is more like "framework maintainers have significantly more total time invested than you do..." (especially when you add up over all the maintainers and bug reporters over the entire life of the framework) "...so they are more likely to have correctly handled some particular rare bug or special case than if you try to do it all yourself."
> I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude.
As had been pointed out before: they don't have to be much smarter, they just have to have more time at hand or be more people, get more bug reports, get more improvement ideas etc.
> But the framework maintainers aren't looking at your specific situation. I mean sure, if you're writing yet another CRUD system for yet another SaaS product, then fine, use Rails, that's what it was designed for.
Let me assure you that I am not using Rails for my hypothetical real time radar tracking system and I'm not recommending anyone else using it for anything either except what it is made for ;-)
That said I think many people will find that their use cases aren't that special.
> But if you're not building Basecamp, then your application is eventually going to want to do something that Rails wasn't intended to do. And then you're going to have to write your own code.
Did you ever try Rails?
> And if you're not confident that you can write that code, because you don't think you can write good enough code for this... then... why are you doing this?
This is a very uncharitable interpretation IMO.
Maybe we just have better things to do than reinventing the wheel again right now..?
(To be clear: sometimes the wheel needs to be reinvented, but every single time.)
It is necessary to have a fundamental understanding, and often frameworks, as you said, can cast us to a single shape, making it difficult to see how else the problem could be solved.
But life is too short to always start at first-principles and rebuild civilization brick by brick.
Frameworks have three things: the code artifact: a Rails or a React, then the reified knowledge it abstracts: like how to structure a web application, and the community and their cultural knowledge.
Sometimes it makes sense to forego all of them and make it your own - especially when that layer of abstraction is core to the value you're creating and you want complete creative control over it. But often times they can be the difference between business success and failure.
> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution.
It will be more appropriate for right now. Whether it's smaller, tighter, or faster (or any other qualifier) is dependent on the code quality.
As the manifesto says, using a framework involves tradeoffs. One of those is trading that direct current appropriateness for future expandability, reliability (bug repairs etc) and other advantages of using someone else's code that covers more use cases than your specific, current needs.
I've seen this more often go the other way - that adopting a framework appropriate for the problem right now then turned out to be a massive restriction on the system as it grew, because the framework turned out to be inappropriate as the system developed.
At least with homebew code, you can adapt it however you like. With framework code you're at the mercy of the maintainers, or you have to spend massively more effort adapting it to your needs, with the risk that a future update to the framework could break your code.
That system would never be exist if not for the framework. Also good luck hiring developers who want to work on your half-arsed system (or rather who would run away as soon as they realise that their experience is barely transferable to another business).
With homebrew code you end up with a few really old developers whom you pay a lot because no one else exists in the universe to support your system. Everybody else comes and leaves while never saying that, to be fair - you really need to rethink your approach to software development.
> Your application doesn't need logging until you have a problem that is solved by logging. It's possible that you never have such a problem. If that's so, then building a logging subsystem is a waste of time.
Your application doesn’t need logging until _right before_ you have a problem that is solved by logging.
I don’t use frameworks these days. I’m glad I was exposed to their ideas in the past. I’m glad that exposure shaped my current approach. A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.
> A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.
This. If you could hire a team of brilliant developers you wouldn't need a framework.
Frameworks capture the design requirements of brilliant developers...but they're not your developers and they may not be your design requirements. The trick is to know when the framework's design requirements differ from yours so much that it's a better business decision to roll your own code than to change your requirements to match the framework. I kinda think far too many businesses change their requirements for reasons of short-term MVP and then paint themselves into a framework corner.
I’ll add that when you write your own solution, it is suited for what you need it to do, and not all of other things.
When using a framework (or a library) it can come with a lot of options you don’t need and can bloat your app.
For example, we’ve made parsers that where waayyyy faster than what existed. But only because we knew exactly what was coming in and didn’t have to test a whole bunch of edge cases a standard library have to test.
Same for a framework. To be useful it has to come with a lot of possibility that you probably won’t use for your special case, but that slows down the whole.
>> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware).
> Well, that's how they could be structured. There are many other ways. MVC is only one option among many, and it has its drawbacks too.
IIS on Win 2k-ish and PHP were a sweet balance. Save file, reload page, file is seen with directives executed. Very much like JS now, sans live reloading. Rails and Django and Nuke and Drupal etc. were a good step toward including a lot of good patterns beyond the point of the required “common.php” getting too long and also CI reports became fancy with common frameworks out of the box, and other operational benefits.
People forget what life was like before Rails and Django.
Everyone can build their functionality in any way they want to, but the trade off is that anyone else who works on your code then has to figure out how you structured it, documented it and make sense of everything else along the way. It’s a huge headache if anyone other than you is ever going to work on your code.
But that also only works if there is a clearly dominant framework in your language (like Rails and Django).
In languages that are more built for the web out of the box like PHP, JS and Go most frameworks are just putting the pieces together in different ways and that leads to a lack of a dominant structure.
Anybody can strip out parts to make something fast. There’s nothing special or magical about that.
Assembling a cohesive approach to solving a repetitive problem that thousands of other people can get behind is significantly more challenging. It’s an exercise in optimizing education rather than optimizing performance.
Good frameworks are hard. Bad frameworks are numerous and easy. Look for languages with a single dominant framework.
> But I wouldn't have gotten to this point had I not learned Django and Rails first.
You would because I did. I started coding CGI scripts in C in 1994 then discovered Perl's CGI.pm
Then I handcoded SQL queries and discovered marshalling / unmarshalling / SQL injections etc. Then started using some library to spare me the issues.
Repeat for any piece of the stack.
Am I going back to frameworkless? No, because I would end up without customers. "No sir, it takes 6 months, not one, because I have to hand code everything or use my own buggy library instead of X which a zillion other developers use."
No. They're just suggesting that in 6 months the libraries they would create to support their frameworkless application would contain some non-trivial amount of bugs. That seems 100% reasonable to me.
Of course, they could plug existing libraries into their frameworkless application, which seems like a much more reliable approach.
I worked the opposite way round. I built my own custom PHP frameworks for each project for 15(ish) years until Laravel and then I was finally convinced it was better to use someone else’s framework than mine.
I liked doing it this way round because when I did Finally use a framework I had a pretty good idea of how it was all put together and also really appreciated the elegance and design choices they had made.
I’m not sure I would have appreciated it so much if I had started out with the framework and not learned all the things it takes to build one under the hood.
About the same as mine, I have started writing PHP code as my first project a decade ago without any web framework and not even a PHP proficient. Until Laravel first appeared in the PHP world when MVC approach was easy to pick up for a small site.
I'm no longer find MVC approach sufficient for all projects and move on to Javascript, Swift, etc, finally settled on Go just before it turns 10th. I'm really appreciate I could build without web framework today.
Laravel isn't an MVC framework. I often see people make this point and it puzzles me because even the creator of Laravel argues that it's not MVC.
Laravel has a "Model" abstraction, but its models are Active Record objects, i.e. database row proxies. The M in MVC is not supposed to be in 1:1 correspondence with your database tables. Laravel's Model class is poorly named.
The closest Laravel would come to being MVC would be by adding your business logic to service classes and adding them to Laravel's service container - an approach that the Laravel documentation mentions as a possibility but doesn't make a big deal of. Indeed, the documentation largely encourages the use of controllers to contain business logic.
Sounds as if you prefer the Microsoft take on MVC, where they introduced the "UI Model" as an additional component.
(Real) Model -> fetch -> UI Model -> build -> View
^
|
v
build/modify
^
|
v
Controller
The UI Model serves as a simplified version of the "real" model that can also use the data structures/objects used by the technology used in the View.
In "original" MVC (outside of the use of this term in webdev), the "M" in MVC absolutely did refer to a 1:1 correspondence with the data at the core of the application. This works too, but when using various UI toolkits, adding the UI Model can make things feel a bit more natural.
For the last 15 years PHP didn’t have a framework that wasn’t a pile of dysfunctional code. I can totally understand why you never considered a switch.
What about Symfony? PHP is a terrible language but Symfony is the most pleasant framework I've ever used. I've been out of PHP for some years. How is Laravel better than Symfony?
For sure. Once one built with Django or/and Rails, it is much easier to know how to structure the other more decoupled frameworks like ExpressJS. Sometimes it is much better to decouple an app into different components that we need such as ORM, layout engine, depending on the task at hand.
I dislike these absolutist statements and manifestos. The real world is kind of complicated. What problems are you trying to solve? Will a framework help you solve those problems? Is the solution better served by gluing libraries together? How much control then are you ceding to libraries? For example if you drop Django and use SQLAlchemy to manage your SQL queries, you've just exchanged one high-level abstraction ORM for another, with all the caveats that involves, only now you have more glue and wiring code to write. And frameworks are a spectrum - in Python you have Django at one end and FastAPI or Flask or Falcon at another.
Yes, people should learn the basics - plain Python or Ruby or vanilla JS or SQL - before moving onto frameworks. But having done that, sometimes you just need to get shit done without reinventing wheels, and sometimes you need to know when the precision instrument beats the pile driver. Frameworks are just one tool in the toolbox. Refusing to use that tool when it's warranted is just as bad as always using that tool because you don't know how to use the others.
> I dislike these absolutist statements and manifestos.
From the manifesto: "We don't hate frameworks, nor we will ever create campaigns against frameworks, but we perceive the misuse of frameworks as a lack of knowledge regarding technical debt and we acknowledge the availability of alternatives to frameworks...The purpose of this Manifesto is to have valuable conversations about the movement. We firmly believe that to be useful this manifesto should be modified during the time as a result of the conversations that our community will have."
What is absolutist here? To me, this seems like the most even-handed, least absolutist manifesto that I've ever seen.
Then why even call it a "Manifesto"? Why the need for a "movement"? These imply a struggle against something that needs to be overthrown or toppled. If you want to start a sensible discussion about "using the right tool for the job" you don't need to write a "manifesto" - a simple blog article will suffice. Manifestos - even the ones written with the best intentions - lead too often to just another kind of dogmatism (looking at you, Agile).
When I see "Manifesto" I think "young, full of energy and dumb about how the world works". Manifestos are declarations of a conceptual bulldozer. Why the drama? Just do what you want without the theatrics, or the declaration that "you're doing it differently" - who cares!
I'd understand if these generalizations came from young and inexperienced developers still figuring stuff out, but you also see them from older developers - they might still irrationally hate on, say, PHP or Java based on their experience with these languages a decade ago, without recognizing that a) PHP and Java and their communities/ecosystems changed and improved since then and b) the problems may have resulted from misuse or lack of experience with the tools at the time.
Languages are just tools. To "hate on" this or that method of solving problems is just immature. To avoid a technology because it is a bad tool is fine, but to trot out manifesto declarations is following some drama script that is unnecessary.
Years of picking through the pieces of other developers loosely documented homespun apps made me appreciate the value in a framework - even a dead or dying one. As a rule of thumb, if I'm developing a pet personal project, then I'll write it myself, if its work then I'll consider a framework, depending on the scope of a given project. In the real world of commercial web applications your project will very likely be touched by many other developers over time. Many of these developers may have a relatively fleeting engagement - i.e addressing one bug or adding one feature.I prefer not to force these developers to read the entirety of my code to do their job.
I wonder how many (besides myself) would not even apply for these jobs working with outdated framework? I imagine most would want something relevant to their career?
Frameworks might help with the bus factor but eventually they become the bus? (hit by the back of the bus? how visualize this?)
I think you are selling yourself short, I would really love to read your code. If the alternative is familiarizing myself with the horrors of [say] Angrular (no really, say it out loud) the choice is easy.
Maybe the job ad should demand the applicant to be familiar with CrapPOS. Then I would be like, hummmm interesting company? maybe? In stead of my usual aaaahhhhh no no not [say] Angrular (really say it out loud, say it really slowly twice)
> I wonder how many (besides myself) would not even apply for these jobs working with outdated framework?
I would think twice before applying to work with an outdated framework; I would think three times before applying if it said “you are going to be developing for our home-grown web framework” :)
Only if you are a major player which defines the de-facto in the industry.
Meh. Reeks of Not Invented Here and reinventing the wheel.
It almost reads like "we get why people use wheels. We're not saying wheels are bad."
I like your random bespoke shit less than frameworks that tend to solve the same problems but in a more standard way with slightly more robust design.
If you don't want to use it then fine. Totally depends on your needs. To create a movement shunning frameworks entirely just seems to be a totally fashion driven idea.
Sure, some things shouldn't be built with frameworks. However, some things should be.
Personally, if the project is large enough/warrants it, give me rails/django/laravel or ember/angular over something frameworkless _most of the time_.
Why? because there is documentation and an established community. With the frameworks I mentioned there is also sometimes conventions (i.e rails/ember).
Can you build something with frameworks that is horrific, madding, and complex? Yes. Can you achieve that same result without a framework? Yes.
IMO the propensity to get things wrong in the context of a framework is less than the propensity to get things wrong without one.
I think this manifesto is missing more thought/detail to properly reason about.
Basically, it seems everything they believe is "follow extreme programming as rigidly as possible and it will alleviate the downsides to being as short sighted as possible."
In JS, frameworks have helped us to work out which bits of "magic" we really value, and over the past 5-7 years especially, that has informed the evolution of the language. And now, most of what we'd want is built into the platform (raucous applause). I build pretty much everything - from simple to very complex - with arrow function closures and direct DOM manip, and it works beautifully. I occasionally use lit-html if I really need to to make quick progress. But otherwise, it's the raw DOM API with one simple, functional pattern...
Any advice for rendering lists? I usually start down this path of building the elements and appending them to some container element, but as soon as I need to update a single element in the list, I end up re-rendering the entire list... with a gigantic list this can start to become problematic.
The approach I've been taking is using the source data to determine what index needs to change, and using the dom to swap out just that element. Here's an example:
I have a simple reconcile function (that I wrote, in umpteen variations) diff the previous and upcoming view state (not the DOM state) for each list item, and if there are changes or new items, the changes are made. If not, DOM nodes are not touched.
FWIW, it is actually nice to take hold of the details. In many situations you realize that you can alter the way things work to achieve cool effects or performance gains or whatever. Things you don't imagine or explore when React is just going to do whatever it does on your behalf.
"The value of a software is not the code itself but in the reasons behind the existence of that code"
I wholly agree with this. However, I'm sort of baffled by this approach. What frameworks allow is you not to have to continiously solve the same problem and waste weeks implementing something that others have solved.
For example, I worked with a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user". In the world of Rails, Django, Laravel and Phoenix this is a configuration task, with existing libraries. In Javascript it was a slog getting the implementation that still lacked much of the functionality of these mature frameworks (there are notification frameworks for Javascript but it was decided not to use them - "no frameworks"!). While it is fun to implement your own thing, here the reasons behind the existence of the code are essentially developer vanity in thinking their notification situation is an absolutely special case, and developer desire to do something stimulating like develop a notification system rather than serve product, organisational or user needs.
To have a clear discussion of this, however, it might be useful to define "framework". Is the target here frontend or backend frameworks? One thing I have observed is in the frontend world frameworks have caused some core skills to atrophy. For example, how many Javascript front end engineers can now confidently, given you click on something, change the colour of it. Probably here a framework is wildly overkill and you will get there with plain Javascript until such a point as complex user interaction is needed.
Realise rhetorically there is less punch to "use a framework mindfully" but this should be basic to any engineering decision "use a language mindfully" and in the last instance "do we need to solve this with software"? Doesn't sound like a movement per sae but corre software engineering skills - use the right tool situationally.
You seem to be equating frameworkless with library-less.
> a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user".
This is trivial without a framework as long as there is a library you can use to "notify the user" (e.g. an email or chat library). It's actually easier without a framework because "event" is just a line of code somewhere in your own application, while in a framework, it can mean a million things and maybe NOT what you actually wanted.
But libraries are much more effective in frameworks.
Say an event that shows a message to a user next time the user sees a page has to know about users, has to be able to store messages for users and remove them once they have been shown, it needs to know about i18n, and have tools to display the current messages in HTML.
A Django library for it can assume the existence of Django for all those things, a general library has a much harder time.
No, I'm not. Libraries were certainly used in this case.
But whereas in Rails this would be mixing in a library to a controller to allow events and configuring them, this was building a new set of models and code over the top of a library for something like Mailgun from no code. A two hour job in Rails/Django/Phoenix but a two week sprint long job to roll your own. Why bother?
> how many JavaScript front end engineers can now confidently, given you click, change the colour of it
The overwhelming majority of JS developers learn the basics before moving on to a modern framework. The most common exception I've seen is backend developers picking up front-end tasks.
If all you're doing is changing the color of something, obviously you don't need a framework. In other breaking news, you don't need a chainsaw to slice bread.
> The overwhelming majority of JS developers learn the basics before moving on to a modern framework.
I'm not sure if this is the case.
I actually set this as an interview question for mid-weight to senior on paper front end engineers and a solid 60% couldn't do it - this was four years ago. Not being able to do this wasn't a "fail" by the way, it was more something to talk around, especially when people successfully reasoned it out without knowing the underlying API, but it did reveal a relatively shallow understanding of the browser environment.
I imagine it is significantly worse now. Do the training course at boot camps take people up from `querySelectorAll` before jumping into React? I'm not sure they do.
A fundamental feature I look for in frameworks is an easily accessible "off-ramp". Is it possible to wean yourself away from the dependency? While many front-pages of frameworks tout how easy it is to adopt incrementally, my concern is about incrementally escaping. Not because I necessarily will, but because it is a good sign of underlying quality and it is always good to have the option.
In my judgment, React scores poorly on “off-ramp” potential as there is a particular React way of doing things. Curious if others would agree, and also for assessments on which frameworks score better on “off-ramp” potential.
It is just the view layer in well architected applications. The off-ramp for a React application is use your state management, data models, controllers, etc. with a different view layer.
Oh, you're making HTTP calls directly in React components? Well, you done goofed and that's not React's fault.
I haven't wrapped my mind around scoped styles. You generally want a consistent UI, meaning mostly global CSS. And, you want the option of easily adjusting a global aesthetic/behavior.
Scoped styles seem like the framework version of the style attribute.
I think for this movement to have integrity you would have to build the apps people think are impossible with vanilla.
You’d need to build those apps/apis in a minimal and elegant way to prove it’s possible. It’s beyond conception for many.
In other words, the complete opposite of what the frameworks show. They always show a todo list, or a blog. You’ll have to come heavy with way more complex apps with simple implementations.
That would be ambitious and could change minds. I’m rooting for you guys. In fact, it might be a great re-take on CSS zen garden if you guys accepted submissions for vanilla implementations and just showcased all the ways it’s possible.
He has been an advocate of this frameworkless approach for many years, and in his book he shows exactly how it's done (might have aged a bit, pre-ES6, this niche is moving fast, but the gist hasn't changed).
The running example in the book is a chat web app with a frameworkless js front end and a node.js backend, using socket.io and mongo.
You can do a lot with libraries. Removing a framework doesn’t mean removing all third party code, you know. The fallacy of the excluded middle gets us into more trouble than just about anything.
I don’t disagree with you but in this case you want to encourage conciseness and simplicity which fundamentally requires constraints (whatever they may be, but at the very least we’re definitely sure no frameworks :p).
I never used frameworks because they seemed like a lot of overhead for some small problems, and then you had to keep migrating, updating, etc.; that is, instead of solving a problem I had to keep solving it, over and over. Dismissing the maintenance of your solution, whatever it is, is unwise.
And certainly the churn of the framework faddishness was not appealing to me. Why learn something and then simply discard all of it for the next cool new thing?
Still, I got roped into a toy project. Got set to use Flask, because it seemed simple. Bought the book, got my environment set up, felt nervous but a little excited ... only to find that my partner decided that we were suddenly switching to Django. When I mentioned that I had invested the time in this (and my own money for the book) to start, I got a little "Agile up" speech, which is apparently the equivalent of "git gud."
So I can see how someone might want to reject frameworks entirely: quite a lot of their in the field use seems to be churn.
However, I still think a stable, mature framework would be valuable so long as upgrades are painless and infrequent, as part of a shared lingo for describing a possible solution to a problem. As a "hustle," no, that sort of thing is a huge turnoff to me, but I do not want to discard the concept entirely.
Nobody is forcing you to update your Django by the way. My business is still on a pretty old version and none of the dependencies are in any way insecure.
There’s certainly also the probability of new holes in the newest libraries so keeping to the old ones is okay.
We're also on an old version, but one problem we're now facing is that the documentation for the version we're on is no longer online. I had to go to an archive site to look something up recently, as the particular feature I was looking at had changed between the version we're on and the oldest still-published documentation.
Using a framework just means "this shall not be my main concern" to me. For example, angular enables me to switch my brain off while working on the frontend. I don't love it, i don't need it, but i use it. Meanwhile i can think about the stuff i actually want to provide via web.
I once worked for a company which had a high developer churn rate - for them it was the most logical decision to run with a wide spread framework (ruby).
Why does it often feel like too many ideologies and tools try to convince you that requirement analysis is optional in their world - one size fits all.
Without even trying to lookup the authors and their backgrounds (if I was into betting) I would bet a sizable wager that the core group responsible for this come from extremely large companies (or my second guess would be a consultancy who caters to large companies).
In my entire career I have never seen more confusion and misunderstanding about how to use frameworks than I have when working for companies listed on major stock indexes with multi-billion USD market caps.
> In my entire career I have never seen more confusion and misunderstanding about how to use frameworks than I have when working for companies listed on major stock indexes with multi-billion USD market caps.
Is it actual confusion, or just difficulty in interoperating with the libraries/frameworks that large companies often already have?
Consultancies are especially unrealistic because many of them tend to take on new projects without having to maintain very many of them. That's definitely going to skew your view of standardized tooling.
If instead this company was focused on long term support or fixing other companies' mistakes, I think the view would be different.
If they mostly get called to fix legacy projects they probably only see the issues and limitations imposed by frameworks.
If they mostly get called to jumpstart a new project they'll probably love frameworks that let them deliver quickly and reliably, since they don't have to worry about long term scope changes and maintenance.
I feel like this would leave me with my bare hands fighting against the mighty dragons of DOM and state. Now I have to roll my own two way data binding and redux clone? Maybe try optimizing with my own virtual DOM? I’d probably sink into the mire within minutes from the cognitive overload alone.
I mean, yes maybe my framework is actually a badly designed weapon that is too complicated and overburdens me. But it solves my dragon problem. With my bare hands I am no longer overburdened, but now I’ve traded that advantage for much worse problems.
Which is why I figure, on balance, I do need frameworks.
Redux is a really small library. I think using it would easily be in the spirit of frameworkless. It also pulls in only two dependencies itself, total—one, which depends on another, which has no deps.
I always remember Adrian Holovaty's talk on this subject, worth watching [1].
I'm pretty sure he said he wrote SoundSlice [2] without the help of any framework (although can't find the quote atm). Soundslice is one of the most impressive and polished web applications I know, so pretty inspiring stuff.
While this is a great talk, and a great web app, I think there is a bit of over compensation on their part, because of them being in the unique position of having founded and had to manage the ticket burden of a very popular (backend) framework - Django.
It's odd because in the talk he advocates patterns over frameworks. Django is an implementation of MVC, as is well known. What is the value of implementing MVC again in Python when someone really has done that job for you?
There is a bit of a slight of hand here. If someone had built a frontend framework in Javascript and was now no longer advocating them, that would be a cleaner argument. But we have a shift of abstraction here from front to back end, when the two domains need to deal with different worries.
Backend or frontend, I don't think it makes a difference for the points of this talk: build your own codebase, use what you need as you need it, consider following established patterns if you find ones that fit your problem.
Django is used as an example of the downsides of a framework, and how the complexity of frameworks explode even though any given user only needs a small percentage of the features.
That implies that you have to become an expert in all the tools to be able to meaningfully compare them. That's not possible. There are thousands of ways to write a web server. How do you choose a best one?
No, that only follows if you believe there's such a thing as "the best one'. You don't have to be an expert, let alone a layman in every tool and technique in order to find a way that's suitable.
My view of frameworks and tooling has translated into other facets of my life.
I wouldn’t by a chainsaw until I felt the pain point from using an axe and branch cutters, or buy a leaf blower until the raking/sweeping got old.
There’s a lot of problems a framework can solve but as a software engineer you should know intimately what each of those problems are before relying on more powerful tools.
I actually find frameworks limiting in a lot of ways so I prefer mixing in specialized libraries
I bought my first home last year. I have 3/4 acre and > 50 trees. I grew up in a townhome with a very tiny yard, so pretty much all the yardwork at my new home was new to me.
I bought a push broom to clean off my driveway and patio. It took about five minutes to realize I was wasting my time and needed to buy a leaf blower.
I also bought a chainsaw even though I had never used one nor punished myself by trying to use an axe to take down and cut up a tree. It was obvious that the chainsaw was the right tool, even if it is more complicated, is more expensive, and requires more upkeep than an axe.
exercising is "punishment" too. it's perspective. thats how you grow, even as a software engineer.
I have 3+ acres and live in the mountains. Splitting a stump with my strength and a axe is rewarding and good for me, even though i used a chainsaw to get the stumps.
I take the exact opposite perspective in my personal life. If I've got a huge weekend project, I'm gonna go ahead and get (or rent) a chainsaw because my time is valuable to me and I don't need to live through the struggle of manual tools to understand the benefits of technology. What does the day of struggling with branch cutters and an axe before succumbing and renting a chainsaw really earn you? Do you really feel like you did a better job or something because you felt like you earned the chainsaw?
I've written an HTTP server from scratch before. I've experimented with scaling it up in multiple ways. I've admitted defeat and gone back to using pre-existing software. Other than scratching an itch to learn, I can't tell you one fungible benefit I got from that exercise as it relates to developing a REST API. Why should a software engineer who builds a REST API need to understand the inner workings of HTTP to use an HTTP framework? Why should a software engineer need to build a massive UI to understand how hard state tracking is to use React? Chances are someone is paying for that code which, by definition, is worse than it should be because it's an exercise in learning why the framework is necessary.
> I've written an HTTP server from scratch before. I've experimented with scaling it up in multiple ways. I've admitted defeat and gone back to using pre-existing software.
Exactly. you're a better software engineer for it because you understand the underlining problem better and you've internalized the need for more powerful tools.
It's not about "earning the chainsaw". It's about learning.
> What does the day of struggling with branch cutters and an axe before succumbing and renting a chainsaw really earn you?
Perspective? Reverence for the how hard humans used to live? Being in better shape? idk.
I feel that often a framework can give you a jump start into something new Where you don’t know what you need but at some point you may outgrow it and be better off doing your own thing because now you know exactly what you want.
Happened to me for example with ORMs or third party WPF components. They were good to start but at some point became limiting.
I think you often can’t or shouldn’t skip that step because otherwise the learning curve would be too steep.
Certainly frameworks can do that but most of the time, especially for an important codebase it’s a good idea to rewrite the whole thing. It’s actually a good idea to start away even when you have lots of unknowns but have in mind it would be a good idea to do a rewrite. Smart companies do at least proof of concepts for this type of project and it pays off. A few sturdy well made code bases can become the backbone of a little enterprise.
These days I usually try to implement something from scratch before taking on a dependency. A lot of times I find I never need more than a tiny slice of the functionality a library would offer. And even if I decide I need one after all, I have a much better appreciation and understanding of what it's giving me. Over time I've developed a sense for what sorts of things are likely to be hard to do myself.
I think a better definition is: Has the term "{library_name} developer" been adopted as a title? "react developer": yes. "moment.js developer": no. "rails developer": yes. "devise developer": no.
I kind of disagree with that, a lot of companies will use terms like "react developer" or "react native developer" because they're looking for specific skill sets, only targeting those skills by explicitly naming their role after it. A lot of bigger companies also usually higher through recruiters, who usually are non-technical and will make up those names.
In reality, you'll most likely be a software engineer specialised in react development.
I did, simply because it became the defacto interaction layer, with its ecosystem of first- and third-party plugins. Perhaps a plugin ecosystem is another defining characteristic: I think the "all batteries included" property most people associate with frameworks seems a bit limiting.
Is openSSL? How much domain knowledge should developers be expected to have across the broad array of capabilities modern apps require? Should we be implementing our own tcp stacks?
Frameworks catalyse development. It's much easier for a new team member to read the very rich and well explained Django documentation than to pour through reams of poorly documented code for a custom mvc for instance.
This feels like both tilting at windmills and irrational expectations on devs who for the vast majority need to turn out features, not core libraries.
According to the dictionary, a framework is "an essential supporting structure of a building, vehicle, or object".
In software it's the same thing. The framework defines the structure, you just fill in the blanks like you would fit floors, add wheels, etc.
The pro is that it's an easy way if you want to build an application that closely follows an existing type of application. But it's too constraining if you want to be able to customize the structure down the line; all of a sudden, you realize that it's defined outside, in a technology that is not your own and you don't understand.
Back when I was doing a lot of Python work I was a big fan of Flask. The reason is that it really just provided an integration layer for existing stand alone libraries; it didn't feel like I was buying in to some massive framework, just leaning on Flask to get rid of some of the boilerplate glue code that is otherwise need to write to e.g. find a jinja2 template, render data with it and then turn that into an http response. Just `return render_template(...)`. But if there wiring became inappropriate it's ultimately not doing that much, and it's easy enough to take that template and use it in a different context.
I don't know how others see it, because the distinction between frameworks and libraries can get fuzzy. For me when I Inter operate with the software in the same way I would any of the tools in my garage, that's a library. When the software feels more like a service that someone provides, then that's a framework.
Hi, I'm one of the founders of the movement. We talked about that a lot but it's not easy to define a framework in a specific way. For example, React is a library. But I think that most of the time people use it as a Framework. If you have some ideas on how to express this thing in the manifesto PR are welcome!
I like the "your code calls libraries, frameworks call your code" description.
React is a library because you can have websites with as many render roots as you want. You can use it only for small parts of the site/app, control all of the props from the outside, etc.
People use it as a framework because they take the SPA route with a single root. Usually a bundler even generates the HTML file for them, tying the entire app to a single render call.
I know how to do most all of it but...there's a lot to do and keep up with that other people are always actively doing/researching in a huge community in a monumental way and have docs for it lying around that are quite comprehensive that allows a team to start working on well-tested code and methodologies together swimming in the same direction without huge debates or wacko decision making from a lone-wolf developer. To have some random first-guy on a team decide his/her own framework from scratch is the usual death knell or redo of the project and creates a bad environment of "my code is truth" type thing without docs or with some terrible ReadMe that's out of date. A mark of a project that is easier to work on (productive) has tons of StackOverflow related search results on the tech / stack / framework it's being used on and typically will have one of the giant tech companies actively investing in it.
Frameworks (as the most popular currently exist) have always felt like the wrong conceptual approach for building complex webapps.
That is, if you're going to go through the trouble of shadowing the DOM, creating "components", etc., then why expose the DOM at all and why make those components HTML-bound? Why surface CSS by default?
A framework could completely abstract away the messy Web semantics that make webdev so painful. Use a GUI for laying out the UI and let it generate the HTML. Use an event-driven component model for "true components" that don't carry the weighty mishmash of CSS, templates, and code.
Rather than go back to vanilla, it'd be interesting to explore going forward beyond Web semantics and protocols. That feels more like evolution.
Sounds like not-invented-here syndrome. Not all frameworks are the same, but frameworks (like Rails) are what allow me to walk into any company or project using them and be effective within hours or days. Without frameworks, you end up with spaghetti that takes months to understand. While great for job security, its terrible for maintainability, on-boarding, security, performance and longevity, and represents a looming liability for the companies that rely on the code.
To me, that's a foolish trade off all for warm fuzzies to validate how smart you are.
This seems like a really stupid idea to me. Who is to say that gcc isn't a framework? How about the Linux kernel? How about x86 or an Intel CPU? Even a 555 timer chip is a framework
Oh boy. I'm not sure there's a worse feeling than popping open a new (to me) project and finding a homegrown framework.
I did this one time as the lead/ architect on a large project. I had valid reasons (at the time) but it was a pain to onboard people. I had to answer everyone's questions / etc even though most of it was vanilla for that platform.
Like all engineering decisions, there are tradeoffs.
One of the things appealing about the readme.md they have in the manifesto is a list of "doing it without frameworks" articles/talks.
This is very appealing to me. I've done a lot of different kinda of programming over the years (embedded C, FORTRAN engineering simulations, years of modeling and ux/tool with Smalltalk, Linux processing and tooling with python, mobile apps in objc, kotlin, and swift, and lately flutter), but I've largely remained aloof of the web. I can skim JavaScript, I get sockets and http (done quite a few protocols over time). Despite all of that, I found web programming very daunting/overwhelming. Every time I dabble, the upside learning curve/awareness just overwhelms me. Maybe because I'm a "dive deep figure out how it works" guy. But this is appealing to me.
I've been bit by a "dead framework" before. We used kohana the php framework and soon it was dying. We were totally fucked haha. I guess I've been lucky since then, I haven't had the misfortune of picking a bad framework.
We use Phoenix with Elixir now, and I don't see Elixir dying anytime soon. With Nim, there's Jester, but I can definitely see that framework dying once Nim gets it's "one true batteries included web framework".
My point is, it's a gamble. Pray you don't fuck up.
I like this manifesto, and you should definitely try to build something without a framework. Database migrations, querying data, data processing, background jobs, it's pretty fun to write something right there up on the edge, your way.
Personally, I would never use a framework anymore for the frontend. I did some simple projects in vanillajs and the sheer simplicity of it and being able to understand the whole code beats any framework anyday.
Like most, I started with React/Vue etc and realized that I was trying to learn a whole language and ecosystem on top of JS and that was why i always found frontends to be so complex. There's simply no comparison.
This is a good example of why a vanilla JS app is much simpler than a framework driven app. Because you've only done the absolute minimum, and it wouldn't work for even a moderately complex real world project.
There's no security considerations. There's no state management. There are no tests. There's no performance improvements like memoization or a VDOM. Even simple things like managing constants isn't done well (eg you've hardcoded the API address in to the getPost function). There's no error handling, so if an API call to fetch a post fails nothing will happen except you'll get a JS error in the console to say 'post.id' not found when PostShow tries to expand out the template string.
Making a simple app in vanilla JS by ignoring everything that makes a fast, robust app hard to build is easy. That's not what most developers are trying to do when they use a framework though. People reach for frameworks so they can implement the hard things without having to build them from the ground up.
No doubt you could implement all of those things, but by the end of it you'd probably have implemented something very similar to React. It's not unreasonable for people who want those things in their apps to just use React in the first place.
> There's no performance improvements like memoization or a VDOM.
VDOM is only a performance improvement if you already bought into a specific version of the reactive architecture (namely, the declarative one, pioneered by Elm and popularized by React).
Otherwise VDOM is an overhead both in performance and in complexity.
Svelte has shown it's possible to do away with that overhead and still keep a nice, declarative API (which is much faster than any VDOM-based solution as it doesn't pay the cost of having a mirror of the DOM in memory + having to run a diff algorithm on every change).
Older frameworks also were able to get by with no VDOM by manually binding different parts of the DOM, which can be done well, but admittedly may result in difficult-to-read code.
Thats quite a collection of nitpicks and I don't think they are all fair;
> There's no state management.
But there is state management via variables in every view. The state management is about decoupling views and data. in case you want a full featured redux like state manager, i don't even see its point.
> There are no tests.
Its an article. adding basic api tests is a trivial task. There are no tests as that wasn't what I wanted to show case.
> There's no performance improvements like memoization or a VDOM.
Using VDOM has no performance improvement unless you need to rerender the entire dom very fast which is where memoization and VDOM are superior. This is a simple event based html/js app. user clicks on something, DOM is rendered. thats it.
why the hell would I want to rerender the DOM every time for no use. This is like saying vanillajs is bad because I didn't write my code in typescript and convert to webassembly to drive web components in my html. I did none of those things because they are not needed...
> Even simple things like managing constants isn't done well (eg you've hardcoded the API address in to the getPost function).
I am not sure what the problem is here... Would it be better if I abstract it to a module where I maintain the map between the api and the function?
> There's no error handling, so if an API call to fetch a post fails nothing will happen except you'll get a JS error in the console to say 'post.id' not found when PostShow tries to expand out the template string.
yep. its a hook. This is a simple article on how things can be achieved. expecation is that when people can show the error message in the console, they can easily consume it in the html as well, if they so desire.
In my other project, where I am using the same error hook, i don't post it to a console but to an notifications div on top of the, page.
> No doubt you could implement all of those things, but by the end of it you'd probably have implemented something very similar to React. It's not unreasonable for people who want those things in their apps to just use React in the first place.
And my argument is that all of us don't really need all those things so why use the full react/vue ecosystem? just a 100 lines of vanillajs would suffice.
Anyway, the point of the article was to show a different way of doing things. i don't expect everyone to agree with it and its fine. each to his own. I personally don't like using frameworks when i can do the same stuff by myself with minimal effort.
> Like most, I started with React/Vue etc and realized that I was trying to learn a whole language and ecosystem on top of JS and that was why i always found frontends to be so complex.
This is intriguing because as someone who started with vanilla JS long time ago I lived through the period when jQuery was seen as the breath of fresh air and React was welcomed as a great alternative to the tangled mess of bespoke code with callbacks all around.
One problem that makes deciding what to use is evaluating the size to which a project will grow. For a one pager or a very simple web app a framework (be it front or backend) is often an overkill. But maintaining a large app that does not use one is quite hellish.
The problem I have with Django, is that it tries to micromanage the database table for me with its own flavor of ORM.
To get around it, and not use ORM, and build out the tables yourself, is difficult. The documentation examples appear to be lacking.
I don’t have a problem with writing my own SQL queries, or writing my own table creation query code, but I tend to have problems trying to get Django to work with my custom tables. Mostly because the documentation doesn’t seem to be geared around doing that.
And then, some people say, that if you’re not using the Django ORM, then there is little point in using Django anyways, and you should use something more lightweight like a Flask.
Maybe someone else with more Django experience can chime in here.
I don't have loads of Django experience, but I have done some Django and some raw SQL + Flask and had good experiences with both. I think I agree with you.
A lot of the benefits that you get from Django and its plugin ecosystem come from having the models available as a common representation of the database that you can be transformed and inspected by various other tools.
If you don't want to use Django models, then I think Django is the wrong option.
Flask is a pretty great option. FastAPI adds some stuff that I really like and does it well, but is still only a year or two old, so might be too risky for some projects.
Coincidentally I am also someone that not always uses frameworks. I understand why people steer away from them. I am a consultant and I come in a lot of places. I often see small applications become a huge pile of crap simply because someone in the team thought they should do dependency injection and we will use Spring for that.
Somehow a lot of people actually think you can not do dependency injection without a framework. Of course bloat is a huge downside to frameworks and security. The framework and its dependencies are a security risk if you don't keep them updated.
I like the spirit of this movement and would love to see concrete descriptions and examples of the best alternatives to frameworks. For instance, would a recommended alternative be a certain set of loosely coupled libraries? Vanilla JS plus DOM API? Software patterns that mirror a framework but avoid using the framework itself?
A showcase of successful real life applications would also make frameworkless more compelling.
The great news about frameworks is that they can have a catalytic effect on delivering a product that falls within their approach.
The other news about frameworks is that you had better be an expert if you need to deviate from their approach.
I prefer Flask's minimalist approach, for all it means spending time (as noted in TFA) wading through various libraries to "build your own framework", which isn't for noobs.
IMHO, frameworks also distill experience, documentation, community and spirit. It allowed me to switch languages and eco-systems easily, collaborate and talk to like minded people. I'd generally be uncomfortable working with teams who try to build everything from scratch. Ofcourse, it's our responsibility to manage technical debt, but it's easier to do that with frameworks.
Meh, yet another religion-like movement. Like TDD people that think you are not a true programmer if you ever write a small piece of code without writing a test first.
How about a movement to help decide whether using a framework is or not is the best option according to the context?
The problem is not in frameworks, the problem is that frameworks are presented as non-serviceable opaque pieces of magic you're supposed to spell your way through.
Now, if I wanted to, I could build my own application without Django or Rails, as long as I had something to accept incoming HTTP requests, make responses, and a library to make DB calls.
But I wouldn't have gotten to this point had I not learned Django and Rails first.
I think using a framework turns many "unknown unknowns" into "known unknowns".
I can read my framework's documentation and learn it has built in logging, so logging is something I need to think about when building a web app. It lets you filter sensitive data from logs, so that's something I need to think about.
This is why I was building a type of application I didn't build before, I would look for a framework I could use, or something like it.
I'd use go kit for building a microservice for example. I don't get many of the concepts involved with building a microservice (circuit breakers, service discovery, etc) and hopefully the framework would help me learn them.