4 ms·

Makes sense to me. We should be using the best tool for the job, and JavaScript isn't always the best tool.

patates 5y ago
Exactly, as when it comes to transpilers, it's unlikely that you can eat your own dog food anyway - as in, compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell.
- numlock86 5y ago
  > compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell Isn't that the workflow when working with/on TypeScript? (substitute webpack with TypeScript)
  - patates 5y ago
    It does make sense with TypeScript as it's a language. It, however, does not make sense with "tooling" (IMHO - there may be of course obvious stuff I may be missing). Tooling may also use a transpiled language but again, I, as a developer who's very experienced with JS, don't see a big win there. Someone mentioned Flow + OCaml as a bad example and how it doesn't work out for them, but that's more than tooling. At that point you are not using tools written in other languages to build JS, you are just using other languages.
    - de_keyboard 5y ago
      Flow failed because Microsoft enabled TypeScript by default in VS Code. It had nothing to do with OCaml in my opinion. However, TypeScript is now suffering from long compile-times because it targets JS. If it was implemented in a language with more control over threading etc. I think it could be faster.
      - patates 5y ago
        I think there were attempts to rewrite a subset of TS in another language. I don't mean assemblyscript, no. Also, if I could use TS on the backend without node (say, with the lib/runtime of another language), that would be amazing.
        guipsp 5y ago
        Deno exists, I guess
  - IshKebab 5y ago
    Yeah and Typescript's type checker code is one 41k line file because if they split it into multiple files it will be slower. `tsc` is pretty great to be honest but it feels like the exception.
- capableweb 5y ago
  > compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell. Could you explain further why you think so? Dogfooding tooling and bootstrapping runtimes with themselves is a fairly common practice, at least for discovering issues, bugs and future features for your own project.
  - patates 5y ago
    Runtimes, sure, but how do you dogfood tooling that transpiles JS to JS for frontend?
    - capableweb 5y ago
      Supposedly since webpack is using JS, they would also benefit from using later features than what's available in NodeJS stable, so they can use webpack to transpile future ES versions to compatible code so it can run on more NodeJS versions. Then that those features can both be used for frontend or backend code matters less, as the new JS features are usually not geared to a specific environment but for JS as a whole.
      - patates 5y ago
        webpack is web-oriented though. While what you are saying is right, for a project which aims to keep web as its focus, this would perhaps not be the best way forward. When we also look the the codebase, they are not using webpack for webpack development, and using commonjs imports instead. The "modern JS" part of webpack comes from Babel and Babel uses TS (though still in progress). So dogfooding here isn't used by major projects, and I think we can see a pattern. For a formatting tool, I would agree with you more, but again, for a tool, wouldn't the formatting of the code of the tool itself be a distraction? It may be or it may be not, it depends, but the benefits are less clear for tooling.
capableweb 5y ago
The thing is, what the "best" tool is, is relative to your requirements. I much prefer "Use the right tool for the job", as it makes it less cargo-culty and emphasizes that it's not always right. For example, if your build process is very slow and you for some reason have to have it be very fast, esbuild is probably the right tool. But if instead your goal is to build a large community of developers who can change their own tooling, webpack is probably the right tool as it's by JS developers, for JS developers. Overall I agree with you, just nitpicking a bit I guess :)
- de_keyboard 5y ago
  > The thing is, what the "best" tool is, is relative to your requirements. Yes I agree, but I think my point still stands :)
  - capableweb 5y ago
    Oh yes, I wasn't disagreeing with you, more filling out a shared opinion :)

Exactly, as when it comes to transpilers, it's unlikely that you can eat your own dog food anyway - as in, compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell.

numlock86 5y ago
> compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell Isn't that the workflow when working with/on TypeScript? (substitute webpack with TypeScript)
- patates 5y ago
  It does make sense with TypeScript as it's a language. It, however, does not make sense with "tooling" (IMHO - there may be of course obvious stuff I may be missing). Tooling may also use a transpiled language but again, I, as a developer who's very experienced with JS, don't see a big win there. Someone mentioned Flow + OCaml as a bad example and how it doesn't work out for them, but that's more than tooling. At that point you are not using tools written in other languages to build JS, you are just using other languages.
  - de_keyboard 5y ago
    Flow failed because Microsoft enabled TypeScript by default in VS Code. It had nothing to do with OCaml in my opinion. However, TypeScript is now suffering from long compile-times because it targets JS. If it was implemented in a language with more control over threading etc. I think it could be faster.
    - patates 5y ago
      I think there were attempts to rewrite a subset of TS in another language. I don't mean assemblyscript, no. Also, if I could use TS on the backend without node (say, with the lib/runtime of another language), that would be amazing.
      - guipsp 5y ago
        Deno exists, I guess
- IshKebab 5y ago
  Yeah and Typescript's type checker code is one 41k line file because if they split it into multiple files it will be slower. `tsc` is pretty great to be honest but it feels like the exception.
capableweb 5y ago
> compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell. Could you explain further why you think so? Dogfooding tooling and bootstrapping runtimes with themselves is a fairly common practice, at least for discovering issues, bugs and future features for your own project.
- patates 5y ago
  Runtimes, sure, but how do you dogfood tooling that transpiles JS to JS for frontend?
  - capableweb 5y ago
    Supposedly since webpack is using JS, they would also benefit from using later features than what's available in NodeJS stable, so they can use webpack to transpile future ES versions to compatible code so it can run on more NodeJS versions. Then that those features can both be used for frontend or backend code matters less, as the new JS features are usually not geared to a specific environment but for JS as a whole.
    - patates 5y ago
      webpack is web-oriented though. While what you are saying is right, for a project which aims to keep web as its focus, this would perhaps not be the best way forward. When we also look the the codebase, they are not using webpack for webpack development, and using commonjs imports instead. The "modern JS" part of webpack comes from Babel and Babel uses TS (though still in progress). So dogfooding here isn't used by major projects, and I think we can see a pattern. For a formatting tool, I would agree with you more, but again, for a tool, wouldn't the formatting of the code of the tool itself be a distraction? It may be or it may be not, it depends, but the benefits are less clear for tooling.

capableweb 5y ago

The thing is, what the "best" tool is, is relative to your requirements. I much prefer "Use the right tool for the job", as it makes it less cargo-culty and emphasizes that it's not always right. For example, if your build process is very slow and you for some reason have to have it be very fast, esbuild is probably the right tool. But if instead your goal is to build a large community of developers who can change their own tooling, webpack is probably the right tool as it's by JS developers, for JS developers. Overall I agree with you, just nitpicking a bit I guess :)

de_keyboard 5y ago
> The thing is, what the "best" tool is, is relative to your requirements. Yes I agree, but I think my point still stands :)
- capableweb 5y ago
  Oh yes, I wasn't disagreeing with you, more filling out a shared opinion :)