There’s this good blog post by automation panda which speaks about all-in-one vs piece-by-piece frameworks I found recently. Sometimes you just want a quick and dirty big library that gets the job done, which is great if there’s awesome documentation and a strong active developer community backing it (bug fixes over just bug reports). However, it can feel like your code is locked in to that one bubble of a framework. There are some fantastic big projects suffocating under a backlog of bugs, and it’s sad to see, but that’s usually when you need to look for an alternative framework.
I find the piece by piece approach better, maybe because I like the UNIX philosophy. Still, for one thing I want to do, I try to find at least two frameworks that can do the job, and have that in mind when I write my code. If I choose the bleeding edge little library and the developer goes missing in action, I could switch to the stable big library. If the big library gets too buggy, I switch to the nimble one. That’s the beauty of open source really, but it does mean a lot of work. All depends on how long term your code is meant to be.
Cool article, agree mostly, it's a good categorization.
Also from a learning perspective, if your going to work on a codebase for a long time you'll need to know what happens under the hood with the given framework. Even though you need abstraction, and don't wan't to get into the frameworks implementation.
I remember when I started developing a project in Rails for my first client, I knew the basics about Ruby and Rails, at the beginning it didn't matter, the incredible setup experience, generators and meta-programming magic let me move forward rapidly. But when time passed by and I started needing to implement more complex features, and also errors began to appear, I happened to be a bit lost (after that I read Metaprogramming in Ruby - great read by the way - in some days and fell in love with the language and Rails' magic modules like Active Record).
Is not that is the framework's fault, Rails is a great framework, but for beginners, all-in-one solutions can be a double-edge sword sometimes, with some years of experience I'm also more inclined to piece-by-piece solutions (Unix commend style, node modules, microframeworks, etc).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There’s this good blog post by automation panda which speaks about all-in-one vs piece-by-piece frameworks I found recently. Sometimes you just want a quick and dirty big library that gets the job done, which is great if there’s awesome documentation and a strong active developer community backing it (bug fixes over just bug reports). However, it can feel like your code is locked in to that one bubble of a framework. There are some fantastic big projects suffocating under a backlog of bugs, and it’s sad to see, but that’s usually when you need to look for an alternative framework.
I find the piece by piece approach better, maybe because I like the UNIX philosophy. Still, for one thing I want to do, I try to find at least two frameworks that can do the job, and have that in mind when I write my code. If I choose the bleeding edge little library and the developer goes missing in action, I could switch to the stable big library. If the big library gets too buggy, I switch to the nimble one. That’s the beauty of open source really, but it does mean a lot of work. All depends on how long term your code is meant to be.
Cool article, agree mostly, it's a good categorization.
Also from a learning perspective, if your going to work on a codebase for a long time you'll need to know what happens under the hood with the given framework. Even though you need abstraction, and don't wan't to get into the frameworks implementation.
I remember when I started developing a project in Rails for my first client, I knew the basics about Ruby and Rails, at the beginning it didn't matter, the incredible setup experience, generators and meta-programming magic let me move forward rapidly. But when time passed by and I started needing to implement more complex features, and also errors began to appear, I happened to be a bit lost (after that I read Metaprogramming in Ruby - great read by the way - in some days and fell in love with the language and Rails' magic modules like Active Record).
Is not that is the framework's fault, Rails is a great framework, but for beginners, all-in-one solutions can be a double-edge sword sometimes, with some years of experience I'm also more inclined to piece-by-piece solutions (Unix commend style, node modules, microframeworks, etc).