Echo JS 0.11.0

<~>

tracker1 comments

tracker1 2391 days ago. link 2 points
Shell section should probably reference using shelljs module with node scripts directly.  If you're already using node, this normalizes very well across platforms.

Other than that, pretty much every gotcha I've come across is there.
tracker1 2395 days ago. link 1 point
Does this support use of the Cluster module?  IIRC, when I looked at gRPC in node a couple years ago that was a major limitation in practical use for me.
tracker1 2401 days ago. link 1 point
Meh... while I do think that using array methods map/reduce/filter etc are generally a better idea from being able to understand code over for loops... there are many cases where the for loop options are better.  Serializing requests or other queue handling in async functions as an example.  Async generators (ES6 Streams with for-async) being another.
tracker1 2401 days ago. link 1 point
This is cool AF... combined with Context, you could pretty much replace redux and react-redux... although there's a huge third party ecosystem around the two now.  It's nice to see these options in the box, and especially working with functional components.
tracker1 2401 days ago. link 1 point
I would also suggest posting this in /r/javascript since it's likely to be seen by more people.  

- I would suggest updating the codebase to use ES6 module conventions and use rollup for your build process over gulp+browserify
- Add a youtube-link that generates an appropriate embed option
- Add wrapper components for Angular, Vue and React

Aside: I'm not sure how much draw you will see for a "pro" version, but good luck to you.
tracker1 2401 days ago. link 2 points
I really wanted to like ngrx, it just felt like too much for the common use case... similar to redux-saga and similar combined effects.  The simpler angular redux adapters are a lot easier to use imho.  That said, I also generally feel vitriolic hate towards Angular, so avoid it as much as possible.  Love react, like vue.
tracker1 2409 days ago. link 1 point
In general, my suggestion is via webpack+babel to do two build configurations.  One for "modern" browsers (async/await support an higher) and one for "legacy" browsers (everywhere else).  Modern ones are fairly easy to detect server-side and inject the correct entry point(s) into your html delivery.

In the top of my "modern" entry, I do a test for async/await, and if it fails, will set a cookie and `location.reload()`.  This forces legacy should it not have detected properly.  In the end, without most of the polyfills or the corejs bits there's a huge savings in overall size, and load.

My current work is mostly internal applications, where I don't have to work around supporting legacy browsers fortunately.  Even keeping firefox + chrome happy is enough work in some cases.
[more]