Marcisbee / radi

🌀Tiny (in size) front-end framework with no extra browser re-flows

Home Page:https://radi.js.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bundler Discussion

colshacol opened this issue · comments

I am creating this issue to progressively discuss and constructively debate on which module bundler should be used for Radi.

The two tools current in discussion are Webpack and Rollup.

This discussion assumes that a module bundler is necessary and that an externally sourced distributable is a desired feature for this application.

My vote would be in favor of Webpack for the following reasons:

Community

With nearly 12,000,000 more monthly npm installs and 26,000 more Github stars, and ~300 more contributors than Rollup, the community surrounding Webpack is much much larger.

This means:

  • More support from online communities.
  • More contributors to tackle bugs and push helpful features.
  • More tools/plugins/loaders/etc to fine tune our build.

Complexity

Webpack is not complex. Complaints of its complexity have become a cultural novelty, like a high school kid that just can't escape a humiliating moment a few years ago. (C'mon, guys. Let it go!)

Furthermore; Webpack 4 even works out-of-the-box with no configuration. (Although, the standard configuration would be of no use to this project.)

I dare say that the majority of issues developers have with Webpack is not even Webpack, but instead the third party plugins and loaders.

The documentation is vast and exhaustive, as well.

Familiarity

This is not a joke.

Webpack may have a bad rap for being too complex, but (assumption) the majority of developers floating around are UI developers, meaning they have more likely worked with Webpack than Rollup.

Furthermore, it would benefit the careers of contributors to potentially work with Webpack in OSS.


Now, what does Rollup offer that Webpack does not?

The most common pitfall I have read is of bundle size, but I have not seen one that takes advantage of the vast ecosystem of tools for Webpack, nor the built in tools for optimization. Not to say that Webpack would win even after optimization, but nobody really knows from what I have found.

(Especially with Webpack 4, which is brand new and not many have pitted the two against each other.)

Ultimately, the bundler should be set-it and forget-it for quite a while. The project is the tool, not the tools that build it. So my opinions about the bundler are not very strong in this instance, as it shouldn't be something we deal with much.

Maybe it'd be fun to set it up with both, Webpack and Rollup, to really see what we feel about it with each one.

My go-to approach these days is using webpack for development, rollup for the actual bundling before publishing.

But that might be overkill on my end as well :). I'm fine with webpack 👍

Is there a reason you would want the library to be opinionated on this?

UMD & commonJS builds should be exported, let users decide what they want to use, yeah.

This is a discussion about the tools we'd use to create those bundles :-)

I really wen't with Rollup in the first place because I wanted to try something new (as I've never used rollup before). I also give my vote to Webpack ;)

@schtauffen Our build process has nothing to do with the end user. It just optimizes for us to get it in a state that we ship it.

I used Rollup when I messed with Svelte. I bragged on it quite a bit.

@ambewas How about we have a showdown and get 2 PRs submitted. One for Webpack and one for Rollup? And then we can review them in their implemented state and output?

@colshacol sure, we can do that.

But for the development itself, rollup itself isn't really an option in my opinion. It is first and foremost a bundler tool for preparing the package for distribution.

Webpack has all the dev tools necessary for making it a great dev experience.

@danieldram
"Use webpack for apps, and Rollup for libraries"

well, there you go. Basically my conclusion as well : )