| Reposting my comment here so it can serve as a discussion point if wanted... Kind of weird that most of the problems identified that are being identified are actually language features that end up making code smaller and more concise, which are languages features that can be optionally used or not. I get the feeling that most of the disadvantages listed here are just things that are done differently and you are used to having to do in node.js because of limitations in the language, that you've later found and attached some benefits to, rather than ideal language features with merits that stand on their own. Seems weird that a declarative module/import system can be viewed as a bad thing, node.js require is done the way it is because that's the most concise way it can be done in node.js without an in-built module system. Creating more boilerplate by exposing a function is easier to read? I'm just not able to follow the logic here.
You can easily identify what dependencies a package has and what it exposes by looking at the header of each library which maintains it in a concise, readable and declarative form - again another area where I can't see how having exports litered throughout the code-base which devs need to scan the whole code-base to find can be considered an advantage. Being able to split out your source files by using library/part is a blessing, which is similar to using partials in C#. i.e. we're not artificially forced to create new classes and abstractions/delegations because the source code is getting too big, as we can group different parts of a library into cohesive and logical parts, that has no effect to the external surface area of the API. I find Batteries included for core functionality is a great win, instead of using/finding adhoc libraries to do the same thing, you can instead use the built-in libraries that are always well thought out and written in idiomatic dart that provides a consistent development experience across the entire platform. The libraries also smoothes out browser quirks behind a consistent API. Not having built-in collections, or not having all async APIs return Futures makes composability harder since different libraries will import and implement their own, and using adhoc libraries that don't follow the same conventions, unnecessarily increases institutional knowledge that is a productivity drain and a source of bugs. Tree-shaking encourages the developer to be lazy and is why it shouldn't be used? This defies logic, wasting time and being forced to find and use minimal libraries not because of technical fit but because of how much your application uses and how much it adds to the overall download size - has only downsides. This developer time-sink exercise is just an artificial complexity that doesn't add any benefits to the end-user. Knowing that your production code will be tree-shaken and optimally packaged for deployment means you can maintain the most optimal development environment you wish as your code will be in its most optimal form when its deployed, so you're free to reference the most suitable library, use as much or as little of it as you need without concern about resulting code-size, which ends up having a smaller output than having hand-picked micro libraries since only the parts of the library that you end up using gets deployed and not the entire library. One of the benefits I got when using the Closure Library (i.e. what Gmail, Google Maps were built-on) was the vast array of well-tested and robust libraries that I could use without any concern of its deployment footprint, being able to freely use any library you wish is what Tree-shaking allows. |