Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Other languages! Especially JavaScript

BortelsBortels Mod
edited December 2011 in Suggestions Posts: 1,557

So - I've mentioned before that a ton of the value in Codea isn't Lua - I can code in Lua for free elsewhere (or even on the iPad if I pay apple to be a dev) - the value is in the libraries twolivesleft adds, and the editor. It's self-hosting that makes Codea exciting - being able to do an app from start to finish on the same platform I run it on.

I'd pay for that same environment, again, in other languages - and I bet there are coders out there who have said "ooh, I want that... But I'm a YOUR-FAVORITE-LANGUAGE-HERE programmer, I dont want to learn Lua". I mean, I like Lua a lot, but I still think in perl - you want another 8 (or more) bucks from me, give me Codea-with-perl. I'm sure all of the modern interpreted languages are the same in this regard.

But, as much as I hate to say it, JavaScript has a special place here - it has special dispensation, apparently, from apple, and a good version is built-in. I'd rather program in lua than js, but I'd rather have network access and apple not freaking out about what we write than lua (or perl or whatever). And I can do that, today, right now (and have). What I don't have for js right now is... A self-hosted dev environment.

This is where you come in maybe.

What I envision is pretty simple - a local web server, maybe only answering on localhost if necessary, and an editor that can make/edit files in its document root. Js and maybe CSS syntax hilighting in the editor. Let the actual code execution happen in mobile safari where apple doesn't care! We have the parts of this already in other apps - editors, and local servers - just put me in a box with a nice bow on top. It shouldn't even phase apple, either, because you aren't even running outside code - ever!

Someone is going to do this, soon I expect. I'd rather it be you guys. Or me :-) but I know how hard a good robust editor is to make. (I've tried this with Bespin, but the local web server at the same time as the browser is what breaks me. I am NOT sure we can even multitask like that... Yet. You might need to not use safari proper, dunno)

PS. For the local web server, node.js would be awesome - but could end up opening up the same sorts of external unreviewed code loading issues you have now. Or - maybe not? It's JavaScript. But it's also a different engine. Worth considering.


  • beebee
    Posts: 377

    Instead of putting JS into Codea, why not 2LL make Codea-for-JS? :)

  • Maybe an in-app Thing where everyone can buy other programming languages, and then a language is set for every projekt?

  • Textastic is good editor and can run js.

  • SimeonSimeon Admin Mod
    Posts: 4,430

    Js would run through a web view, so you wouldn't get the OpenGL based renderer.

  • Posts: 273

    FWIW, as a non-programming neophyte I like the ease and simplicity of lua and the fact that the code is terse (no need to declare datatypes, no need to have a semi-colon at the end of every line, etc.).

    Codea's graphic functions, editing interface and lua seem a perfect match for the iPad. Using Codea (and lua) I'm constantly amazed at how quickly and fluidly I'm able to tinker with an idea.

  • I agree with @Bortels. An HTML5/JavaScript version would be VERY interesting to both kids and professional web developers. It would also neatly sidestep any sharing issues with apple, as you would just go to web pages in their own browser.

    Plus, given all the google progress in this direction, I would predict that OpenGL or WebGL will be integrated within a version or two. In the meantime you could easily integrate paper.js, or Processing code.


  • BortelsBortels Mod
    Posts: 1,557

    Frankly - canvas isn't bad at all, and web kit has a lot of the OpenGL-ish spice - transforms, and so on. Really, my main issues with js are a lack of self-hosting, which this would solve nicely, and speed. Bad past experiences with cross-browser issues. But again - I would trade those for self-hosting and a lack of Apple interfering, and the speed and features are always improving.

    I also think, as @alveda suggests, the potential user base for this may be an order of magnitude bigger than for lua. JavaScript is hot right now. And I agree -we'll see webgl in mobile safari soon (ipad3 I'm hoping)... And that would be "free" functionality for you.

    As an aside: does a web view come with js processing? If so - my "let us render HTML and svg" suggestion takes on added functionality. It's silly to have to say "to info from the web, you'd need to write it in another language, and render that to an image you won't use..." but meh - maybe that sort of silly is what we need to illustrate to apple this policy needs modification.

  • AND you nicely incorporate my web server and all the HTTP sexiness!

  • Posts: 2,820

    Codea might as well make their own language by combining languages. I'd be fine with that. Right now, I use Textastic to program things like websites. I ran across this video righ here that allows you to code apps and install them on your iPad. I'm away from my mac and haven't set up server, so somebody should check it out.

  • Posts: 2,820

    Different languages? Im leaning to no. Too complex in my opinion. Stick with Lua and add to it. It's and amazing language.

  • BortelsBortels Mod
    Posts: 1,557

    You're missing the point, Zoyt - Apple's rules seem to be different for javascript (or at least their javascript in mobile safari). The idea was to try to work around their restrictions by doing it the way they seem to want. It does us no good to, say, add sockets to lua if apple is just going to reject it.

  • NatNat
    Posts: 143

    You can run Processing.js programs on the iPad.

  • Posts: 2,160

    Wow! I hadn't heard of Processing.js before. Looks, frankly, amazing. It is quite possible that if I'd come across it a few months ago, I wouldn't have started on Codea (I was looking for a processing-like thing for the iPad). Now that I have, and invested a fair amount of time and effort in learning it, then I'm reluctant to go back.

    However, it does make me ponder whether or not one could write a Codea.js that could take a Codea program and convert it to javascript to be truly cross-platform. One couldn't do everything - touches would be limited to single touch and gravitational stuff would be out - but it would solve one of my "problems" with Codea: the restriction to the iPad. This is problematic in two ways: I'm developing applications with Codea for use in my lectures, where I use an iPad. As they run on the iPad, I can demonstrate them. But then students without an iPad can't download them and play with them (LoveCodify seems a little complicated for this). I'd also like to be able to write some similar apps for some other educators who aren't using iPads but laptops. Since I now know Codea quite well, and have a fairly large library of easily-reusable code, I'd like to do that in Codea. But then again I'd like to drop the files onto a non-iPad and know that they are usable.

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 4,430

    @Andrew we're currently working on extracting the engine from Codea to release as open source. Hopefully with a command-line Mac OS X tool to run project bundles, and of course, an iOS example app that runs .codea bundles.

    Edit: While Mac OS X support should be fairly straight forward I imagine Windows and Linux will be fairly significant undertakings.

  • Posts: 2,160

    I'm vaguely aware of that, and it would be great to have.

    What impressed me most in my brief glance at iProcessing.js was that it wasn't at the engine level but at the script level. It looks as though it takes a Processing program and then reinterprets it as javascript code. So I had in mind a much smaller project than extracting the engine from Codea: simply a lua interpreter in javascript wrapped around with a setup and draw function and a simplified touch call.

    As a hacker, not a programmer, having to learn a new language each time I want to do a new thing is a bit of a hassle. So far, I've had to learn snatches of Perl, PHP, python, ruby, javascript, java (aka processing), lua, c, c++, TeX just so that I can get something working that I want to use. Of those, I guess I feel okay with Perl, TeX, and probably now Lua (I'm just waiting for a few free days to see what I can do with LuaTeX ...). So the idea of being able to take, in this case, a Processing (java) program and directly drop it into a completely different context is fantastic. I would really love to be able to take a Codea program (perhaps with a little modification for the reduced environment) and drop it onto the web.

    Don't get me wrong, I think Codea is absolutely fantastic, and as I get more dependent on my iPad for "doing stuff" then my own issues with being tied to that platform become more and more ephemeral. However, for the reasons described above, I can't just consider my own use of my code - I want others to be able to use it, and can't assume that they have an iPad.

  • SimeonSimeon Admin Mod
    Posts: 4,430

    Web based would be best, but it's also trickiest for the reasons you mention.

    Interestingly, there are a few Lua interpreters written in Javascript. One of them is here:

    (Project wiki:

    So it's possible. The hardest bit would be getting high performance graphics rendering across browsers. My bet would be on WebGL, but at the moment that's limited to Chrome.

  • Posts: 2,160

    I'd be happy with low performance for the time-being (Firefox claims WebGL - and at a higher level of compliance than Chrome -, though after installing the necessary library I found it crashed FF a couple of times). Moreover, as Codea is essentially a 2D system (despite my best efforts), it might be possible to do the non-mesh stuff without WebGL.

  • SimeonSimeon Admin Mod
    Posts: 4,430

    It would be possible to rewrite. Processing does this and offers a few different renderers.

    WebGL offers the easiest path in terms of porting though, as the shaders and engine design could largely be used as-is.

    These are all thoughts for after the initial open source release, though. Maybe someone will take it upon themselves to use the source code to create a web version, or support some other platform — that would be the best outcome. We don't have the resources to maintain that many branches.

  • Posts: 2,820

    Your right. Mabey JavaScript/HTML5 would work but that would be a hassle to put together in my opinion. Hmm. There are still other features I'd like first.

  • NatNat
    Posts: 143

    My opinion is that Lua is a nicer language than Javascript: fewer warts, less unexpected behaviour. That makes it easier to learn than Javascript -- I picked it up in a couple of commutes, including the metatable stuff. And it's widely used in games programming, making Codea more useful as a game prototyping tool.

    I still haven't learned all the ways that Javascript can help me shoot myself in the foot!

    So, I think Lua is a great choice for Codea.

  • BortelsBortels Mod
    Posts: 1,557

    Every time I get frustrated with Codea - or rather, frustrated with Apple's arbitrary restrictions on it - I go back to javascript and the web for a day or so, and that tends to reset reality. Javascript and the web, even saying "this will target ipad only", is... complex. And ugly. And there's still no good way to do the dev on the ipad. And it has other weird restrictions (try reading the keyboard without a text box up - works in any browser except mobile safari).

    Plus, compared to Codea, performance sucks - especially graphical. that's changing, but meh.

  • Posts: 1,207

    Yeah, I think the biggest things I like about Codea are it's relative cleanness compared to JavaScript or C++, it's relatively nonsense-free syntax when compared to Objective C, and it's graphics focus. Put the three together, and you just pick it up and code.

  • Posts: 2,820

    "And there's still no good way to do the dev on the ipad. " -@Bortels
    I like to use Textastic A LOT. It may not be the best coder, but it is wonderful in my opinion.

  • DylanDylan Admin Mod
    Posts: 121

    My experience with javascript on iOS is that it tends to be fairly slow. Only Mobile Safari has access to JIT compiling, any other app cannot execute data pages (ie, anything not in the signed binary), so you can't do JIT. That means even if we used a Webview, the javascript it ran would be significantly slower than Lua (which is a speedy little language even without JIT, unlike javascript.) Not to mention the overhead of Webkit's renderer compared to our direct access to the graphics hardware.

    As you can see in the iProcessing demo video, it is struggling with a few solid filled circles. Doing anything remotely interesting would probably cause significant slowdowns.

  • Posts: 2,820

    Just an idea @Dylan - You could have an in-app preview and then say "Test in safari". Safari can read the app's files if you allow it, right? But anyways, you would make an engine for the Lua part of it. But first, I really want sprite packs.

  • Posts: 2,820

    And working out sockets with apple

  • guys, check out - it has PHP and looks pretty neat

  • BortelsBortels Mod
    Posts: 1,557

    cute. I'm taking a look, will report back.

  • BortelsBortels Mod
    Posts: 1,557

    So - it's cute. It's just what you'd think it is; a WebUI, with a PHP interpreter built-in. You can do html pages, and javascript, but it clearly is intended to be used for php mainly. It does not use the itunes document import/export, and I don't see any import/export, so it looks like it's in the cut/paste regime as well, although it comes with some binary images - so maybe I'm missing something, I don't see a way to import new ones.

    I'll bet money it's javascript support is identical to the regular safari support - ie. no access to the photo roll or camera or such, ditto php.

  • edited August 2012 Posts: 580

    Here's something that may be of interest: Riq over at cocos2d has been adding JavaScript bindings to cocos2d 2:

    I'd be lying if I said that I haven't considered the possibility over the last couple of weeks of making a cocos2d-based iPad app similar to Codea that would take advantage of the JavaScript bindings. One awesome benefit of such an app is that anything done through that app could work on the web, iOS, and Android, essentially for "free" (I know, I know, "write once, run everywhere" typically ends up being "write once, debug everywhere", but given that cocos2d has already been ported to virtually every platform of consequence and has a massive community, plus other aspects like native rendering, menuing systems, batched rendering/sprite sheets, particles, physics, and a wealth of already available tools, it's very hard to ignore).

  • BortelsBortels Mod
    Posts: 1,557

    Their keyboard is worth a look - I like the five-way keys.

  • Jmv38Jmv38 Mod
    Posts: 3,268

    This discussion is rather old, but i'll add my opinion of casual programmer. A few days ago i wrote in another discussion:

    '' I am always amazed how natural and smooth it is to program in lua: i just copied you code, typed a few lines and it works directly as expected, no bug! I've done quite some programming in Javascript, that's a different story: i almost get one error for each line of code and it takes the hell of a time to have something that finally works. I worship LUA! ''

    if you really want to program in Javascript, then buy textastic it is an excellent dev platform, and and i have made rather complex javascript programs there (including a small offline web-app for ipad). But there are limitations put by big brother on IOS: he won't let you cache locally more than 1 mp3 file, so it makes it very tedious to program an offline game with sound. Also saving images locally after processing in not possible (at least in javascript, maybe in pearl or..?) so it is very limited compared to codea. I have experienced touches, canvas, sounds, orientations in this offline webapp ( a touch timer at for those interested).

    So my wish would be: keep focused on improving LUA in CODEA, add libraries and fonctionnality but don't go to other langages, LUA is fine. Just my opinion.

Sign In or Register to comment.