Echo JS 0.11.0

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.

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.