4 ms·

Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). Sometimes there are npm packa

Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). Sometimes there are npm packages that are just wrappers for other projects, but those are usually short-lived and end up being rewritten in JS (except for C/C++ libraries, which neatly compile to native extensions directly). If anything, the common complaint is much more accurate: the tooling is rewritten from scratch too often.

kuschku 9y ago
> Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). How is that relevant? The problem is still that you end up with tools wrapped around tools wrapped around tools. Building a usual nodeJS project ends up with the callstack in my process explorer being 20 levels deep, of node processes, some bash mixed in, and inbetween ruby, python etc for building the documentation with mkdocs and the SASS or SCSS
philipodonnell 9y ago
Eh. Anything that stands between the raw code you write and the code running on the production serer is a "tool" that has to be managed, configured, etc... The implementation language isn't as important as the fact that the code you wrote requires tools written by third parties executing a sequence of intermediate steps to be in an executable form.
- couchand 9y ago
  Good point, we shoud all just arrange bits of machine code.
  - kuschku 9y ago
    No, but ideally you’d have 1 program you execute to transform your code into the final build, and that’s it. Maybe that program can be modular, but that’s it. Instead of precompiling Typescript and JSX to ES5, with Babel that to ES4, then launching dozens of asset processors to turn your SASS, SCSS, and JSS into CSS, with dozens of wrapped processes... As mentioned, the Java world handles everything with 2 processes, the C++ world with 3. Only the JS world manages to run in a single project webpack, gulp, grunt, compass, typescript, babel, and JSX, all transforming the source, leading to build times second only to old-school C++ projects.

kuschku 9y ago

> Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). How is that relevant? The problem is still that you end up with tools wrapped around tools wrapped around tools. Building a usual nodeJS project ends up with the callstack in my process explorer being 20 levels deep, of node processes, some bash mixed in, and inbetween ruby, python etc for building the documentation with mkdocs and the SASS or SCSS

philipodonnell 9y ago

Eh. Anything that stands between the raw code you write and the code running on the production serer is a "tool" that has to be managed, configured, etc... The implementation language isn't as important as the fact that the code you wrote requires tools written by third parties executing a sequence of intermediate steps to be in an executable form.

couchand 9y ago
Good point, we shoud all just arrange bits of machine code.
- kuschku 9y ago
  No, but ideally you’d have 1 program you execute to transform your code into the final build, and that’s it. Maybe that program can be modular, but that’s it. Instead of precompiling Typescript and JSX to ES5, with Babel that to ES4, then launching dozens of asset processors to turn your SASS, SCSS, and JSS into CSS, with dozens of wrapped processes... As mentioned, the Java world handles everything with 2 processes, the C++ world with 3. Only the JS world manages to run in a single project webpack, gulp, grunt, compass, typescript, babel, and JSX, all transforming the source, leading to build times second only to old-school C++ projects.