4 ms·

What's the problem with micro-frameworks or libraries? I prefer to be able to find a nice, compact solution to a problem and be able to jump in any make any mod

What's the problem with micro-frameworks or libraries? I prefer to be able to find a nice, compact solution to a problem and be able to jump in any make any modifications I need rather than sifting though a behemoth. It certainly takes more effort on my end to figure out the one-true-framework to the point that it abstracts what I already know. That's doubly ineffective. I'm much more comfortable with the OS project ecosystem we have now with a ton of tools you can just download and use to your whim. Most of the time you don't even need to modify the code to suit what you want. Granted, it takes a bit more skill to be able to know which solution to choose - but that's something we should all be good at. This article also sounds like someone who doesn't actually like the art of programming and just wants to see the end result. I'm only frustrated when I'm shackled by a technology or code framework/library. Other than that you have to enjoy the ride because the end result is never as good as you imagine it to be.

ColinCampbell 15y ago
The problem is there is no guarantee they will play nicely together, not clash, or provide similar and compatible APIs. JavaScript developers are running into a very similar set of problems and having everyone cobble together their own solutions is pretty clearly not an answer, which obvious to those who have tried. You may already know what is being abstracted by some of the more expansive frameworks (Cappuccino, SproutCore, Backbone, etc) but there are a lot of people who do not know or do not want to deal with the differences in browsers, etc. I'm assuming that you don't consider jQuery or its ilk restrictive as far as abstracting the DOM. I don't know of many application developers who would prefer to deal with the low-level DOM API (which differs across browsers, etc) instead of a library like jQuery. There are many people who approach application structure from a similar viewpoint. Instead of rolling their own and running into problems scaling and maintaining their applications, they can use a framework that provides an abstraction that is proven to work. Everyone tries to roll their own pet framework project because that's where the glory is. That's not necessarily the best thing for the future of the web.
- methodin 15y ago
  I agree that rolling new frameworks/libraries out for the glory only is a terrible thing but they generally don't do much harm since the truly atrocious projects fade into oblivion. We can only hope at least one thing was learned from them. I do not consider jQuery restrictive and in fact it's liberating because it provides a core set of tools that are much more useful than the core tools provided by native JS. jQuery was born out of a need. As long as something is more useful than what it wraps I tend to not mind it. But wrapping things arbitrarily like HTML is just useless. I do see a stark difference between marrying independent frameworks that are proven and writing a brand new one that encompasses all the ideas of each.
- benatkin 15y ago
  Here's you: > Everyone tries to roll their own pet framework project because that's where the glory is. Here's jtaby about twenty minutes earlier: > Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects. Talking point much?
  - jtaby 15y ago
    Not a talking point, we just have a lot of conversations about this at the office :)
    - aaronblohowiak 15y ago
      The diminutive "little pet" prefix at one point applied to: linux kernel, kde, gnome, jquery, prototype.js, node.js, ruby, &etc. Your dismissal of small, young projects is akin to saying "Don't start a startup, just join a big business!" You're calling out to people in the Bazaar and asking them to join your Cathedral. Good luck!
FuzzyDunlop 15y ago
I agree with this. The way I see it is that the more you aim for consolidation at the expense of competition, the less freedom you have to renew your approach if you can't quite get the results you want. This leads to people reinventing the wheel in such a way they're happy with the results and also learn new techniques that can be applicable outside of the framework dev environment. This is great for innovation, and when you can code independently of a framework and create your own solutions, you're just one step closer to pushing the boundaries and coming up with something special. A custom microframework is great for that as you can get to grips with the concept of ORM, MVC, OOP (with PHP in particular) and all manner of other techniques. On a personal level, I had the choice of learning a framework to make a REST API, or figuring it out for myself by making my own solution. I re-invented the wheel - probably made something wonky - but it's invaluable knowledge. Had I taken heed of the OP I may still be wrestling with Symfony2 or CakePHP right now. Looking at it another way, this article could have been written a few years ago and instead of Javascript, it could have talked about fresh web developers creating a blog as their first project. The analogous question posed would be, "why don't people just install Wordpress?" The answer to that would be: "because they won't learn anything."

ColinCampbell 15y ago

The problem is there is no guarantee they will play nicely together, not clash, or provide similar and compatible APIs. JavaScript developers are running into a very similar set of problems and having everyone cobble together their own solutions is pretty clearly not an answer, which obvious to those who have tried. You may already know what is being abstracted by some of the more expansive frameworks (Cappuccino, SproutCore, Backbone, etc) but there are a lot of people who do not know or do not want to deal with the differences in browsers, etc. I'm assuming that you don't consider jQuery or its ilk restrictive as far as abstracting the DOM. I don't know of many application developers who would prefer to deal with the low-level DOM API (which differs across browsers, etc) instead of a library like jQuery. There are many people who approach application structure from a similar viewpoint. Instead of rolling their own and running into problems scaling and maintaining their applications, they can use a framework that provides an abstraction that is proven to work. Everyone tries to roll their own pet framework project because that's where the glory is. That's not necessarily the best thing for the future of the web.

methodin 15y ago
I agree that rolling new frameworks/libraries out for the glory only is a terrible thing but they generally don't do much harm since the truly atrocious projects fade into oblivion. We can only hope at least one thing was learned from them. I do not consider jQuery restrictive and in fact it's liberating because it provides a core set of tools that are much more useful than the core tools provided by native JS. jQuery was born out of a need. As long as something is more useful than what it wraps I tend to not mind it. But wrapping things arbitrarily like HTML is just useless. I do see a stark difference between marrying independent frameworks that are proven and writing a brand new one that encompasses all the ideas of each.
benatkin 15y ago
Here's you: > Everyone tries to roll their own pet framework project because that's where the glory is. Here's jtaby about twenty minutes earlier: > Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects. Talking point much?
- jtaby 15y ago
  Not a talking point, we just have a lot of conversations about this at the office :)
  - aaronblohowiak 15y ago
    The diminutive "little pet" prefix at one point applied to: linux kernel, kde, gnome, jquery, prototype.js, node.js, ruby, &etc. Your dismissal of small, young projects is akin to saying "Don't start a startup, just join a big business!" You're calling out to people in the Bazaar and asking them to join your Cathedral. Good luck!

FuzzyDunlop 15y ago

I agree with this. The way I see it is that the more you aim for consolidation at the expense of competition, the less freedom you have to renew your approach if you can't quite get the results you want. This leads to people reinventing the wheel in such a way they're happy with the results and also learn new techniques that can be applicable outside of the framework dev environment. This is great for innovation, and when you can code independently of a framework and create your own solutions, you're just one step closer to pushing the boundaries and coming up with something special. A custom microframework is great for that as you can get to grips with the concept of ORM, MVC, OOP (with PHP in particular) and all manner of other techniques. On a personal level, I had the choice of learning a framework to make a REST API, or figuring it out for myself by making my own solution. I re-invented the wheel - probably made something wonky - but it's invaluable knowledge. Had I taken heed of the OP I may still be wrestling with Symfony2 or CakePHP right now. Looking at it another way, this article could have been written a few years ago and instead of Javascript, it could have talked about fresh web developers creating a blog as their first project. The analogous question posed would be, "why don't people just install Wordpress?" The answer to that would be: "because they won't learn anything."