Creatively expanding Hyperloop base...

[ylluminate]

@catmando not sure if you saw this discussion previously in Gitter, but I have been thinking that a portable Hyperloop that can run atop Amber or even Lucky frameworks for Crystal might be very attractive for the communities. It could be argued that having Hyperloop / Opal on these provides a more isomorphic platform even though it's not one-to-one per se. Nonetheless, it would very much expand desirability for those hunting speed while keeping a primarily Ruby environment.

[catmando]

I certainly agree. It think it would be very very powerful if we had a crystal -> JS transpiler (like Opal)

Meanwhile i guess it does make sense as interim step to at least integrate hyperloop (FE) with a hyperloop crystal backend, compatible with either AMber or Lucky or both.

[ylluminate]

What is the "FE" nomenclature? I am assuming it's some kind of a "bare metal" (FE reminds me of "iron") interface that would allow interop with other crystal backends such that perhaps there is a single interface provides the necessary translation for them...?

Just brainstorming, any thoughts on what would be the best approach to start such an effort?

[catmando]

FE = frontend (client side)
BE = backend (server side)
Full stack framework (i.e. hyperloop, meteor, volt) = FE + BE integrated

So your proposal as I understand is to somewhat to a version of hyperloop that is 100% compatible for the FE part of the code (i.e. the client etc) but would use crystal on the BE (server)

The problems to solve are

1. what kind of ORM does Amber/Lucky have? Then you have to adapt the current Hyperloop server side code to use that ORM. Could be fairly easy depending on what kind of hooks the ORM supports. Hyperloop just needs a few things to work.
2. figuring out how ServerOps are going to get called from the client.
3. Hyperloop has a pretty small controller you would have to port to your crystal framework

[ylluminate]

LOL, gotcha. I guess we all have too many acronyms floating around our heads.

I'm no authority on either framework; we're just looking at using Amber primarily as a Rails replacement for a couple of projects right now due to the marked speed and memory consumption improvements and it would sure be nice to have hyperloop to run atop this. I think we've all been hoping to see things improve in the ruby space with Truffle and such, but Crystal takes things so much further performance wise right now (even though it's still not entirely mature), that it's hard to ignore.

Re: each framework:

• Amber (someone in Gitter summarized Amber as: "... more like rails mixed with a bit of phoenix and other modern ideas."). ORMs: Granite, Crecto, Jennifer.
• Lucky (I guess Thoughtbot is behind it and I think it's going after Elm or some "Elmish" stuff, so Opal might not be as well received? Dunno. Someone in Gitter said: "Lucky uses a lot of experimental concepts [and is about] catching bugs early, forget about most performance issues, and spend more time on code instead of debugging and writing tests... [uses] ELM style view templates."). ORM: LuckyRecord

I'd personally say that Amber would probably be the primary target for the moment.

[barriehadfield]

@ylluminate your joining of the dots is much appreciated.

[paulcsmith]

Hi @catmando! I'm the creator of Lucky. I like the idea of Hyperloop and I've been interested in Opal before. I'd prefer isomorphism over using Elm. I also like the idea of mixing and matching where most pages are generated on the backend in Lucky, but something like Hyperloop could be used for just a few components.

You can see that Lucky actually has Hyperloop like components generated with Crystal methods: http://luckyframework.org/guides/rendering-html/#adding-a-page so I think it could be a good fit.

What kind of hooks would LuckyRecord need to work with Hyperloop on the front end?

[fkchang]

@paulcsmith looking at the crystal guides page, it looks like the rendering examples could be in that subset that is the same in both ruby and crystal -- in my mental thought experiments of how an opal/crystal full stack framework would work, in the ideal case, there could be some isomorphic opal/crystal code if coded to some guidelines (possibly a tool to ensure they run on both) -- so I think there is potentially something quite cool that could happen

[fkchang]

@paulcsmith hey, so I'm wondering what the quickest way to hook opal into lucky would be. I see from http://luckyframework.org/guides/asset-handling/ you're using brunch. I've never used brunch, but I guess the brunch equivalent of setting up webpack to compile opal files. Where I'd like to go with that is be able to have hyper-react load initially with brunch, have opal-hot-reloader hot reload transpiled Opal and css (though I don't know what I'd have to do to support hot reloading of the css - but if it's similar to how Rails does it, I can watch the compiled .css files), but also have a directory of code that can be run on both front end and backend. With Ruby based systems, we can use sprockets to both compile the opal code as well as allow the sharing of front and backend code via shared directories -- I'd be curious as to how to do the same with Lucky/Brunch -- possibly via config. Lastly, having some sort of backend components that could prerender the hyper-react components, perhaps a class that on the frontend inherits from HyperComponent and on the backend, inherits from something else, so the code looks the same -- though that might be too much to ask for, or too complicated (won't support JS based components on server side render like we can do in ruby-hyperloop) -- but food for thought.

I'm thinking if we could throw together a quick configuration, it could make for an interesting test bed. @barriehadfield might have ideas having written https://github.com/ruby-hyperloop/hyperloop-rack-webpack-stack -- had addressed similar issues

[janbiedermann]

Re 2. figuring out how ServerOps are going to get called from the client:

For the time of transitioning, this could be done in a server side JS engine, bridging to the crystal backend. This way you can run the opal code on the server side, calling via the bridge in to the crystal backend. For example.