Echo JS 0.11.0

I don't see the value beyond actual bash scripts and/or npm scripts...

For a moment, I had this confused with JSON Resume[1]. thinking of CV == Resume, instead of Computer Vision[2].

1. https://jsonresume.org/
2. https://opencv.org/

Here's how I use it...

https://gist.github.com/tracker1/f0b91b0bc07fe67d08ef2d6119707a2d

I guess I should expand on my initial reaction...

1. this takes something fast in JS and makes it slow... JSON stringify/parse functionality is very fast in JS generally speaking.  Adding this overhead makes it slow, for very little gain.

2. it's using decorators and not really documenting if it's TS, legacy or the current stage-2 decorators proposal.  The fact that the repo seems to indicate typescript leads me to believe it's TS based.  If this library is TS meant to work with TS, then why not just rely on TS signatures?

3. given the additional overhead vs. just using TS types for code comparability, it's dubious if this is any faster, better or slower for validation vs Joi and any number of existing validation frameworks.

4. the syntax is really noisy.  It seems like it's inspired by the ASP .Net Model validation patterns in some ways.

About the only place I might consider this would be within the context of a node based API service, and going back to the third issue, I'm unconvinced this is any better than any number of input validation tools already in existence, or that it's any easier to adapt in that context.  I would suggest adding some metrics/testing for seige on an API with various validation tooling including this one in place, including valid and invalid cases one and more layers deep into an object structure.

https://github.com/pichillilorenzo/jackson-js/issues/1

Babel, or typescript yes... decorators have been in limbo for 5+ years now, the current proposal has been developing for about 2 years, which is different than legacy decorators and will probably be several more years before this shakes out.

https://github.com/tc39/proposal-decorators

Yuck.

Looks nice.  Mostly using Joi these days (in koa, separate from hapi)

You may also want to consider the useMediaQuery or useViewportSpy hook from beautiful-react-hooks[1], since it's probably closer to what you may actually be trying to accomplish.

1. https://github.com/beautifulinteractions/beautiful-react-hooks

Should probably include examples of useContext and useReducer to round things out, but nice intro.

I would suggest if you are using a Component based toolkit that you use a UI/Component framework that does it's styling in a sane way (material-ui) over using a CSS centered framework.  This is especially for SPA and similar.

While this isn't the case for TFA, seems to be centered around server-oriented content, I'm just not a fan of CSS centered vs component centered frameworks if you're doing client-side development.  The disconnect becomes pretty big in practice.

Just my $.02 ... a notable exception might be if you're in a larger environment that has separate designer oriented resources and you are receiving most markup and styling from those resources.  Even thin, it's often better to turn your markup into component oriented logic.