Consider opal/atom backend

[wasnotrice]

I spent a few hours this weekend working up a new proof-of-concept Shoes backend.

• Compiles Shoes and your Shoes app to Javascript using Opal
• Embeds Opal, Shoes, and your app in an atom-shell window (based on Chromium, this is what the atom editor uses for its windowing)

Here's a "Hello, world!" example.

Shoes.app :width => 300, :height => 300 do
  banner "Hello, world!"
end

I was really impressed that Opal could compile Shoes basically out of the box (all I had to change was to remove parts that use the filesystem...for now). Also really impressed at how easy it was to get a rudimentary backend going, even using two projects that were totally new to me. Thanks, team, for writing extensible, reusable software :smiley:

I think this backend has lots of potential.

• Shoes wants to render like a web page, so I anticipate things like text flow to be pretty simple
• The atom shell already has Windows, Linux, and OS X binaries available for download
• The atom shell has a super slick packaging system. Copy the atom-shell app, and add your app folder. Done.
• While the binaries are not small, they are smaller than our Swt versions: ~35MB zipped, ~90MB unzipped for the OS X version.
• As @PragTob has already noted, this backend could be repurposed for distributing apps as web pages (minus certain features you can't have in a browser).
• While so far, I've just used vanilla Javascript and HTML for the backend (along with some atom-specific stuff for windowing), I'd like to implement the backend using React. I've been using React on a side project, and really liking it. I noticed that the Atom editor also uses it. React is well-suited to our architecture, because it wants to to just feed data to a component and let React take care of it from there. This could simplify the backend a lot.

Questions

• Is it valuable to be working on this right now? Having worked on it some, I expect it to be simpler to implement than Swt, especially since packaging seems to be already worked out (I have packaged an app on on OS X, but not the other platforms).
• If you're not yet convinced that this approach is valuable, what would you like to see in order to be convinced?
• Given discussion in #688 about not splitting off the Swt backend into a separate repository, does it then make sense to bring this backend into the main repository at some point?

Thanks for your feedback!

[PragTob]

Hi @wasnotrice !

As mentioned in your main repository, awesome work and awesome idea. Basically the same questions you posed were also "burning" in my head yesterday evening after seeing it.

I totally agree that a shoes backend that is HTML-ish-JS will probably be a lot simpler and faster because browsers are optimized as hell. And basically shoes tries to imitate the web, so actually having the web at our side would be super awesome and probably easy. I always felt a bit like shoes was some web developers trying to make cool desktop app programming happen. We probably don't even need the positioning code...

On the other hand, I also feel that the JRuby/SWT backend is too close to the finish line to abandon it now. Also there are other concerns for me: JRuby and SWT is battle tested and proven software. Opal and atom-shell are the new cool kids on the block - not as battle tested/ready yet.

Another thing that I've never really done in JS is the whole drawing thing, sure we got canvas et. al. but does that also work well together with text etc.? However I'm sure that there are solutions for this.

So my rough feels/thoughts right now: I see more potential/simplicity in the opal and atom approach but also more unknowns/risks. Plus JRuby/SWT is pretty far down the line. So I feel like finishing that and then exploring Opal/atom as the second backend, which is super promising. But yeah excited and uncertain :)

Also I believe it'd make sense to integrate the code of the second backend into the main repository at some point mainly with the purpose to stabilize the DSL code. E.g. there probably are points where we need to change part of the DSL code as we may need additional calls to backend objects or find that soem DSL stuff is too tightly coupled to the backend implementation. Easiest to resolve when it's all in one repo I guess.

Shoes on! Tobi

[jasonrclark]

This is super cool, and I'm really excited to have a credible second backend that isn't heavily C-based! Personally I'm still pretty keen on pushing JRuby/SWT over the finish-line of a full release given the stability and effort that's been put in, but the Opal/atom combo makes a lot of sense to follow that up with. :sparkles:

[KCErb]

My two cents:

I'm really excited about this idea! I'm excited about anything that helps push Shoes onto more platforms, especially mobile. With Opal in our backend it looks like we can stick a Shoes app on the browser (opal), on the desktop (atom) or into the app stores via cordova / phone gap.

I've been learning Ruboto / Android Development as of late thinking that it might serve as a backend to get Shoes apps onto the AndroidOS, but just this morning I found out about Cordova and am thinking "Man, if you can get your project into HTML5/CSS/JS then you can get it onto any platform in the world."

Yay!

[PragTob]

I don't know about cordova but I know phone gap a bit. Yes exciting technology and the web is awesome! However, at least with phone gap you never really reach native feel afaik.

Plus still hope that opal.rb does good and continues... quite some ruby impls have vanished over time.

There is also ruby motion who just announced Android. They always had iOS but their ruby subset for iOs is... quite limiting.

[elia]

Awesome work! (thanks to @fkchang for spotting it!)

---

remove parts that use the filesystem...for now

@wasnotrice since I was doing stuff with Opal + node-webkit / atom-shell I ended up implementing a bunch of File related stuff for Node: https://github.com/opal/opal/tree/master/stdlib/nodejs I also have a couple of fileutils methods that I'll push soon, anyways contributions and feedback are really welcome :)

[ylluminate]

How awesome. Thanks for sharing!

[illtellyoulater]

This is gonna be a really interpoweful join venture :) I'm sure it will also bring additional spotlight to Ruby. Great idea! Also praise to the JRuby/SWT Shoes development!

[jikkujose]

Opal.rb for implementing apps in mobile might turn out to be PhoneGap all over again. It has many issues, it hardly produces native feel. Its jittery.

[ylluminate]

@JikkuJose show us an example of what you're saying as we are using Opal in production on some quite large sites and now even games and it works fantastic.

[jikkujose]

I am sorry, I have to rephrase. I wasn't talking against Opal use to build web apps. I was talking about web apps being embedded in webkit shells to replicate as native apps.

[ylluminate]

Hmm, I'd love to see an example of this in action to see if that would be the case. Can you throw something together so that we can poke it as per your assumption to see what does happen?

[jikkujose]

Would love to; let me see if I can try to find some time this weekend. Or else, even find some examples of such shells having serious usability issues; I remember Walmart having an app that sucked so bad, even Facebook's exit of hybrid apps was covered in many blogs, finally Gmail's latest version doesn't quite feel native (I consider their web development team to be practically the best, if they can't do it, I would to assume the platform inherently has issues). In short I think the problem stems from the following:

• I think the views rendered in a browser is fundamentally designed to change so fluidly. The browser doing such rapid recalculations is a significant overhead in mobile devices and makes these feel like web apps, which have text reflows/scaling (though many these days have controlled to avoid it, the tell tale signs still sort of shows here and there).
• Secondly the asynchronous loading of pages like in webpages (think layout/images popping up one after the other), breaks the expected experience thats typical of native UI. I think the webkit shell's caching system needs to be behaving differently to fix it.
• Loading of other pages in the app also reminds of the previous issues, especially visible in slower connections.
• And in cases of JS issues (which is quite common even in the best hybrid apps) the app freezes and dies in weird and unpredictable ways.

Note: I wonder how reliable and maintainable the generated JS from Opal can be especially when used in such a shell.

On 9 August 2014 08:45, George Plymale [email protected] wrote:

Hmm, I'd love to see an example of this in action to see if that would be the case. Can you throw something together so that we can poke it as per your assumption to see what does happen?

— Reply to this email directly or view it on GitHub https://github.com/shoes/shoes4/issues/712#issuecomment-51675589.

[elia]

Note: I wonder…

Nothing changes going from web to shell in terms of reliability and maintainability. On the contrary reliability increases by supporting jus WebKit+v8 and everyone knows Ruby is much more maintainable :)

I wonder anyway if this is the right place to discuss such a topic…

[jikkujose]

@ylluminate can you share your contact details? Would love to know a bit more about the large scale Opal apps you have developed.

[krainboltgreene]

I know this is old, but now that Opal has better view layer implementations (like react.rb and clearwater's virtualdom.js wrapper) this should be really easy.

[KCErb]

Updates (just to keep this alive because I think it's great)

• Atom shell is now electron
• I've been focused on learning RubyMotion these days with the long-term goal of getting shoes a native mobile backend. The redpotion and bluepotion gems make RubyMotion development much more Ruby-like which is a huge plus for backend development.
• RubyMotion does ask for money to get access to their Ruby implementations. They ask $100 per year for a student license, but maybe if team Shoes puts together the backend, the RubyMotion team will consider some kind of a Shoes license to let beginners code for free.
• A big downside here is that RubyMotion is OS X only. There is probably zero effort to change that in the near future.

There's a lot going on in the electron and motion communities these days, the Shoes project has the potential to cut out the learning curve for both of these technologies and get new developers into the fun stuff early-on.

On the other hand, I also feel that the JRuby/SWT backend is too close to the finish line to abandon it now.
-- PragTob

Definitely not in favor of abandoning our current backend. It's the scaffolding that's getting this project up and going. I'm just excited by what's beyond the SWT hill, and thinking of that makes me want to stay the course and keep running!

[krainboltgreene]

I'm super in love with Electron, even if I'm no longer in love with Opal. I've already written a microbrowser in Electron and it was very enjoyable.

[wasnotrice]

:+1: