Echo JS 0.11.0

Need to check this out... pretty interesting to see react in a deno project... didn't realize they enabled it for their ts compilation.

I'm not sure I find the pipe method really any easier to reason with than the pipeline chain.  Also, if you're using babel, you can just enable the pipeline operator.

https://babeljs.io/docs/en/babel-plugin-proposal-pipeline-operator

The F# inspired version is probably the best option imo...

https://github.com/valtech-nyc/proposal-fsharp-pipelines

    const getData = async url => url |> fetch |> await |> r => r.json()
    const logIt = async p => p |> await |> console.log;

    'http://foo' |> getData |> logIt;

My only curiosity is if OvermindJS can grow to larger state objects... with Redux, you can slice your state up into separate sub-reducers per property on the state object.

Also, I prefer the hooks to the hoc at this point.

https://github.com/PixelsCommander/PrayerWheel

This publishes an SPA with no routing and no server-side rendering... it breaks most of what a blog should carry... you cannot share a link to an article even.

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