Echo JS 0.11.0

I do like/appreciate some of the composite controls.  I've mostly been using material-ui for now.

Nice little wrapper around Puppeteer (chromium) with some extra options.

Interesting project, but wish it would also handle making certain to request additional storage when needed.  Also, the cookie storage should be disabled by default as it can dramatically increase request times to/from the server.  All cookie data needs to be transmitted and parsed by the server on EVERY request.

--- 

rant on web-sql ahead

I know that creating a minimal definition for "web sql" was hard, but I'm constantly dissapointed that MS didn't just adopt SQLite at a compatible version for IE/Edge.  They're using it in Windows 10.

In the end it could have been a very pragmatic choice for a lot of this.  For the most part now, I stick to local/session storage interfaces for k/v storage and don't worry about it.  All the current browsers support it, and it's relatively transparent.

I just don't want to encourage less experienced developers to prematurely optimize.

Also, calling them "Performance Mistakes You Should Stop Doing" is a bit of a red herring in this case.  As it isn't something you should stop doing unless you need to for performance reasons (after you've determined it's an issue).

There are a couple down-votes and I didn't want to leave the impression that I was one of them.

While I agree that it's worth knowing these things.  In the end, use the clearest code as much as possible.  A quick reduce with an inline fat-arrow function is much shorter and easier to understand than passing off into another function that does a for loop, or worse inlining the loop.

I didn't downvote, but will suggest that one should optimize when one needs to optimize.  Also, one should use metrics to find real-world bottlenecks that are causing actual pain or stuttering.  In the end adding additional lines of code or making more complicated loops increases complexity and size, that also count.

In the end, write clean, concise code, with just enough comments to cover any possible confusion in logic or intent, and leave it at that unless or until you have metrics to properly point the blame.

In the end it depends on your use case and your need, and unless or until you *have* to improve performance, concentrate on clean code first.

Advertorial content, not necessarily off topic, or out of line, just not generally appreciated.

I'm also not sure I quite understand where Bit fits into the scheme of things, it seems to be an additional repository system to manage on top of whatever CI/CD you already have not to mention npm, builds, releases, etc.  I'm not sure how many environments can realistically utilize the platform and if it's worth the additional complexity over npm enterprise or another internal repository system.

I so want to use this for "unexpected" error conditions, capture the background on a canvas, clear it all with the image of the background, and every time you close the dialog it repaints in a different position like old-school windows 9x and 3.x used to.

This is why you should use a normalization before serializing and doing any comparisons, unless relying on the order.

That's probably fair, but should note it, just in case...  It's surprising how many apps today still need to support IE9-11.   Which is a shame.

Definitely interesting... not sure I like the store/state management piece, but it's definitely interesting.

One thing that would be nice to see would be browser support.  I'm assuming the store is using proxies in order to raise state change events.