While somewhat informative, I think some things are a little bit muddied... Jest actually uses Jasmine2, and Enzyme can be integrated into several of the test tools in question. While wiring up Puppeteer can be a bit of a pain, the learning curve really isn't bad in practice.
On other problem is you have different options for different concerns. Unit testing react is not the same as integration or render testing. I happen to really like using Jest for most tests, and while I like chai/mocha more than Jasmine, Jest gives you more than just the test harness, it gives you parallel support as well as code coverage in the box.
Using Jest with puppeteer for integration/browser testing does take some work, but it's very nice in practice.
My only commend is it seems like socket.io is a bit overburdened and a faster/lighter socket server implementation might help... pretty cool all the same.
Interresting, though the article doesn't actually link to Cypress[1]. The first reference, or two, should absolutely link out to the project's home page.
I've been using Puppeteer with Jest myself, which isn't so much fun to setup, but has really been productive for me.
[1] https://www.cypress.io/
I don't think that Web Components will grow much as-is, it's cool for relatively discrete UI components, but the lack of non-string property support and a good story for state management, I think React is generally better for most use, but you can combine the two.
I also do think that Web Assembly projects will mature, and should a better DOM story come to bear fruit that will be really nice. I have a feeling that access to Canvas and sound primitives will come ahead of general DOM access, which will have some really cool options for webifying more applications more easily.
Cool project, unsure of durability or redundancy constraints, let alone something akin to gossip to re-seed and/or re-balance records to partitions after coming online again.
Seems like a natural pairing to leveldb for local storage or even just an in-memory store for distributed caching.
Would still probably be better off with something with a higher memory threshold than node.js supports out of the box.
Two biggest reasons, I like the syntax, and using object de/structuring...
export default ({ foo, children }) => (
<div className={classNames(
'some-component',
{ foo }
)}>
{children}
</div>
);
Two biggest reasons, I like the syntax, and using object de/structuring... export default ({ foo, children }) => ( <div className={classNames( 'some-component', { foo } )}> {children} </div> );missing object support { 'className':truthyFalsyValue }