> "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it
I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.
Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app.
Besides, bytes count is important, but it's only a problem because people aren't using tree-shaking optimizers, like Google Closure. E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need. A smart tree-shaker is able to detect unused branches and eliminate everything you don't use.
And it's a solvable problem. Google Closure in "advanced" optimizations mode is amazing. Unfortunately the popular libraries are not written for Closure's advanced optimizations and thus are incompatible. This is where compilers can help us. ClojureScript for example compiles to Google Closure optimized Javascript. There's also a fork of an older version of TypeScript that does the same thing. Google's Dart does tree shaking too. Maybe we'll also see EcmaScript 6 compilers that will do it too.
We don't need to sacrifice code reuse because of bytes count. I mean, sure, if you don't find a library that matches your architectural needs, wheel reinvention is fine. But optimizing for bytes count is a stupid reason to do it and we only feel the need for it because our tool-chains are primitive.
Tree-shaking optimizations aren't a magic bullet. I argued for about a year and a half to get Google Search to use JQuery, but it turned out to be a complete non-starter because the way the JQuery library is constructed is not amenable to compilation or static analysis. JQuery often dynamically assigns methods to the JQuery object by building a base function and then customizing it with some data-driven properties, then splitting a string to get the method names. For example, .width() and .height() are the same method, but one returns .offsetWidth while the other returns .offsetHeight; this distinction is encoded into a closure when the JQuery object is created.
It's a really cool programming technique that unfortunately kills the possibility of statically analyzing the library.
The other interesting thing is that this technique actually makes the JQuery codebase significantly smaller than defining separate methods for each function that appears in the API. So it optimizes for byte-size of apps that use all JQuery functionality, at the cost of apps that use only a little bit of JQuery functionality. And I think this trade-off is why people continue to like no-framework approaches: it is possible for the application author to know what functionality from a library they will need and write code accordingly, but it is not possible for a library author to know what functionality a particular application will need and optimize for that. When you make your library more amenable to tree-shaking compilers, you increase the byte-size of it in the absence of those compilers (through reduced code-sharing or dynamism in your own codebase), which makes you look worse in head-to-head comparisons. When you build your library to be small and clever but assume it'll all be used as one unit, you impose a tax on people who just want some of the functionality and not all of it. And when you use no library at all, then you often end up reinventing parts of the functionality of a JS library poorly, in a less optimized form, and as your app grows it becomes both slower and less productive than if you'd just used one of the leading frameworks.
We ensure that React is advanced mode compatible and people routinely get pissed at me because I'm a stickler for bytes. But that's because React is a shared core library where it's our job to be small and fast.
When you're building an app, the trade-offs and priorities are different.
> E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need.
Although a plus of something like jQuery, if you get it off google's cdn, is that probably most users will already have it sitting on their disk so you they won't actually need to download it. It gets cached by default for up to a year.
I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.