3 ms·

last time I tried to use Rollup, I found that it was very focused on NodeJS libs rather than frontend projects where Webpack (or other tools that bill themselve

last time I tried to use Rollup, I found that it was very focused on NodeJS libs rather than frontend projects where Webpack (or other tools that bill themselves as "bundlers") is used more often. After a few "oh, rollup doesn't do that by default, guess I need this plugin"-situations, I switched back to Parcel. Has that changed? Was I just not using it right or didn't read the right rollup-for-the-web documentation?

tazard 6y ago
That hasn't been my experience at all, in fact recent tools such as vite and snowpack are built on using rollup for frontend projects. You do need to install the plugins you want to use as they aren't all available out of the box, but generally I haven't had any troubles and basically just stick to the official plugins.
tehbeard 6y ago
Rollup isn't focused on node, if it was commonJS support would be bundled into the code. It's got a small and focused core that aims for esm (I regard the other output formats supported as esm -> that format). You do need to plug stuff in rather than having a batteries included experience. But that is a strength imo where you want to worry only about what you need. I do recommend adapting an existing config when using it in a new project, or creating your own templates/"create-x-app" wrapper. I use it for my home projects, and several work ones. It's "lower level" than Babel or parcel but that means I can set it up to compile both a lean, modern esm build, and a legacy IE11 compatible polyfilled systemJS bundle much easier than I can in webpack with its proprietary bundle format or parcels zero config. I will admit that node resolve and commonJs rollup plugins are pretty much a required part to work within the npm ecosystem right now, so it is a bit more boilerplate-y than I'd like.
- hardwaresofton 6y ago
  Thanks for noting this -- I ought to give it another try in the near future.
zamalek 6y ago
I use NodeJS exclusively for running Rollup (I'm using Rust for the back-end), and I use Rollup exclusively for the front-end bundling (TS, SCSS, Babel, SVGO, minifiers). Have a look at the Svelte templates, they all use Rollup. Configuring Rollup is far more straightforward than Webpack and source maps just work. I'm pretty sure you'll like it.
- hardwaresofton 6y ago
  I need to give it another try -- I end up separating my front and backend codebases completely so while I don't have to worry about mixing, I did find that Rollup was more complicated than Parcel so I just went with Parcel. Out of curiosity, what are you using as your HTTP server library/framework for Rust? At this point I've used a bunch of them (maybe 3/6+ that are out there) and am curious what others are using.
  - zamalek 6y ago
    What I've tried for this project (in chronological order): * Gotham. Pros: very clean. Cons: lots of boilerplate code. * Actix-web: Pros: very little happy-path boilerplate code. Fastest framework right now. Cons: error handling is just awful - I struggled to get `?` to work. Glacial compilation times. * Rocket (0.5 direct Git dependency). Pros: route handlers almost entirely consist of logic I care about, even for errors. Feels very deliberately "rusty." Cons: no HTTP2. No websockets. It has been accused of being "too magic." Each resulted in a ~20% reduction in LOC. I tend toward getting shit done, so I'm over the moon with Rocket.
    - hardwaresofton 6y ago
      Thanks for sharing -- for me: * actix-web: Pros: good docs, well supported, good eco system, Actor model fits very well with how I build systems (Actor ~= Component) Cons: some ceremony around setup of the app object * tower-web Pros: good ergonomics, much easier to wrangle app state Cons: all-in-one macro is a bit hard to reason about, hard to split up bits of API (I might have just not known enough about how to break up the impl_web! macro) * warp Pros: express-y (req, resp) => result interface, surprisingly feature complete (http2, sse, websockets) due to building off of simple interfaces/extension points, functional APIs that are easy to compose Cons: very new, kind of experimental, docs are a little lacking but examples help

tazard 6y ago

That hasn't been my experience at all, in fact recent tools such as vite and snowpack are built on using rollup for frontend projects. You do need to install the plugins you want to use as they aren't all available out of the box, but generally I haven't had any troubles and basically just stick to the official plugins.

tehbeard 6y ago

Rollup isn't focused on node, if it was commonJS support would be bundled into the code. It's got a small and focused core that aims for esm (I regard the other output formats supported as esm -> that format). You do need to plug stuff in rather than having a batteries included experience. But that is a strength imo where you want to worry only about what you need. I do recommend adapting an existing config when using it in a new project, or creating your own templates/"create-x-app" wrapper. I use it for my home projects, and several work ones. It's "lower level" than Babel or parcel but that means I can set it up to compile both a lean, modern esm build, and a legacy IE11 compatible polyfilled systemJS bundle much easier than I can in webpack with its proprietary bundle format or parcels zero config. I will admit that node resolve and commonJs rollup plugins are pretty much a required part to work within the npm ecosystem right now, so it is a bit more boilerplate-y than I'd like.

hardwaresofton 6y ago
Thanks for noting this -- I ought to give it another try in the near future.

zamalek 6y ago

I use NodeJS exclusively for running Rollup (I'm using Rust for the back-end), and I use Rollup exclusively for the front-end bundling (TS, SCSS, Babel, SVGO, minifiers). Have a look at the Svelte templates, they all use Rollup. Configuring Rollup is far more straightforward than Webpack and source maps just work. I'm pretty sure you'll like it.

hardwaresofton 6y ago
I need to give it another try -- I end up separating my front and backend codebases completely so while I don't have to worry about mixing, I did find that Rollup was more complicated than Parcel so I just went with Parcel. Out of curiosity, what are you using as your HTTP server library/framework for Rust? At this point I've used a bunch of them (maybe 3/6+ that are out there) and am curious what others are using.
- zamalek 6y ago
  What I've tried for this project (in chronological order): * Gotham. Pros: very clean. Cons: lots of boilerplate code. * Actix-web: Pros: very little happy-path boilerplate code. Fastest framework right now. Cons: error handling is just awful - I struggled to get `?` to work. Glacial compilation times. * Rocket (0.5 direct Git dependency). Pros: route handlers almost entirely consist of logic I care about, even for errors. Feels very deliberately "rusty." Cons: no HTTP2. No websockets. It has been accused of being "too magic." Each resulted in a ~20% reduction in LOC. I tend toward getting shit done, so I'm over the moon with Rocket.
  - hardwaresofton 6y ago
    Thanks for sharing -- for me: * actix-web: Pros: good docs, well supported, good eco system, Actor model fits very well with how I build systems (Actor ~= Component) Cons: some ceremony around setup of the app object * tower-web Pros: good ergonomics, much easier to wrangle app state Cons: all-in-one macro is a bit hard to reason about, hard to split up bits of API (I might have just not known enough about how to break up the impl_web! macro) * warp Pros: express-y (req, resp) => result interface, surprisingly feature complete (http2, sse, websockets) due to building off of simple interfaces/extension points, functional APIs that are easy to compose Cons: very new, kind of experimental, docs are a little lacking but examples help