https://github.com/Jon-Biz/simple-static-react-firebase/blob...
Sorry, but with those many dependencies, I could hardly call that minimal.
Sorry, but with those many dependencies, I could hardly call that minimal.
That said, leveraging Browserify, Bubleify[0] and Ramda[1] alone can get you pretty far in a seriously maintainable way with modern code, which is super nice: keeps compile times stupid quick and reduces some of the cognitive overhead (and possible maintenance drama) that too many third-party deps introduce.
There's a balance to be struck here, and it's a hard problem, I think.
For me, a minimal stack is just an HTML file(possible with a JS file as well) that loads React and Firebase via CDN, and then relies on browser's shipped ES6 capabilities to write code.
But in that sense I might be trolling here since nobody actually does that :)
And, only React, ReactDom and Firebase (which has to be required in the page html, unfortunately, due to Firebase issues) actually ship down to th client
While I can appreciate the benefit of keeping your entire codebase small (especially the bits that aren't yours), I'm not entirely certain of the wisdom of trying to build a react/es6/less/sass transpiling development environment with as few external dependencies as possible :)
babel-core, babel-loader, babel-polyfill, babel-preset-es2015 and babel-preset-react can be considered one dependency (it's babel...).
react and react-dom are another.
webpack, the dev server, and 3 webpack plugins can be considered a 3rd.
That's 3 "real" dependencies. If that's a lot, then i'd love to see a "real" minimal setup.
Just because javascript dependencies tend to take the unix philosophy to the extreme doesn't mean that each of those should be treated equally.
IMO JS hits all of the points of the unix philosophy:
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
Following that, babel reducing its "main" code down to a "useless on it's own" core, and allowing all functionality via plugins fits perfectly in that ideal. Then there are "presets" which can be built on top of them to include many of those plugins as one dependency, and a package to polyfill things that can't be "compiled" at compile time (babel-polyfill).
If i don't care about optimization, i can just throw everything in there and it'll work. If i want to cut down on the size, i can look at my target browsers and drop things (like babel-polyfill, or in some cases even most of the plugins from the babel-preset-es2015), and can install and run only what is needed.
it also makes writing new features into something like babel simple as hell, you can do it in a 10 line plugin. That makes it extremely simple to avoid bloating other plugins with options/features and instead encourages new plugins that do what the option/feature wanted.