5 ms·

Edit: There's some more discussion about Turbopack at https://news.ycombinator.com/item?id=33333695 https://news.ycombinator.com/item?id=33333695. Looks like t

Edit: There's some more discussion about Turbopack at https://news.ycombinator.com/item?id=33333695 https://news.ycombinator.com/item?id=33333695. Looks like they launched a webpack alternative called Turbopack today: > Next.js 13 includes Turbopack, the new Rust-based successor to Webpack. https://vercel.com/blog/turbopack https://vercel.com/blog/turbopack https://turbo.build/pack https://turbo.build/pack

nightski 4y ago
Sigh another one? I thought Vite was the new thing.
- AlmostAnyone 4y ago
  Sigh? I think the speed improvement is awesome.
  - hirop 4y ago
    It is awesome to see so much innovation, but it can be exhausting to keep up.
  - apozem 4y ago
    I'm quite alright with new tooling every six months when the new thing is orders of magnitude faster. If people want to compete to make my job as a frontend dev easier and faster, that is just fine.
    - nightski 4y ago
      Ideally we could learn how to make the existing tools better/faster and create software that can evolve rather than re-writing everything from scratch every six months.
      - yboris 4y ago
        I suspect at some point we hit the limit of the language performance. I can't imagine JavaScript beating Rust when both are written well.
      - AlmostAnyone 4y ago
        There was many years before people started trying to replace Webpack.
        nightski 4y ago
        True but webpack itself had a ton of churn and made practically no effort to maintain backwards compatibility causing a ton of work with each major update.
        AlmostAnyone 4y ago
        Hmm, I am using it since v2 and I disagree, it was not so bad. I saw a lot of people had overcomplicated configs that could be simplified a lot, I guess those had some problems upgrading... But mine never had much problems (and not just because my needs were simple...), I just removed some options when going to v4 and that's about it.
- pull_my_finger 4y ago
  I think the issue starts when xyz new tool requires you to write code specific to that thing, which is something I avoid as much as possible. IMO they should strive to stay out of the way as much as possible and just bundle/optimize/tree-shake and not worry about extending JS as a language or nodejs as a runtime or doubling as a build tool or a filewatcher or a development server etc etc (see the UNIX philosophy 'do one thing well'), even at the expense of less optimal/fast builds. As soon as you start doing stuff like importing your images into your javascript so your bundler can do compiler tricks, you're painting yourself into the corner. One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.
  - jfoster 4y ago
    There's a few facets to consider: 1. Does code written a particular way? 2. Does it need to be configured? 3. Does it conflict with other tooling? 4. Does it have limitations that are too restrictive? 5. Does it cause bugs/issues that are difficult to resolve? The ideal tool just does its thing, doesn't need any code written or configuration, works no matter what other tooling you're using, has no limitations, and will never itself cause a bug. That might not be realistic to do 100%, but I think it's what all tools should be aiming for.
dhruvarora013 4y ago
Spent the last few months migrating to Vite. The Javascript ecosystem is exhausting and exhilarating all at the same time
- RunSet 4y ago
  No telling how many sides the next iteration of the wheel may have but one thing's for certain: That one will be the ultimate version.
- toinewx 4y ago
  Well at least Vite does not lock you in the Next.js eco-system, so it's something ¯\_(ツ)_/¯.
- strangescript 4y ago
  Overall the community is starting to embrace better languages for tooling, primarily Rust with some Go and Zig sprinkled in. Eventually I think we will hit a point where there will be a defacto dev tool that can take a web app and package it however you want, deploy it wherever you want, and do it very quickly. Some would argue those exist now, but until it can be done literally everywhere, painlessly, I would contend we aren't there yet. It's probably more likely something like WASM/WASI takes over before then honestly.
- kyriakos 4y ago
  What I hate about javascript fatigue is that there's never enough time for something to mature before it gets replaced. Documentation always covers the basic scenarios and never any edge cases. Sooner or later you end up trying to find a solution in a github issue 20 pages down.
  - mmis1000 4y ago
    I think webpack is a special exception. It somehow revised the whole 5 major version and still don't get a proper plugin development document at all, not even basic one. You don't even have a flow graph that tells you events happen in which order. Everyone either Google and copy paste random example or reading the source by themselves. It always amazed me that such a big project can just live without docs.
pastor_bob 4y ago
>On an application with 3,000 modules, Turbopack takes 1.8 seconds to boot up, while Vite takes 11.4 seconds. How many apps are dealing with 3,000+ modules?
- Joeri 4y ago
  At the pace the javascript ecosystem is going, by next year it will be almost all of them. Create react app for a new default project pulls in 1400 packages, 300 MB in size, just to put a hello world page on a screen. That nobody thinks this is absolutely bonkers drives me absolutely bonkers.
  - tr1ll10nb1ll 4y ago
    Informed developers don't use CRA anymore.
  - deleted 4y ago
    [deleted]
  - reducesuffering 4y ago
    Plenty of people think it's bonkers and the informed frontend perspective is to not use CRA anymore: https://www.youtube.com/watch?v=7m14f0ZzMyY https://www.youtube.com/watch?v=7m14f0ZzMyY

nightski 4y ago

Sigh another one? I thought Vite was the new thing.

AlmostAnyone 4y ago
Sigh? I think the speed improvement is awesome.
- hirop 4y ago
  It is awesome to see so much innovation, but it can be exhausting to keep up.
- apozem 4y ago
  I'm quite alright with new tooling every six months when the new thing is orders of magnitude faster. If people want to compete to make my job as a frontend dev easier and faster, that is just fine.
  - nightski 4y ago
    Ideally we could learn how to make the existing tools better/faster and create software that can evolve rather than re-writing everything from scratch every six months.
    - yboris 4y ago
      I suspect at some point we hit the limit of the language performance. I can't imagine JavaScript beating Rust when both are written well.
    - AlmostAnyone 4y ago
      There was many years before people started trying to replace Webpack.
      - nightski 4y ago
        True but webpack itself had a ton of churn and made practically no effort to maintain backwards compatibility causing a ton of work with each major update.
        AlmostAnyone 4y ago
        Hmm, I am using it since v2 and I disagree, it was not so bad. I saw a lot of people had overcomplicated configs that could be simplified a lot, I guess those had some problems upgrading... But mine never had much problems (and not just because my needs were simple...), I just removed some options when going to v4 and that's about it.
pull_my_finger 4y ago
I think the issue starts when xyz new tool requires you to write code specific to that thing, which is something I avoid as much as possible. IMO they should strive to stay out of the way as much as possible and just bundle/optimize/tree-shake and not worry about extending JS as a language or nodejs as a runtime or doubling as a build tool or a filewatcher or a development server etc etc (see the UNIX philosophy 'do one thing well'), even at the expense of less optimal/fast builds. As soon as you start doing stuff like importing your images into your javascript so your bundler can do compiler tricks, you're painting yourself into the corner. One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.
- jfoster 4y ago
  There's a few facets to consider: 1. Does code written a particular way? 2. Does it need to be configured? 3. Does it conflict with other tooling? 4. Does it have limitations that are too restrictive? 5. Does it cause bugs/issues that are difficult to resolve? The ideal tool just does its thing, doesn't need any code written or configuration, works no matter what other tooling you're using, has no limitations, and will never itself cause a bug. That might not be realistic to do 100%, but I think it's what all tools should be aiming for.

dhruvarora013 4y ago

Spent the last few months migrating to Vite. The Javascript ecosystem is exhausting and exhilarating all at the same time

RunSet 4y ago
No telling how many sides the next iteration of the wheel may have but one thing's for certain: That one will be the ultimate version.
toinewx 4y ago
Well at least Vite does not lock you in the Next.js eco-system, so it's something ¯\_(ツ)_/¯.
strangescript 4y ago
Overall the community is starting to embrace better languages for tooling, primarily Rust with some Go and Zig sprinkled in. Eventually I think we will hit a point where there will be a defacto dev tool that can take a web app and package it however you want, deploy it wherever you want, and do it very quickly. Some would argue those exist now, but until it can be done literally everywhere, painlessly, I would contend we aren't there yet. It's probably more likely something like WASM/WASI takes over before then honestly.
kyriakos 4y ago
What I hate about javascript fatigue is that there's never enough time for something to mature before it gets replaced. Documentation always covers the basic scenarios and never any edge cases. Sooner or later you end up trying to find a solution in a github issue 20 pages down.
- mmis1000 4y ago
  I think webpack is a special exception. It somehow revised the whole 5 major version and still don't get a proper plugin development document at all, not even basic one. You don't even have a flow graph that tells you events happen in which order. Everyone either Google and copy paste random example or reading the source by themselves. It always amazed me that such a big project can just live without docs.

pastor_bob 4y ago

>On an application with 3,000 modules, Turbopack takes 1.8 seconds to boot up, while Vite takes 11.4 seconds. How many apps are dealing with 3,000+ modules?

Joeri 4y ago
At the pace the javascript ecosystem is going, by next year it will be almost all of them. Create react app for a new default project pulls in 1400 packages, 300 MB in size, just to put a hello world page on a screen. That nobody thinks this is absolutely bonkers drives me absolutely bonkers.
- tr1ll10nb1ll 4y ago
  Informed developers don't use CRA anymore.
- deleted 4y ago
  [deleted]
- reducesuffering 4y ago
  Plenty of people think it's bonkers and the informed frontend perspective is to not use CRA anymore: https://www.youtube.com/watch?v=7m14f0ZzMyY https://www.youtube.com/watch?v=7m14f0ZzMyY