Should we rename?

[barriehadfield]

RE Positioning and the future. crystal-lang/crystal#829 I have been watching webasm rise day by day. Our C# guys are all aflutter with the possibilities and even experimenting with WPF in the browser. The idea of choosing your language to write Fullstack web applications is real and going to happen soon. The rise of Fullstack platforms is imminent. It's a good time to be stabilizing our COMPS architecture and DSL. :-) BUT - we have a problem. Our problem is - will it be more likely that our chosen language will be Ruby or Crystal? I suspect most likely Crystal as Rails is losing popularity fast and the hottest things tech around is Crystal. Imagine: “Hyperloop is a blindingly fast Fullstack web architecture. The fastest way to build and run web applications - all in one language - Crystal”. Look at the claims Amber is making "968,824.35 requests per second: 32 cores at 2.7Ghz” https://github.com/amberframework/amber Now imagine the same sort of claims made about the speed of the client running webasm. (Note that Amber has an ActiveRecord based ORM and nothing really for the client more than Rails). SO, forgive the long message and I hope you are still reading as here is my point - we are badly named Ruby-Hyperloop as the Ruby bit might change. If we are doing a rebrand and a new release, we should think about a new name and new domain. ruby-hyperloop.org is unlikely to fit us. If we are going to change, I would rather do it as one big bang this Xmas - new docs, website, positioning and name. Thoughts?

[sfcgeorge]

Since there's no Opal for Crystal even yet, I think the possibility of a Crystal Hyperloop, or Elixir Hyperloop, or whatever, are years away. Crystal hasn't even reached 1.0 so a Crystal Opal would be constantly in flux, it would be a disaster right now.

In the future sure it's a nice idea, there could be ruby-hyperloop and crystal-hyperloop and elixir-hyperloop. But they won't share any code, Crystal and Ruby aren't compatible and there is no intention for them to be. So any crystal-hyperloop would be a completely separate codebase, just sharing ideas and maybe a feature test suite.

We could have a not-elons-hyperloop.com as an umbrella for all the individual Hyperloop implementations, with the high level architecture overview. But I don't think doing that prematurely is a good idea. All code examples and config etc would still have to be separate. And the architectures might not even be identical since you'd want to follow the conventions of the host language's server framework.

[fzingg]

I like to keep the "Development productivity" as one of the top priority.
So I think 2 important questions are:

1/ Does Hyperloop can be completely separated and be independent from any kind of Back-end or DB with keeping all its functionalities (HyperModel, Policies, broadcasting, ...), and then be interfaced with those Back-end easily ?

->　If the answer is YES, then let's choose the most productive language or way to code a global HYPERLOOP for this transition era and the fullstack future era.

-> If the answer is NO, then we choose to have different HYPERLOOP (ruby-hyperloop, crystal-hyperloop, JS-hyperloop) and provide to users a global solution and ready to use solution where they just need to choose their BE, DB and the most adapted and productive fullstack-Hyperloop module (rails, ...).

So we could have a global website : FULLSTACK-HYPERLOOP and propose different solution to users with kind of guidelines:

WHAT KIND OF APP WOULD YOU LIKE TO BUILD ?
Then provide the best solution and Tutos according to their needs.

As Forrest Chang said few months ago: "HYPERLOOP could save RAILS."
And I think it is a good way to think.
Because I'm sure that's is not for performance that people are not crazy about RAILS (except for specific speed needs off course), it is because they don't know HOW TO PLUG IT WITH A FRONT END. And most of people would rather prefer to start with the developing the FRONT END then go with the BACK-END (which is bad IMO).

So in term of "Development productivity" , we can will have different users, with different needs but all want an EASY TO DEPLOY FULLSTACK APP.
And we can propose that, whatever they needs:

Simple SPA App: JS-Hyperloop , JSON, Node JS
Middle size App: Ruby-Hyperloop, Rails
Big and Ultra performant App: Crystal-Hyperloop, KEMAL, AMBER

FULLSTACK-HYPERLOOP is not only a new performant web framework, it is also a global solution for your application, whatever your needs and business ....

We could have a new FULLSTACK-HYPERLOOP logo, then the RUBY-HYPERLOOP one, JS-HYPERLOOP, CRYSTAL-HYPERLOOP.

[catmando]

@fzingg has got it. Deemphasizes the ruby part.

[barriehadfield]

@sfcgeorge @fzingg @catmando thank you for the replies.

I also think that the right thing to do is de-emphasize the ruby part as this gives us flexibility without needing to make any decisions about the future now.

The easiest thing to do would be to just emphasize Hyperloop with a domain like hyperloop-framework.org or hyperloop-fullstack.org (both available)

A change like that would require minimal re-working of the docs.

[fkchang]

Like @sfcgeorge as much as I like the idea of isomoprhic crystal, it's years away. A big part of why ruby-hyperloop is strong is because it joins 2 large vibrant ecosystems, react.js and Rails, dropping Rails loses a lot of that. I always thought that was a big selling point - quick and easy from both front and backends, drop in a lot of code from npm and rubygems and lego together your app. I think an all opal full stack framework has promise too, the hard part is "Rubyfying" the node side of things, but I'd want the same promise of ruby-hyperloop, easy to lego the backend together (but w/a better programming language). So rack-hyperloop is probably a good step in abstracting things away from Rails so that we can target other backends with a high level of functionality, 1st non Rails, then perhaps all Opal, then non Ruby backends.

[ylluminate]

De-emphasis + a generalized abstraction layer is definitely the right approach here. Opal and Crystal are close enough that we can get away with calling them isomorphic and a guide and some conventions to keep it sane where there could be potential mismatches would do the trick. Mating up with these Crystal backends such as Amber & Lucky (pleased to see the Lucky creator even liking this in that thread) will really bolster Hyperloop + Opal in general.

You know, I really feel that Crystal is not so far removed from Ruby that Opal could not become the answer in and of itself for vertical stack for Crystal proper. It might be worth investigating, but I don't think it's essential even if there isn't an interest in becoming that.

[ylluminate]

Side note about Crystal: I didn't realize just how quickly the language was heating up. Did you know on the TIOBA index that it's gone from not even being in the top 50 six months ago to position 24 this month of November? Last month it was at 28 and in September it was at 31. It finally popped out of position 60 in August to 32 with TIOBE saying this:

"Especially Crystal with its jump from position 60 to 32 in one month is doing very well. The Crystal programming language is a statically typed Ruby variant. Since it is compiled it is superfast and has a small memory footprint without losing the feeling of being easy to use. It seems worthwhile to give it a try."

[fzingg]

@barriehadfield Like very much hyperloop-fullstack.org

[catmando]

Why not fullstack-hyperloop.org
Or hyperloop-framework.org

[ylluminate]

Seems like the "*framework.tld" is becoming the convention... Hmm.

[catmando]

Ahhh tx!

[barriehadfield]

Some available domains - please vote for one of these or suggest another:

hyperloop-fullstack.org
fullstack-hyperloop.org
fullstack-hyperloop.io (but $100 a year)
hyperloop-fullstack.io (but $100 a year)
hyper-stack.org
hyperstack.tech ($30 a year)
fullstack.im
hyperstack.org (for sale $700)

@ylluminate I could not find a tld domain...

[barriehadfield]

My first choice is hyperstack.tech and second, hyperstack.org and I would be happy to split the cost between a few of us

[fzingg]

Yes, I like hyperstack as well.

1. hyperstack.tech
2. hyperstack.org
3. hyper-stack.org

[catmando]

I'm also for buying hyperstack and will contribute

[catmando]

The hyperloop fullstack framework or "hyperstack" for short. Build apps in ruby, js, closure or crystal... Blah blah

[ylluminate]

Hyperstack is really nice.

[janbiedermann]

Hyperstack 👍

[barriehadfield]

Very happy to say that hyperstack.org and hyperstack.xyz have been sponsored by the company I work for www.workshare.com :-)

[sfcgeorge]

Wonderful! Though Hyperstack.org seems to redirect to spam, are we sure it's available?

[barriehadfield]

Let's hope so, the transfer is said to take up to 10 days. It's through name.com so hopefully, they do have the right to sell it.

[barriehadfield]

Good news - hyperstack.org came through. I have pointed it to a non-existent Github account for now which is better than the dodgy spam before!

[barriehadfield]

Closing as this is now underway