5 ms·

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

by nightski 4y ago

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.

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.