Echo JS 0.11.0

I really like parcel, in many ways for the same reasons I like jest.  Trying to wire it all up yourself is *so* much effort, that I'm willing to spend a couple seconds on initial builds to account for it.

Similarly, Jest does such a good job at wiring up coverage, which is really a pain with say mocha.

I't a bit more pragmatic, and I still have to do some leg work.  I'll probably start using v2 in the next few months.  I tried an early beta and had some issues with it.

Missing generator functions... async generators are really cool as well, combined with for-await.

Interresting, though for something like this, that's embedding in another application instead of being the application, I'd probably reach for preact or hyper as another JSX transform option, which will be much lighter.  You can even swap in prod vs dev builds for testing.  React adds a lot of tooling and niceties that come with a ton of overhead.

You're looking at probably a 80k deliverable for the example out of the box, vs under 5k using hyper+jsx or preact.

I like React.  This just is a case where using something smaller/lighter but being very similar in practice would be better.

1. https://github.com/lukejacksonn/hyperapp-wiki/blob/master/docs/jsx.md
2. https://github.com/preactjs/preact
3. https://github.com/kenoxa/svelte-jsx

Interesting. Would definitely reach for Vue when extending mostly static content for more dynamic components at this point, where I might have used jQuery a decade ago.  I still prefer React + Redux + Material-UI for apps though.

Seems like the general sentiment is to keep them.  I often don't feel like sitting through the videos, so will probably just remove only if there's multiple downvotes or "this is spam" type comments on them.

Thanks for the feedback.

Pretty low in general, maybe 1:15 or 1:20 or so... just noticing more lower quality entries, and figured I'd reach out and ask... seems to be mostly in favor of keeping them, which is okay by me... I only tend to delete things maybe once every day or so, and often not on the weekends, so they may manage to stay up for a while.

-- edit:

Of course, as soon as I say that, there's 2 today, 1 of which is off-topic... lol.

Note: Without restricting allowed domains in OriginStorage, this effectively opens up your data to *any/every* website.  DO NOT STORE CRITICAL/SECURE/SENSITIVE DATA HERE.

Simple caching... for the browser, probably better implemented with a Service Worker[1].  One issue is that the options stringification should be using a stable/consistent stringify implementation[2]

1. https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker
2. https://www.npmjs.com/package/json-stable-stringify

Looks like this could really be close to an in-memory objectdb typed interface... if you made your queries return functions that act on the database, you could use it for creating a data abstraction layer interface.  From there, you could bind to a storage engine for serialization/deserialization.

Really cool, and pretty close to some useful primitives indeed.

Was going to mention the demo size is 2.7mb transfer size, but looks like 1.6mb of that is storybook in the demo iframe.

So ~~1.1mb, which is still pretty big, but considering the size some of these kinds of things reach, not so bad in general considering this includes some other framework resources on top that may not be part of the actual demo.

I would suggest getting a demo screen outside storybook that only showed the resources needed for the demo itself, so the overhead can be determined independently.

NOTE: for anyone using this, or other large modules (graphing, pdf and reporting modules in general tend to get very big), make sure you have async chunks setup in your build pipeline and are loading these modules with an async abstraction layer to not impact your initial load times as much.