I've had projects that got really strange error messages when using rollup that completely went away when I switched back to Babel.
One "issue" with rollup is that it is not 100% semantically correct. Neither is Babel in all cases, but the creator argues that if you're not following exact semantics now, you're relying on your tests to ensure proper behavior, so use something that is at least more minimal and keeps your bundle size down.
So when you're writing code and bundling with rollup, you can pretty much ensure everything works fine, but as soon as you pull in an extensive third-party library you have no assurances that it has been tested with rollup and will work correctly in all cases. In the worst case, it will seem to work fine but in weird situations will actually error out. This was my experience with rollup.
Most of the code here is actually from lodash due to the use of `throttle`, not either of the projects you mentioned.
kudos for in-view's demo page though
Does Rollup produce a more efficient bundle in your experience?
Minified (1.49kb) and gzipped (677b).
Whether lodash functions should be used instead of naive functions is up for debate. My opinion is if the lodash functions are 5x the size of the entire library, it's probably best to not include it, or to include it as a build option (if the user's project already includes lodash for example).
Assuming the current setup of babel+webpack the difference between your naive version is just ~0.5 kB.
You can generally get smaller bundles using `lodash/xyz` modules over the `lodash.xyz` packages because of plugins like:
https://github.com/lodash/babel-plugin-lodash
https://github.com/lodash/lodash-webpack-plugin
Though in the future lodash-webpack-plugin may support `lodash.xyz` packages too.
import throttle from 'lodash/throttle';
import { throttle } from 'lodash';Or Bublé[1] ;) which i've found to be much faster than Babel, even for relatively small codebases (~ a couple thousand LoC).