[danpalmer]

This looks nice, although in Redux's favour is a large ecosystem of libraries that will work with it. This highlights a problem I still have with the JS ecosystem, which is relatively tight coupling between libraries. Of course many of these libraries could be glued together manually without too much work, but with the rapidly changing ecosystem and APIs for interoperability between libraries, and the obscurity of some of the libraries (Redux being a good example), this is often just not practical.

Compare this to Elm and the Elm architecture, and it seems worlds apart. Interoperability between libraries that all works in the same straightforward way, checked by the compiler.

It feels like the JS community made a lot of good decisions for the right reasons, but still ended up in a place that isn't great.

[heygrady]

Babel is both the driving force of innovation and the cause of much of the fragmentation in JS. Babel allows you to use the latest language features and target the oldest environments. The trouble is that there's not a "right way" to package software to cover all of the deployment concerns. Code needs to work on Node going back several versions as well as browsers going back several versions. And for mobile/desktop websites, your code bundle size is extremely important. Rollup and Webpack 4 go a long way towards making this easier but it's nothing close to a "standard best way" to do it.

[danpalmer]

That's a good summary of the fragmentation and coupling in the build tools, but there's also the libraries themselves - React, Redux, React-Router, React-Router-Redux, etc etc.

[adamsea]

I have to agree. The webpack-blocks project seemed like a step in the right direction, as it lets you 'compose' a webpack config (in theory) without side effects. I recently discovered lerna and am curious about using it to put together "safe" bundles of libraries which are commonly used together. No idea if that's actually a practical approach or not - its all in the dreaming stage.