I don't know that I agree with that... a lot of the syntax definitely burrows from Ruby, but then again so does CoffeeScript... this actually looks a lot like CoffeeScript with embedded razor templating.
I think this is either developed by or targeted at people with a ruby background, and does give some context. I'm actually more happy with something closer to JS (EX6/7 transpiling) with React (JSX) than something like this. Usually when you approach headaches on larger teams with JS, it's more that you haven't broken things down as well as you can/should more than a language construct.
JS projects tend to work far better from discrete separations of components, views, functions and composites... simple components can be thought of react components that only use properties for rendering, views are a composition of components that use stores for state interaction. Functions are modules that have singular discrete testable functionality and composites are similar to classes but yeild an object tethered to state/options but mainly glued together from modules that expose a single workflow function.
There's also control/workflow type composition, and node-style object pipes tend to work very well in many of those scenarios... get batch of items from db into an object stream through workflow steps, queues, etc.
It's definitely an interesting abstraction of a few ideas together, I'm not sure what it does in terms of improving a larger workflow. Other than a more wrist friendly syntax.
I think this is either developed by or targeted at people with a ruby background, and does give some context. I'm actually more happy with something closer to JS (EX6/7 transpiling) with React (JSX) than something like this. Usually when you approach headaches on larger teams with JS, it's more that you haven't broken things down as well as you can/should more than a language construct.
JS projects tend to work far better from discrete separations of components, views, functions and composites... simple components can be thought of react components that only use properties for rendering, views are a composition of components that use stores for state interaction. Functions are modules that have singular discrete testable functionality and composites are similar to classes but yeild an object tethered to state/options but mainly glued together from modules that expose a single workflow function.
There's also control/workflow type composition, and node-style object pipes tend to work very well in many of those scenarios... get batch of items from db into an object stream through workflow steps, queues, etc.
It's definitely an interesting abstraction of a few ideas together, I'm not sure what it does in terms of improving a larger workflow. Other than a more wrist friendly syntax.