[racket] Dr. Racket for iOS

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Mon Apr 7 17:29:20 EDT 2014

Rather than iOS-specific and Android-specific apps (either JVM-ish or 
native code), I'd like to suggest focusing instead on targeting *HTML5 
offline apps*.

I'm working successfully on HTML5 offline apps for technical software 
right now, and I think HTML5 is a good way to go to get device 
independence, at the same time as making the apps not necessarily 
cloud-lock-in/spyware (like most mobile apps and services right now have 
become).

On the impractical side, JavaScript is simply an awful language for app 
development, for no good reason.  (JavaScript was better as a tiny 
script language for hooking up Java applets in Web pages, and it hasn't 
evolved as well as it could've.)

So I'm seeing a few different ways that Racket could fit with offline 
HTML5 apps:

* Just doing the app in HTML5 and JS, but use Racket on the server.

* Like #1, but use Racket as a compilation step to add something more 
like macro facilities to HTML and JS.

* Write key app algorithms in Racket and have translated to JS. (Note: 
This is for nontrivial algorithms.  Practical JS is so intertwined with 
DOM manipulation, and working with libraries/frameworks oriented towards 
JS dumbness, that I'm not seeing benefit trying to generate all the JS 
code from Racket, only select pieces.)  (Incidentally, this might also 
give you obfuscation, which sometimes you might want if the copyright 
owner doesn't want to share source and give away rights to copy&paste 
'derivative works' and such.  But the main benefit is to write 
algorithms in a real language rather than a scripting language.)

* Write entire app in Racket, forgetting about existing HTML5 
frameworks, using Racket UI facilities (perhaps the same MrEd GUI and 
eventspace stuff as used by DrRacket et al.).  Have this compiled to JS 
or a JS-implemented VM, together with DOM/CSS/canvas/etc. for the UI.  
You could implement a large persistent filesystem that DrRacket sees 
using HTML5 IndexedDB (and Web SQL on iOS, until they decide to join 
everyone else with IndexedDB).  Then you might be able to get the 
existing DrRacket source to compile to this HTML5, and then run on all 
the modern tablets in browsers and as offline apps, maybe with OK 
performance.

I think Danny Yoo's Whalesong(?) might have much of the same idea as the 
last option, but I haven't looked at it, and don't know how much of his 
implementation could be reused for this somewhat different purpose.

Neil V.


Posted on the users mailing list.