Some quick notes of my two weeks living by the unix philosophy.
- Things like underscore, jquery, backbone, bal-util, etc are on the way out
- They were awesome at their time, because until recently, packaging and distributing javascript code was hard
- pre-compile, pre-package, distribute as zip, manual install
- These days, we have npm, component, bower which can automate all distribution, packaging, installation, and concatination of different projects regardless of size
- Things like node's require (browserify for client side), make it finally easy for modules to include each other
- Before we had to battle with global variables and lengthy manual installs to get two libraries working together, don't forget version conflicts
- Now, this is all handled for us
- This allows us to write, tiny, little, concise, libraries that can be distributed, used, packaged, and concatenated by others easily
- This means instead of having 10 different versions of underscore loaded at run time inside your node.js application, especially when each requirement only uses about 1% of underscore
- You now include only what you need, and because of the concise nature, these modules can eventually be considered finished, and as such, you will only end up with one version inside your application regardless of how many apps use it
- This also means that with the traditional utility belt structure, we keep bumping the version dependencies for the latest version even when the 1% we use hasn't even changed, causing unecessary overhead
- The other discovery is that the utility belt methodology, promotes a "more code" syndrone, whereas the initial burdon of writing something that will be considered finished and not touched again, makes sure that you write something that is well thought out, tested, and concise - rather than adding more code to more code
- Using tiny modules has the benefit of if you do decide on redoing a component, you have the choice of upgrading the existing one, or writing a new one and swapping it out, both are feasible and good options - with the utility belt option this gets a lot more messy as if you introduce a b/c break it affects everyone - whereas going the new tiny module route and swapping it out for only the projects that need it, don't incur this problem
- CoffeeScript is still awesome for tiny modules, javascript's fragilility becomes very apparent when writing such things; edge cases become soo important as their impact is dramatically magnified by all the projects that use it and how much they do, this requires extra thought, care, and precision around not introducing unseen problems (e.g. === or ==, for loop correctly, bindings correctly, prototyping correctly, etc.) where coffeescript allows you to march forward pretty easily without having to worry about breaking something without realising - this also follows the unix philosophy law of code generation which states the exact points just covered
Very sleep deprived. Feedback welcome.