Echo JS 0.11.0

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.

The modal itself presents a single issue I see a lot in modals... in that if the vertical space on the screen doesn't show correctly, the modal won't scroll, also, the page in the background does scroll[1].

I generally put in the effort to work around this.

[1] https://github.com/juanbrujo/tinyModal/issues/4

IIRC, flow doesn't/didn't work on windows, which is a non-starter for a lot of users... not sure where this stands now, last looked at it when using flow types to be able to use angular 2 without typescript, as I mentioned, I didn't see the point as I still needed bits from babel.

But flow adds type support (same as typescript), and can also be used with babel... flow only does one thing, so better integration.  Typescript doesn't offer much beyond types (and flow does that) over babel.. and as you say, you're using babel anyway.

Because at runtime, typescript doesn't provide type checking... ie: when interacting with a foreign API... Beyond this, with small, well-organized modules, TypeScript tends to only add boilerplate, and doesn't tend to prevent as many errors as the time to write boilerplate prevents.

I can see why some would like it, I just don't find much value in it.