4 ms·

I saw this come up during the handmade hero screencast yesterday, and I appreciate the sentiment a lot. Although I have a feeling that Casey and his crowd would

by Udo 11y ago

I saw this come up during the handmade hero screencast yesterday, and I appreciate the sentiment a lot. Although I have a feeling that Casey and his crowd would disagree, I believe this initiative touches only part of the problem, and worse, it could be interpreted as absolving programmers working at higher levels of abstraction from doing their part. Knowing what happens behind the scenes when you write a line of code is important. Question the decisions made by frameworks and libraries, and question whether you actually need them. Keep the stack minimal and thin. Choose the right tool for the job, and be knowledgeable of its inner workings. Resist replacing tradecraft with ritual, especially when programming in groups. These can (and should, in my opinion) also apply to web development, a huge category that seems to be all but despised and written off by the handmade people.

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/

by Udo 11y ago

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/