Echo JS 0.11.0

This sounds similar to how the `react-icons` package works, in fact, many of those components could have been used to wrap their own SVG icons.

I don't have anything... I had to do some checks for the actual route, the router, and in the redux engine... It was about 6 months ago tbh and I just remember it was wild getting it to sync between the router and the redux... I had to hack a listener for route changes, then trigger an action into the store.

I'm not longer working in the group that was on the project...

One of the hardest issues I had with redux + ng2 was actually trying to integrate the ng2 router with redux, I wanted to keep the route and params in redux, so that my components could all reference from the same location for all state.

Keeping the store and router synchronized was pretty painful to say the least...  Hopefully the next article in this series touches on that.

While interesting.. I would think that something using a promises interface, and beyond that, having a template string parser would be more eloquent at this point.

Kind of a sad moment, but I'm glad Tim was able to pass the project along.  Too many times a project just dies on the vine.  I can't imagine how relatively painful moment must have been to get to where it is, and how much work it is.  Date-time logic is some of the most difficult to get right, especially when you add in various locals and options.

Just today, I've been working around issues by replacing a bunch of custom logic with moment.

CJS/Node modules really can only work via pre-bundling solutions... AMD is pretty bad in it's own right as well, though slightly better for the browser case.

The ES2015 module syntax offers the ability to determine loading as a pre-process step.  Though in practice most aren't using proper reference paths, so you're stuck using pre-bundling, similar to CJS.  Also, you can't conditionally require modules as you can with CJS.  Some benefits are the ability to have better tree shaking with bundlers.  As it stands, the tooling is a work in progress.

If ES2015 modules were supported in browsers from earlier on, then they would have been used over either CJS or AMD.  And HTTP2 would have been *HUGE* in terms of performance.

It feels like this is slightly less of an abstraction than Redux (which itself is pretty small), with a slightly less clean abstraction, and more inconsistent to extend.

It's an interesting idea, just the same, I just don't think it's quite as good.  There's nothing stopping one from using multiple Redux stores in an application, but that's a YMMV kind of thing.

Interesting... with webpack, will often inject $, jQuery and window.jQuery via webpack.ProvidePlugin ... I'm more inclined to avoid jQuery altogether these days if possible.

The query engines in most browsers is as good as I need.... document.querySelector* does what I need.  With shims for Array.from, and addEventListener, that covers the major use case.  Promises are in the browser and bluebird has more as a better alternative.  Axios and fetch are better options for remote requests, already promise based.  The value add for jQuery (as a pretty big library) just isn't as worth it to me.

It's getting to a point that it's worth considering having two builds in babel again... one for modern browsers, another for ES2015 target.  Since most self-updating browsers and even Node have most of ES2015 now, a lot of the patching is only for IE9-11 (depending on what you support).

I can't help but feel that these templating libraries aren't long for this world as ES6 templates are supported by all modern browsers.

Nice primer on the React way...  It does take some getting used to... and aside from a few edges, really love React as an application platform.  Some types of interactions (animation and drag-drop) are harder to fit though.