
JavaScript Fatigue? Or something more? - shruubi
https://shruubi.wordpress.com/2016/01/31/javascript-fatigue-or-something-more/
======
substack

        > 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.

------
pedalpete
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?

------
AstroJetson
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.

