Webpack bootstrap is pretty intense for small libs
Closed this issue · 8 comments
Webpack is by far the best build tool for very large webapps, but for small utilities, it's a bit...overkill. The webpack bootstrap code can be as large as the library itself! This is just one of many issues that I'm thinking about when it comes to this boilerplate's future...
👍 completely agree with this thought. I have high hopes for roll-up improving as it seems to solve this problem well with very minimal added overhead.
@paulfalgout, that makes a lot of sense. It's almost as if there are three general categories...
- rollup for small libs in ES2015
- rollup or browserify for simple ES2015 webapps
- webpack for monster-sized webapps
1 and 2 may actually just be the same thing. What do you think?
Yeah.. for the most part it seems silly if you're going to redistribute a library for consumption elsewhere that it would include the webpack loader interop stuff. I like that rollup is essentially just a fancy ES6 module concat. Correct me if I'm wrong, but I think you can get around the acorn issues by using some sort of rollup-babel plugin that does the transpilation on each module during the concat. I think there's just some issues with needing the commonjs part of babel for gulpfile.babel.js and then making sure the commonjs is not loaded for rollup.. which might be impossible in babel 6 right now..
But yeah.. I think if you're doing anything other than packaging some ES6 modules together to distribute elsewhere, it makes sense to go browserify / webpack because you're going to need some other thing as some point, that rollup doesn't do.
I agree with all of that. I intended for this boilerplate to be used in all contexts, but I'm slowly coming around to the fact that there's not a single good tool that's useful always.
I'm not too sure what to do about the situation atm. What are your thoughts?
I think it is super super useful to have a boilerplate specifically for writing modules for distribution or libraries or whatever they should be called.. And I think it really helps the open source community if there's a defacto tool that makes sure when someone is open sourcing something it meets a particular standard. In fact I don't know that I would have been very successful open sourcing some of my own libraries had this not been available at the time. But that's likely a much smaller audience than a more generic tool. Perhaps two tools would be better? I don't really know.
Part of me really likes this fulfilling the narrative of helping people bring quality stuff to open source. And while there are various other boilerplates for setting up your project.. I don't know any that are specifically built, or good at open library work. At the same time.. it does seem like if it was really good at doing that.. it's potentially 2 or 3 customizations away from being good at the whole thing..
Ohh.. one thing that I feel is different for libraries than for projects is you're more likely to want to test a library on various environments.. possibly with multiple dependencies.. so it makes keeping the npm i faster more key than when the testing time is a single run.
soooo while the non-uglified version of the webpack output doesn't look great, turns out it appears to compress really well https://github.com/samccone/the-cost-of-transpiling-es2015
I applied this same treatment to Marionette v3 with similar results, however rollup came out on top:
| Tools | File Size (bytes) | gzip size (bytes) |
|---|---|---|
| webpack + babel + uglify | 47444 | 11173 |
| babel + rollup + uglify | 47402 | 11161 |
| rollup-babel-plugin + uglify | 47256 | 10850 |
I suspect this is because now the loader code cannot be removed from uglify, where as in the transpiling test there weren't any external dependencies.
So while I still lean towards rollup for libraries.. it's much less of an issue than I would have thought.
Closing in favor of #319