Echo JS 0.11.0

Veerrry interesting...

Considering how much the API surface in Angular 2 has changed in the past year, that's hilarious.

(sarcasm) the part where you enthusiastically get started, then the part where you wish you'd just used React instead.

LOL

Just don't name your objects that are deserialized or unserialized with "JSON" as part of the name.. they're an object, plain and simple...

If they hold a higher level abstraction (Json.Net object, or similar), or hold a string that is Json, go ahead and have it as part of the name...   It just bugs me when I see things like:

    var jsonData = JSON.parse(somestring);

If this is JavaScript, "jsonData" isn't JSON, it's an object.

Here's mine[1]. I need to button it up for an actual release, and improve the demo to show more options... it's pretty flexible and the modal is entirely standalone, with no external dependencies on the built version.

You could write a pretty thin shim for wiring up date inputs.  I didn't write an actual date input component as I wanted it to be able to tie to whatever input component/method one wanted... but have a nice full-modal picker.

Also, as you resize the screen it will handle reflows/sizing as well as vertical scrolling when the window is too small, many modal templates won't do that properly.  The size min+gz is about 20kb, using preact, preact-compat and redux... I'll probably refactor to separate the actual date-picker component from the modal, and make it more friendly for use inside react (and preact-compat) projects, without the bundling.

edit: the demo doesn't always seem to gzip the js, it's about 60k non-gzipped, but can shrink a bit with gzip level 5-9 compression.

[1] http://tracker1.github.io/md-datepicker/

I think Node.js should probably be the first place to reach for when building interactive front ends that need to talk to a backend... The iteration and throughput you can get with node initially make up for most of its' shortcomings.  That said, you can always shave off pieces that don't perform well into services that are farther back, then use node to delegate the operations from your front end to these more performant services.

As TFA mentions, structure and discipline are important as projects grow... It's easy to create a mess of spaghetti.

I would say if your data set is hundreds thousands of records, JS and Node can be *very* bad at this... In general, when trying to map-reduce larger data sets in node, you need to really be careful on how you introduce, stream and dispatch results.

Node has a command line flag that can expose manual garbage collection (good to do after each record, or every N records, as memory use will grow fast otherwise.  Even then, when you have so many objects referenced, they will collapse...  You can use streams for the map, and reduce aggregates, but if your reduction aggregate object/map gets too big, it will blow up the runtime when you run out of references and/or memory available.

Realistically go and even rust are better suited to these kinds of flows with larger data.  I love JS, it's my favorite language, and I really like node... but there are some use cases it's absolutely bad for.

As far as I'm concerned local is langage + location...  such as "en-US", where language-only is a fallback if there's no match in language-location.

I would probably either have a "default" language, or a configuration to set what the default is.  With rules for fallback/forward.

I'd also get rid of the configuration option to specify locales, and use the directory path's /^(default|([a-z]{2})(\-[a-z]{2})?)\.json$/i to look for configured localizations.  This means less configuration, and more straight forward defaults.

Minor niggle, I would make the action's payload itself the Promise... as it is, one has to dig into it... There's no reason not to simply check for a thenable payload directly.