Echo JS 0.11.0

Don't do this, let the methods expire… we have async functions now… beyond async being a reserved word.

Obviously a place that doesn't have any/many over 30 or 40.

Would be better to use async functions.  Supported in all modern browser for quite a while as well as in node for several years.  Not to mention via Babel since before the name change (iirc).

I think the hooks interfaces are definitely interesting... as is seeing a lot of considerations as to integrating state management in thoughtful ways.

I do hope that it doesn't bloat the reactdom stuff too much if you aren't using it.  Right now react-dom and chartjs are the biggest chunks in my two biggest output bundles...

OMG! That is gorgeous and nifty AF.  Love it...

I really do like it a lot... though, I'm not even sure where to begin to be able to test the behaviors...   May want to add at least a couple examples for unit testing against with say jest/enzyme.

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.