Repository navigation
Towards language agnostic Hyperloop Stack #100
Description
How much would this help us?
What languages would we target?
What are the implementation details?
My answers:
Would it help? Seems like it really would... It would make the concept universal and take out the "language wars element".
What languages? Javascript, crystal, clojure would be my immediate choices. But this is pretty random.
Javascript because well it would just sell well. Everybody wants an SUV so even jaguar makes an SUV. Also a Javascript implementation would clarify what is unique about the hyperloop stack, in contrast to react.
Crystal because its the logical successor to Ruby, and also because its macro system will make for a beautiful and effecient DSL. Only negative is we don't have a Crystal -> JS compiler (yet.) However as has been pointed out crystal BE, ruby FE would be a logical stepping stone.
Finally, Clojure is interesting (to me) because of ruby's roots, in lisp, the fact that Clojure does have browser implementations, and has great meta programming capabilities.
Implementation Details Need to think on this one and take some time to write it down :-)
Activity
fzingg commentedon Nov 20, 2017
Probably a stupid question:
If Hyperloop Stack is language agnostic (JS, crystal or whatever ...), then if I use RAILS, then I can still continue to write all my components, Stores and Operations as it is now, right ? It will still continue to use OPAL to get RUBY to JS ? or Maybe RUBY to crystal ? I'm not sure.
janbiedermann commentedon Nov 20, 2017
it would certainly help getting good algorythms.
a common protcol for all could help for services talking to each other
catmando commentedon Nov 20, 2017
@fzingg yes I am imagining a standard set of semantics for components, models, stores, operations and policies. You can see how this works already as components can basically be described either in javascript, JSX or Ruby. We would have similar mechanisms for models, stores, and operations.
Underlying this would be JS code on the client, with language specific wrappers (again just like the relationship between react and hyperloop today.) On the server side, each language would have its own server side implementation responding to a standard set of protocols.
So for example if you were using javascript on the client and node on the server, you would be able to describe run operations like today but of course the syntax would be JS.
There would be no change for existing ruby hyperloop apps.