I don't think it's particularly hard... the issue is, it depends on what you expect from front end testing.
One of the best things about React + Redux, is if done properly, you can cover a *LOT* with unit tests alone on your action creators (dispatch) and the reducer(s).
On the latest project I'm working with... all components are functional and using hooks. All event handlers for components are using bound action methods from the action creators.
This means, all actions can be tested via call/injection alone... the API and getState/dispatch passed into the event handlers.
All state changes through reducer tests... in the end, the components are pretty straight forward (material-ui) and reliable. That part is more of a pain to actually test, but less impactful on logical workflows.
Kind of wish the razor-like engines (such as vash and bliss) had gained more traction... I really do like the syntax.
The article itself is really shallow and doesn't even cover what its' own summary mentions.
Nice demo.. that said, having a UI that displays the JS that is actually being used, without having to dig into the dev tools would be a huge improvement. Without it, especially if one uses a mobile device... in the abstract, without code samples, this demo is nearly useless.
I disagree hugely on momentjs being the best option for date functionality... date-fns and luxon are both much better options... momentjs is a massive dependency and *really* big. Luxon was made by the momentjs team with the benefits of hindsight. date-fns is more than likely more than enough and much lighter.
See the npm package fclone for a decent deep clone implementation. (disclosure, it was shake n bake, and I helped).
https://www.npmjs.com/package/fclone
I think I commented along these lines in the original post... I don't mean to be discouraging, only that from a developer perspective there are so many choices. As to the deluge of options, I'm coming at this with 24 years of web application development experience.
Here is one major issue, and that is you pretty much have to click through from the landing page, to the docs, to the playground to have anything resembling a complete code sample for beginners, this should be front and center.
My issue specifically with frameworks like this is that it doesn't get you closer to either the html dom or to a component structure. The playground example is almost a component example with Form etc... just hard to flow. Also, at least from the example, you cannot segment state use... each child component needs to know about the state as a whole, you cannot pass part of the state, bind event handlers or bubble up/down the portion of state and handlers to the child.
Similar alternatives include using hyperapp with a separate state manager... There's also svelte, riot and preact to consider.
Beyond even this, you can go a very long way with template strings.
isotope seems like it might be useful if you want a dynamic piece in a larger site, without much overhead (size is probably the biggest selling point). Although, I think trying to build anything significant with this would fall apart pretty quickly.
Would be very cool if this is done with a charting component that doesn't bring in > 1mb of JS framework (uncompressed) to draw the chart alone... but hey.
Hmm...
<div class="card">
vs.
<div class="w-1/4 mx-auto flex p-6 bg-white rounded-lg shadow-xl">
Which one is much less complicated and less code again?
Seems to be a smaller implementation for the MongoDB BSON data format.
Here's an article going over this and some competing formats.
https://yuhui-lin.github.io/blog/2017/08/01/serialization
edit: If this is for an API response structure, than you may want to also consider GRPC as a protocol (uses protobuf3)
Hmm... <div class="card"> vs. <div class="w-1/4 mx-auto flex p-6 bg-white rounded-lg shadow-xl"> Which one is much less complicated and less code again?