7 ms·

Javascript has the same problem, but I think its worse. At least there are platform standards in C (autotools in GNU, msbuild on Win). Trying to figure out how

by kibibu 11y ago

Javascript has the same problem, but I think its worse. At least there are platform standards in C (autotools in GNU, msbuild on Win). Trying to figure out how Grunt/Gulp/Broccoli, LESS/SASS/Stylus/Jade, Coffeescript, Uglify, Bower, Browserify, Require.js, AMD/CommonJS, NPM etc all work together is a nightmare. It's all too hard, so people added Yeoman, Brunch, or other things to generate application configs - but now you need to decide which skeleton/generator you want, which takes you down the JS and CSS framework rabbithole. Of course the only sane response to all this is to write another build system that doesn't repeat everybody else's mistakes. In comparison, Makefiles are remarkably usable.

voltagex_ 11y ago
Yep. I'm more comfortable with Make than I am with JSPM/NPM and System.js. The process to minify my javascript and CSS and then replace the paths in the HTML so my pages actually work seems to be needlessly complex. I'm seriously considering whether I can use Make for my production website builds - the only issue is Windows support.
- Gibbon1 11y ago
  You have a couple of options with make under windows. There are native versions of make. Where you are using dos shell commands to do stuff. MinGW provides Posix compatible native commands. (you can use ls, cat, etc commands). You can use msys which gives you a Posix compatible build env. Finally something like Cigwin provides both a Posix compatible build env and Posix compatible runtime as well.
- TheAceOfHearts 11y ago
  Try out webpack. Webpack makes handling all of your assets into something trivial. I converted around 3,000 lines of Gulp files into a 200 line webpack config. (Most of which ended up being alises, and this is a reasonably big project.) For an example of what makes it so awesome: var img = require('./foo.png') // "/output-path/0dcbbaa701328a3c262cfd45869e351f.png" Webpack will copy this file (foo.png) to your output folder, and rename it using the file hash, so it does cache-busting. You don't need to use other build tools, you can just use the webpack CLI. I personally use npm scripts. Webpack also allows you to setup aliases for modules, as well as load pretty much anything you can imagine. You wanna pull in a module that doesn't use CommonJS and instead exports a global? Webpack has global-loader. AMD is supported as well. Oh, and this includes a sane development environment, with reload on save, as well as hot loading assets that support it. (Check out react-hot-loader: http://gaearon.github.io/react-hot-loader/ http://gaearon.github.io/react-hot-loader/, but it works with css as well.) And you can require css files in your components, and then add the extract-text-webpack-plugin so it'll rip the css from the generated JS bundle! Aaaaand it handles SourceMaps, so you don't have to worry about some plugins (looking at you gulp) not playing well together. Finally, it also handles minification, either through a CLI option or in the config.
laichzeit0 11y ago
I'm a C guy, and I never "worry" that if I have to recompile a project I worked on 1 or 2 years ago that I'm going to have to fight the toolchain to get it going again. Make will be make, and it will work. I have a huge concern when I do anything in Javascript about what happens in 1 or 2 years from now when I have to modify a project I built using some Yeoman scaffolding. Is it still going to work? Will those node modules still be there? Can I update them without it breaking everything? It's really weird for me, coming from the world of C, CVS/Git, Make, Linux, etc. where it's almost _unthinkable_ to introduce changes that would break older versions. Hell even the world "old" generally means 5+ or 10+ years.
- Sacho 11y ago
  I don't understand. You can configure your node module to use specific versions of libraries just like a C project. Surely you've heard of problems people have with dynamic linkage and their programs not working? This is why distros spend so much time getting things to work with each other - I think you're just sweeping that under the rug. The tools you're working with aren't different on this manner - it's not like your tool will magically recode itself to work differently.

by kibibu 11y ago

voltagex_ 11y ago

Yep. I'm more comfortable with Make than I am with JSPM/NPM and System.js. The process to minify my javascript and CSS and then replace the paths in the HTML so my pages actually work seems to be needlessly complex. I'm seriously considering whether I can use Make for my production website builds - the only issue is Windows support.

Gibbon1 11y ago
You have a couple of options with make under windows. There are native versions of make. Where you are using dos shell commands to do stuff. MinGW provides Posix compatible native commands. (you can use ls, cat, etc commands). You can use msys which gives you a Posix compatible build env. Finally something like Cigwin provides both a Posix compatible build env and Posix compatible runtime as well.
TheAceOfHearts 11y ago
Try out webpack. Webpack makes handling all of your assets into something trivial. I converted around 3,000 lines of Gulp files into a 200 line webpack config. (Most of which ended up being alises, and this is a reasonably big project.) For an example of what makes it so awesome: var img = require('./foo.png') // "/output-path/0dcbbaa701328a3c262cfd45869e351f.png" Webpack will copy this file (foo.png) to your output folder, and rename it using the file hash, so it does cache-busting. You don't need to use other build tools, you can just use the webpack CLI. I personally use npm scripts. Webpack also allows you to setup aliases for modules, as well as load pretty much anything you can imagine. You wanna pull in a module that doesn't use CommonJS and instead exports a global? Webpack has global-loader. AMD is supported as well. Oh, and this includes a sane development environment, with reload on save, as well as hot loading assets that support it. (Check out react-hot-loader: http://gaearon.github.io/react-hot-loader/ http://gaearon.github.io/react-hot-loader/, but it works with css as well.) And you can require css files in your components, and then add the extract-text-webpack-plugin so it'll rip the css from the generated JS bundle! Aaaaand it handles SourceMaps, so you don't have to worry about some plugins (looking at you gulp) not playing well together. Finally, it also handles minification, either through a CLI option or in the config.

laichzeit0 11y ago

I'm a C guy, and I never "worry" that if I have to recompile a project I worked on 1 or 2 years ago that I'm going to have to fight the toolchain to get it going again. Make will be make, and it will work. I have a huge concern when I do anything in Javascript about what happens in 1 or 2 years from now when I have to modify a project I built using some Yeoman scaffolding. Is it still going to work? Will those node modules still be there? Can I update them without it breaking everything? It's really weird for me, coming from the world of C, CVS/Git, Make, Linux, etc. where it's almost _unthinkable_ to introduce changes that would break older versions. Hell even the world "old" generally means 5+ or 10+ years.

Sacho 11y ago
I don't understand. You can configure your node module to use specific versions of libraries just like a C project. Surely you've heard of problems people have with dynamic linkage and their programs not working? This is why distros spend so much time getting things to work with each other - I think you're just sweeping that under the rug. The tools you're working with aren't different on this manner - it's not like your tool will magically recode itself to work differently.