3 ms·
At a visceral level, I really love the concept. I've created my own game engines (before the age of ubiquitous, well-tested free engines), and I understand how
by SomeCallMeTim 11y ago
At a visceral level, I really love the concept. I've created my own game engines (before the age of ubiquitous, well-tested free engines), and I understand how to optimize code all the way down to counting cycles (which used to be easier).
At a practical level, though, I'm really, really sick of people creating Yet Another Framework. NIH is not something that needs encouragement.
And this "manifesto" will be used to justify NIH. It may not be the point of the authors, but people will absolutely point to it when they want to create something that's been done well already.
I totally agree that the right idea is to use exactly the tools for the job. Don't throw every new framework into your app and expect it to be fast enough. "Minimal and thin" is the right answer.
I've been doing a lot of JavaScript work recently, for example, and I often visit MicroJS [1] when I need something. Instead of the 100k+ of jQuery & plugins I can often find one library that's 4k and another that's 6k that together do all I need. If you need most of jQuery, ZeptoJS [2] is often a good answer.
That said, sometimes ecosystems are powerful. When you need nontrivial functionality, and the best options have a dependency on jQuery, it might still make sense to include jQuery. Development time still counts: Spending an extra 30 hours to reinvent a component is great if you're spending your own time on it, but when you're billing by the hour, it's a lot harder to justify if that component is available off the shelf and Just Works in about 5 minutes.
It's all about compromises. I do think that it's common to see developers throw in a component if it's even slightly useful, leading to the web of today where a single page might download and initialize 40-60 different libraries. It would be healthy if the pendulum would swing back in the other direction. But we really don't need 300 ways to do every single thing in JavaScript.
[1] http://microjs.com/# http://microjs.com/#
[2] http://zeptojs.com/ http://zeptojs.com/