4 ms·

> The production build metric here would be ESBuild + a small amount of overhead from vite. (The HMR/dev build side of things is handled by Rollup instead with

by oefrha 2y ago

> The production build metric here would be ESBuild + a small amount of overhead from vite. (The HMR/dev build side of things is handled by Rollup instead with Vite) That’s completely backwards. Vite only uses rollup for production, which is why production build is slower. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... The plan is to replace both esbuild and rollup with Rust-based rolldown (fast, and supports rollup’s plugin architecture) eventually. See https://www.youtube.com/watch?v=hrdwQHoAp0M https://www.youtube.com/watch?v=hrdwQHoAp0M.

graypegg 2y ago
Oops, yep you’re right, I mixed them up.
lenkite 2y ago
I suppose we should wait until all tools move to Rust/Zig before learning modern front-end engineering to bypass the churn phase. Till then stick to plain HTML+CSS.
- johnny22 2y ago
  for the basics you can just use vite and nothing will change except what's underneath. it's only when you get fancy that you need to write your own plugins that would really be affected by this churn.
- crabmusket 2y ago
  I've been using webpack for the last 7 years. Major version upgrades can be a pain, but broadly it's fine. People hopping frameworks every 6 months are causing their own problems.
  - alluro2 2y ago
    I fully agree with the sentiment - but for me there's also that I could remove 26 (!) dev dependencies and minutes off each build, in a medium-sized app, when replacing Webpack with Vite - so it's worth being in the loop at least to some extent.
    - crabmusket 2y ago
      Yep, that makes total sense. We're also looking at a Vite migration in the near future, but also making sure that whatever we do, we're leaning more on web standards and common functionality, and avoiding as much bundler specific stuff as possible. Back in the day is was cute that you could import GLSL fragments directly into your JS code. Now, not so much.
- pjmlp 2y ago
  And maybe then, we also get rid of node, and use compiled languages frameworks on the server.

by oefrha 2y ago

graypegg 2y ago

Oops, yep you’re right, I mixed them up.

lenkite 2y ago

I suppose we should wait until all tools move to Rust/Zig before learning modern front-end engineering to bypass the churn phase. Till then stick to plain HTML+CSS.

johnny22 2y ago
for the basics you can just use vite and nothing will change except what's underneath. it's only when you get fancy that you need to write your own plugins that would really be affected by this churn.
crabmusket 2y ago
I've been using webpack for the last 7 years. Major version upgrades can be a pain, but broadly it's fine. People hopping frameworks every 6 months are causing their own problems.
- alluro2 2y ago
  I fully agree with the sentiment - but for me there's also that I could remove 26 (!) dev dependencies and minutes off each build, in a medium-sized app, when replacing Webpack with Vite - so it's worth being in the loop at least to some extent.
  - crabmusket 2y ago
    Yep, that makes total sense. We're also looking at a Vite migration in the near future, but also making sure that whatever we do, we're leaning more on web standards and common functionality, and avoiding as much bundler specific stuff as possible. Back in the day is was cute that you could import GLSL fragments directly into your JS code. Now, not so much.
pjmlp 2y ago
And maybe then, we also get rid of node, and use compiled languages frameworks on the server.