Echo JS 0.11.0

Definitely interested in playing with PouchDB, there's also a server implementation that exposes the Couch api interfaces.  I am a bit curious about security... I'm interested in implementing some syncing of user settings to a private db server-side, and authentication is the only thing I'm not nearly familiar enough with.

Will need to find time to look into the PouchDB server implementation to see how security is, or can be implemented.

dupe

I happen to like JS, more so with the extra ES6+ niceties, but I can see the appeal of a more purely functional language without some of the extras.

And no, imho no solution is perfect.. tbh, if it's public facing I'd just prepopulate the store server-side with the essential portion of data and let the rest populate client-side... that would take care of the non logged in user case, and account for search engines... the rest can run client side.  In the end, it's up to the author.

I also happen to really like react in general, and if full server rendering were desired, I'd go the redux-universal route.  I usually use the thunk methods with async functions anyhow, so that allows promise resolution to work in that way.

To each their own though.

Classes in JS(ES6) are definitely sugar over the prototype chain... beyond this, you'll still need to have that inheritance chain for certain contexts.  If you choose prototype syntax over class syntax is entirely subjective.  I happen to think the class syntax is cleaner to look at and follow.

I don't think classical inheritance is a good use case for many types of workflows, for others, they are.  In general, where you want to persist state in conjunction with workflows, classes tend to work better.  Not that you can't work around them, but it really depends on your needs.

I tend to use classes very sparingly in JS.

Very cool... curious how long it will be before we see `.mod` and similar tracking format players in JS.  Would be cool to see a reduction in bandwidth usage (like currently done for mp3/waveform) for games and the like.

tldr; Stick to the latest even number Node versions for the longest period of support.  Use the highest numbered versions for the latest and greatest.

In the end, I feel this is pretty nice, with a new LTR each year at every other version.  The down side imho, is I really hope all the stage3-4 bits of ES make it into V8 before Node version 8 is cut in 6 months, I know a lot of those pieces are slated to make it in.  I have the feeling that with the extra bits that are pretty far along in ES stages, that there won't be need for too many changes to the core engine for some time, at least in terms of ABI/API.

While an interesting demo, the ClosureScript is difficult for me to read.  Also, this can be done pretty easily with React+Redux as well, only populating the primary data on the server, to a full render/rerender on the server via redux-universal as well as other options for partial rendering, or donut caching.

In particular donut caching can work very well with react, having the surrounding render server-cached and templated, only injecting the server-populated center piece (which works for the unauthenticated user case, being SSO friendly), and having the client load any authenticated pieces in the surrounding areas.  Instead of mounting a single react app, you can mount 3-4 one for each region connected to the same store.

This is some great stuff.  I am curious if any effort will be made to reduce singular compaction to Xms, similar to how it works with go, so that GC in node can be split up and doesn't stop the world for too long.

TIP: If you're doing a dedicated processing script in node, you can expose the garbage collector to the runtime, and in your script you can call GC manually after each handled item, this will keep your memory usage low.  I wouldn't suggest manually calling GC in a service based application, but for processing scripts it helps a lot.

Only minor nit I would pick is that in most of the cases in the refactored code, `else` could be removed.  More often than not, `else` is a code smell imho, and often you're better off separating function logic and having an early return instead of an else.

Will have to give it a try... inevitably many/most attempts at masked in put fail in terms of edit/select/cut/paste handling... By either never being able to inject text in anything other than the end position, unable to select and/or cut text and failed paste operations.

Hopefully this accounts for the above more than typical shortcomings.