Hi Neil, I can't get past the idea that tablets are a terrible environment to do development. - screen to small & made smaller by on-screen keyboard - limited resources(ram/flash/mhz/cores) compared to a cheap laptop
As for developing for tablets Whalesong is impressive. 'raphael-demo.html [src] Uses features of the JavaScript FFI to access theRaphaelJS vector graphics library.' - http://hashcollision.org/whalesong/ I'll be having a look at doing the same thing with d3 (http://d3js.org/ ). LambdaNative is really interesting, but I wish it was the Racket, with the JIT rather than gambit because I like Racket. Alas a fork is beyond my skills. (and the Racket JIT would probably flatten the battery of a tablet) http://download.racket-lang.org/docs/5.1/html/raco/ext.html LambdaNative 'LambdaNative is a cross-platform development environment written in Scheme, supporting Android, iOS, BlackBerry 10, OS X, Linux, Windows, OpenBSD, NetBSD and OpenWrt.' -- http://www.lambdanative.org Kind regards, Stephen -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile +44 (0)79 85189045 http://www.degabrielle.name/stephen On Mon, Apr 7, 2014 at 10:29 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > 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. > ____________________ Racket Users list: http://lists.racket-lang.org/users
