5 ms·

I think https://vitejs.dev/ https://vitejs.dev/ is better. It pulls in a much smaller set of packages for a hello-world non-CRA react app. I think it was someth

I think https://vitejs.dev/ https://vitejs.dev/ is better. It pulls in a much smaller set of packages for a hello-world non-CRA react app. I think it was something like 1.3k lines of yarn.lock for Vite vs 6k lines for Parcel v2. JS projects shouldn't be bloated, even if this would get optimized-out for production. In the ideal world, you would use esbuild only, but you still need the other features for development: hot reload, hot module repalcement, and pretty error pages when you cause a RuntimeError.

benatkin 5y ago
vite uses Rollup, and I think it's probably better too. When I see zero configuration I become less interested in a project, because I like being able to configure things. Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build." https://vitejs.dev/guide/api-plugin.html https://vitejs.dev/guide/api-plugin.html
- devongovett 5y ago
  Parcel 2 does both: it is useful out of the box, and many projects will never need to configure it, but v2 adds a complete plugin system that lets you override and configure everything too. :)
  - benatkin 5y ago
    Good to hear! I'll give it a look.
- catlifeonmars 5y ago
  I don’t think zero configuration is mutually exclusive with full configuration control. Zero config is often just a design exercise in setting reasonable defaults on top of a configurable system.
  - benatkin 5y ago
    It could be argued that Vite is zero config because it allows you to go without a configuration file, but it says "zero config" nowhere on the site. It isn't because I want there to always be some configuration that I avoid zero config, it's because I've seen some projects like Next.js reject requests for a configuration setting that I thought were good and it has turned me off to the idea of "zero config". https://github.com/vercel/next.js/issues/7315 https://github.com/vercel/next.js/issues/7315 https://github.com/vercel/next.js/issues/1109 https://github.com/vercel/next.js/issues/1109 https://github.com/vercel/next.js/issues/13268 https://github.com/vercel/next.js/issues/13268
    - catlifeonmars 5y ago
      I get that. Curious, what do you think of prettier, which appears to philosophically align with next.js based on the issues you linked? Personally, prettier is more palatable specifically because it does one thing.
hsn915 5y ago
In the real world, you can use esbuild only. You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly. hot reload is really bad with slow bundlers. One of the projects I have to maintain at work has this hot reload feature. Here's how it goes: I edit a sass file, it recompiles in the background for 5 seconds, then reloads 4 or 5 times. Why? Who knows.
- eyelidlessness 5y ago
  > You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly. You don’t actually need any of these tools. But HMR is useful not because build time is slow (even if it often is), but because dev/validation iteration is slow too. TDD can improve some of that, but when you’re iterating on something interactive and want to validate the experience of it (or any number of other circumstances where manual validation provides value), having your setup state preserved can mean the difference between split second validation (with fast tooling) and completely breaking flow.
  - hsn915 5y ago
    What do you mean by "dev/validation iteration"?
    - snorremd 5y ago
      Say you're developing a big form with lots of different inputs. When you're iterating on the form you don't want to lose all your form state because you edited some code. When you make the change you want to see what that change does to your form in its current state.
      - renke1 5y ago
        That's very true. I think the most frustrating thing (that I regularly see) is people trying to do a minor fix in a wizard (let's say on the 5th step) and going through every step again just to see if the bug was fixed. Things like HMR can help here. That's why things like mock-service-worker or having prefilled Redux stores (or whatever state management you use that allows something similar) are a real time saver. Of course fixing the bug based on test is always better, but often you have to fix something visual which is a little bit harder to do with tests.

benatkin 5y ago

vite uses Rollup, and I think it's probably better too. When I see zero configuration I become less interested in a project, because I like being able to configure things. Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build." https://vitejs.dev/guide/api-plugin.html https://vitejs.dev/guide/api-plugin.html

devongovett 5y ago
Parcel 2 does both: it is useful out of the box, and many projects will never need to configure it, but v2 adds a complete plugin system that lets you override and configure everything too. :)
- benatkin 5y ago
  Good to hear! I'll give it a look.
catlifeonmars 5y ago
I don’t think zero configuration is mutually exclusive with full configuration control. Zero config is often just a design exercise in setting reasonable defaults on top of a configurable system.
- benatkin 5y ago
  It could be argued that Vite is zero config because it allows you to go without a configuration file, but it says "zero config" nowhere on the site. It isn't because I want there to always be some configuration that I avoid zero config, it's because I've seen some projects like Next.js reject requests for a configuration setting that I thought were good and it has turned me off to the idea of "zero config". https://github.com/vercel/next.js/issues/7315 https://github.com/vercel/next.js/issues/7315 https://github.com/vercel/next.js/issues/1109 https://github.com/vercel/next.js/issues/1109 https://github.com/vercel/next.js/issues/13268 https://github.com/vercel/next.js/issues/13268
  - catlifeonmars 5y ago
    I get that. Curious, what do you think of prettier, which appears to philosophically align with next.js based on the issues you linked? Personally, prettier is more palatable specifically because it does one thing.

hsn915 5y ago

In the real world, you can use esbuild only. You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly. hot reload is really bad with slow bundlers. One of the projects I have to maintain at work has this hot reload feature. Here's how it goes: I edit a sass file, it recompiles in the background for 5 seconds, then reloads 4 or 5 times. Why? Who knows.

eyelidlessness 5y ago
> You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly. You don’t actually need any of these tools. But HMR is useful not because build time is slow (even if it often is), but because dev/validation iteration is slow too. TDD can improve some of that, but when you’re iterating on something interactive and want to validate the experience of it (or any number of other circumstances where manual validation provides value), having your setup state preserved can mean the difference between split second validation (with fast tooling) and completely breaking flow.
- hsn915 5y ago
  What do you mean by "dev/validation iteration"?
  - snorremd 5y ago
    Say you're developing a big form with lots of different inputs. When you're iterating on the form you don't want to lose all your form state because you edited some code. When you make the change you want to see what that change does to your form in its current state.
    - renke1 5y ago
      That's very true. I think the most frustrating thing (that I regularly see) is people trying to do a minor fix in a wizard (let's say on the 5th step) and going through every step again just to see if the bug was fixed. Things like HMR can help here. That's why things like mock-service-worker or having prefilled Redux stores (or whatever state management you use that allows something similar) are a real time saver. Of course fixing the bug based on test is always better, but often you have to fix something visual which is a little bit harder to do with tests.