Echo JS 0.11.0

I would, frankly question the need for any version of IE at this point...  The extra overhead is significantly higher for supporting anything that isn't a modern browser, Edge, Chrome and Firefax update regularly (what is your userbase).  I'm working on a Government project of all things and the cutoff we went with is browsers supporting async functions (es2017).  A lot of polyfills for everything from generators/async to fetch are just eliminted by that.  ymmv. Supporting IE8 will blow up your bundle size with many polyfills and transforms if you want to use modern JS.

I have a modern app set for es2017+ browser with webpack, babel, react, redux, material-ui and more.  The main bundle is 156k gzipped[0].  If you want more lightweight, you could use a different UI kit, and use inferno. Alternatives include Vue, but the two apps I've been involved with using it I haven't cared for either. All said, 160K for JS + CSS + Controls isn't so bad.  It's not as lightweight as you can get, but it's a pretty rich feature set.  If you look at the core-js section, if you include IE8, it will be *MASSIVE*

If you work at it, and don't need routing, or fancy controls, etc... you can pretty readily create a bundle that's under 30k.


[0] https://imgur.com/a/CSvjNrb

Wishing I could vote this up twice.

IE11 support...

    function createUUID() {
      var fmt = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx';
      var rnd = Array.from((window.crypto || window.msCrypto).getRandomValues(new Uint8Array(32))).map(function(n){ return n&0xf });
      function rk(c,r) {return (c == 'x' ? r : (r&0x3|0x8)).toString(16); };
      return fmt.replace(/[xy]/g, function(c) { return rk(c, rnd.pop()); });
    }

Regarding the use of Math.random()

    function createUUID() {
      const fmt = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx';
      const rnd = Array.from(crypto.getRandomValues(new Uint8Array(32)))
        .map(n => n&0xf);
      const rk = (c,r) => ((c == 'x' ? r : (r&0x3|0x8)).toString(16));
      return fmt.replace(/[xy]/g, c => rk(c, rnd.pop()));
    }

[0] https://caniuse.com/#feat=cryptography

[1] https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues

graphql isn't free though... there is a *LOT* of boilerplate depending on your object graph structure and actual data source implementations.  It doesn't always make sense to jump through those hoops... then again, it doesn't always make sense to go through extra abstractions to group your AJAX requests either.

The bigger issue is that if you have more than around 6 connections to a single resource they will be delayed.  It's not so mucha matter of grouping the requests to deliver at the same time as it is about limiting server requests and resource contention.

Websockets would be another solution.

Didn't see this when it was first published, and google didn't show it on echojs.

While on the one hand, I completely understand, on the other, I'd like to see babel have a single document/page listing all the stage-X proposals and links to pages for each of the appropriate plugin for the latest version of Babel.

I switched to individual plugins when all the deprecated warnings started.  thinking of publishing @tracker1/babel-preset-running-with-scissors for an equivalent to stage-0

Definitely cool, but at 35GBP ($45 USD), it's definitely a bit overpriced imho... at $15-20 USD, it would be something you'd get a few just to play with.  I'm not sure I even have a great use case for something like this without spending even more on a surrogate device to work with/against.  For around $60-80 USD I can do an RPi3B+ with case etc and a btle adapter.  It's not as small, but as I said, the puck is really limited without a surrogate device anyway.

This could be a really cool effect for a chat application.

A few points to mention:

1. I feel that redux-thunk with async functions are good enough for 98% of async needs... saga and others are just so much overhead and boilerplate to work with.

2. Look at mterial-ui (which uses React-JSS for styles), it's a pretty nice set of tools to work with on that side.

3. I find Redux easier to work with when things get more complicated, you can break things up and combine them as you need.

4. connected-react-router will tie into redux a bit better... you can also write your own redux plugin to deconstruct querystring parameters and append the data in response to your connected router.

5. Writing middleware for redux can fill a lot of gaps, ymmv of course.