If I'd have to spend my career developing and attending to a single product, a set of libraries would be all I need. I can fill in the blanks and connect them and write and maintain any missing pieces.
However I work for customers, many different projects, and I'm more than happy to work with Ruby on Rails, that enforces a common structure to every project, lets me predict where files are and what they do, etc. The advantage is in all the time not spent on learning from scratch every single project. I can start working on the very first day. Even Django, which is mostly anarchy compared to Rails, is better than complete anarchy with every single project using different tools and having a different architecture.
Furthermore projects started with Sinatra and Flask and similar tools quickly evolve into something as complex as Rails and Django, with tons of home made fragile code. There is never the time to make them robust, because nobody is working full time on those projects for years. Basically frameworks allow developers to multitask among projects which is great for consultants and also for customers, because they don't have to pay for the extra developers.
Django has a few features that can be taken for granted: the ORM, the templating language (ouch), the admin, the user/auth/permission system, the division in views (called controllers in Rails) and templates (called views in Rails.) They are well known entities but there is no well defined structure for the code. A project can have any shape and I've seen no two projects with the same shape. On the other side every Rails project has the same shape, often even across multiple versions of the framework. The greatest departures from the standard are some app/services directories but in general you can tell where a url is implemented without looking at Rails' equivalent of urls.py
Django allows multiple subprojects inside an app and code wherever one wants to place it. Rails also allows code anywhere but in practice it's always in the same places. Maybe it's Python, inviting developers to overengineer their code.
Yeah the templating language is not so nice, I sometimes use Jinja instead. Also, I don't like the classic MVC so I have a completely different structure thus validation your point completely :P
If you ever end up in Django land (for some project), checkout Django Ninja for APIs, you'll end up avoiding having these annoying url files and just have a
@api.get("some/api")
def some_api(request):
instead. Super simple and useful. I just recently discovered it and I don't know how stable it is but it seems pretty stable so far.
Perhaps "frameworks don't compose" and "frameworks shape how you code" are actually good features, not a problem. Where are frameworks the most popular? Probably for web services (e.g. Spring Boot for Java). You don't need them to compose because you will only have one.
That you are forced (or at least strongly nudged) to code in a certain way is good because that means that all your web services are at least superificially familiar to all developers at the organization. That special service composed from many libraries? Impossible to work on without significant time investment.
I suppose though that if you are in a domain where you actually would want a library, but all that's on offer are frameworks, and you actually need to compose them, then yes, that seems problematic.
Expanding, a framework allows components to work together, the OS being the most common example. Most languages also define a framework for the program to fit into. Startup initialization, main routine, shutdown, memory allocation. Without this it would be hard to use libraries.
The click bait title worked on me but come on, it’s like saying screwdrivers are evil or something. A framework is a tool that’s appropriate in some circumstances and not others.
Well, no. The screwdriver is the library. The framework would be a workshop that someone else set up exactly to their liking, forcing you to use their tools and materials, and you can't easily replace their default screwdriver with one you prefer.
well expanding on that analogy, if you don't have your own workshop and/or don't want to spend time setting one up, then getting use of a shared community workshop would be fine. Especially if all the drawers are labelled, and it has all those peculiar machines you didn't think you'd need but actually turned out to be very useful. Yes, others made some decisions and now you have to follow those, but that is more often a positive thing than a burden.
I feel like I'm stretching the analogy beyond credulity here, but there's also a lock on the workshop and you can't leave it without finding a pair of bolt cutters.
I mean I do think the original article is an exaggeration (as is this analogy), and there are lots of tradeoffs to be made. E.g. in the Java ecosystem it's much easier to find a Spring Boot developer than someone who is willing to set up a project from scratch. Maybe that's a good thing for your project, but maybe it's not.
Maybe more apt would be that the stuff you built in the workshop doesn't fit out the door so you'd need to take it all apart to rebuild it somewhere else.
Still, the article is insensible. Frameworks are not evil. They do not have malicious aims. I think the worst we can say in that direction is that people get tribal about this kind of thing and insist their framework or way is the best and lose objectivity.
Honestly that just sounds like a skill issue. If you're skilled with your tools, you should be able to use similarly shaped tools when arranged differently.
To continue butchering this analogy, craftspeople use unfamiliar workshops all the time and no one is preaching about the evils of pegboards for organization.
I agree with you, too clickbaity, too black-white. But a difference between screws and frameworks is that there's plenty of Django developers but not a single screw carpenter.
If I'd have to spend my career developing and attending to a single product, a set of libraries would be all I need. I can fill in the blanks and connect them and write and maintain any missing pieces.
However I work for customers, many different projects, and I'm more than happy to work with Ruby on Rails, that enforces a common structure to every project, lets me predict where files are and what they do, etc. The advantage is in all the time not spent on learning from scratch every single project. I can start working on the very first day. Even Django, which is mostly anarchy compared to Rails, is better than complete anarchy with every single project using different tools and having a different architecture.
Furthermore projects started with Sinatra and Flask and similar tools quickly evolve into something as complex as Rails and Django, with tons of home made fragile code. There is never the time to make them robust, because nobody is working full time on those projects for years. Basically frameworks allow developers to multitask among projects which is great for consultants and also for customers, because they don't have to pay for the extra developers.
As much as I love Flask (or Bottle) and the Go approach, I find myself in the same boat.
Curious question, why you say Django is mostly anarchy compared to Rails? I haven't used Rails btw.
Django has a few features that can be taken for granted: the ORM, the templating language (ouch), the admin, the user/auth/permission system, the division in views (called controllers in Rails) and templates (called views in Rails.) They are well known entities but there is no well defined structure for the code. A project can have any shape and I've seen no two projects with the same shape. On the other side every Rails project has the same shape, often even across multiple versions of the framework. The greatest departures from the standard are some app/services directories but in general you can tell where a url is implemented without looking at Rails' equivalent of urls.py
Django allows multiple subprojects inside an app and code wherever one wants to place it. Rails also allows code anywhere but in practice it's always in the same places. Maybe it's Python, inviting developers to overengineer their code.
Ah that's a super explanation there, thank you!
Yeah the templating language is not so nice, I sometimes use Jinja instead. Also, I don't like the classic MVC so I have a completely different structure thus validation your point completely :P
If you ever end up in Django land (for some project), checkout Django Ninja for APIs, you'll end up avoiding having these annoying url files and just have a
@api.get("some/api") def some_api(request):
instead. Super simple and useful. I just recently discovered it and I don't know how stable it is but it seems pretty stable so far.
Perhaps "frameworks don't compose" and "frameworks shape how you code" are actually good features, not a problem. Where are frameworks the most popular? Probably for web services (e.g. Spring Boot for Java). You don't need them to compose because you will only have one.
That you are forced (or at least strongly nudged) to code in a certain way is good because that means that all your web services are at least superificially familiar to all developers at the organization. That special service composed from many libraries? Impossible to work on without significant time investment.
I suppose though that if you are in a domain where you actually would want a library, but all that's on offer are frameworks, and you actually need to compose them, then yes, that seems problematic.
Expanding, a framework allows components to work together, the OS being the most common example. Most languages also define a framework for the program to fit into. Startup initialization, main routine, shutdown, memory allocation. Without this it would be hard to use libraries.
A solution is to develop frameworks as a set of libraries + some (best case very little/no) glue code. Eg. ASP.NET vs EF Core.
I saw go codebases started by devs frameworks.
Give me back rails.
Urgently
... and in the end, frameworks are better if you plan to work on more than one project in your life.
The click bait title worked on me but come on, it’s like saying screwdrivers are evil or something. A framework is a tool that’s appropriate in some circumstances and not others.
Well, no. The screwdriver is the library. The framework would be a workshop that someone else set up exactly to their liking, forcing you to use their tools and materials, and you can't easily replace their default screwdriver with one you prefer.
well expanding on that analogy, if you don't have your own workshop and/or don't want to spend time setting one up, then getting use of a shared community workshop would be fine. Especially if all the drawers are labelled, and it has all those peculiar machines you didn't think you'd need but actually turned out to be very useful. Yes, others made some decisions and now you have to follow those, but that is more often a positive thing than a burden.
I feel like I'm stretching the analogy beyond credulity here, but there's also a lock on the workshop and you can't leave it without finding a pair of bolt cutters.
I mean I do think the original article is an exaggeration (as is this analogy), and there are lots of tradeoffs to be made. E.g. in the Java ecosystem it's much easier to find a Spring Boot developer than someone who is willing to set up a project from scratch. Maybe that's a good thing for your project, but maybe it's not.
> I feel like I'm stretching the analogy
Maybe more apt would be that the stuff you built in the workshop doesn't fit out the door so you'd need to take it all apart to rebuild it somewhere else.
Still, the article is insensible. Frameworks are not evil. They do not have malicious aims. I think the worst we can say in that direction is that people get tribal about this kind of thing and insist their framework or way is the best and lose objectivity.
Honestly that just sounds like a skill issue. If you're skilled with your tools, you should be able to use similarly shaped tools when arranged differently.
To continue butchering this analogy, craftspeople use unfamiliar workshops all the time and no one is preaching about the evils of pegboards for organization.
I agree with you, too clickbaity, too black-white. But a difference between screws and frameworks is that there's plenty of Django developers but not a single screw carpenter.