3 comments

[ 2.7 ms ] story [ 14.8 ms ] thread
Good luck on getting a common method together. This kind of integration has always been a problem. This is one of the things that Java tried to overcome with the use of beans and jars. But even now a large application can have a hundred jars attached to it.
The think I've been thinking a bit about lately, is that aren't we writing the same structure again and again? Is your browserify that much different to mine? Oh wait, it is now because I'm using webpack. Ok, what about sass vs. less? Damn, more differences in set-up.

I've been wondering if it just makes more sense to have a module on github with these things set-up already. Maybe a few modules. Just grab the one that is 'most similar' to the tooling you want to use, and get up and running quickly.

Then you can customize if you want, but I would hope we could settle on 5 or 6 variations. Does every app really need a different structure for where they put their static assets vs. compiled?

    > Imagine being able to download just one build tool that by 
    > default allows you to write something like
    > ‘jsc /some/js/dir -o /some/build/dir –enable-jsx’

    $ npm install --save browserify babelify babel-preset-es2015 babel-preset-react
    $ browserify -t [ babelify --presets [ es2015 react ] ] \
      main.js -o public/bundle.js
To incrementally recompile when a file changes: `npm install --save watchify` and replace `browserify` with `watchify` above.

There are sets of tools that compose well and are easy to set up. I think developers hear about all these new techniques and think they need all of them, but it's much more important to know what you don't need and how to incrementally add pieces in small steps only when you need them and not before.