
Luna, the in-house web framework developed at Asana - jamesjyu
http://asana.com/luna/
======
jashkenas
For the record:

[http://www.quora.com/Why-is-Asana-developing-their-own-
progr...](http://www.quora.com/Why-is-Asana-developing-their-own-programming-
language-\(Lunascript\))

To quote:

    
    
        Update: For the last few months, Asana has moved from 
        writing Lunascript for our application code to Javascript. 
        The two main things that were slowing down our development:
        too much remaining research-level work to make the compiler 
        output more performant code
        lack of tool support
    
        We're *not* a framework company, so we didn't want to devote 
        years to this work at the expense of building our product. We're 
        still using the framework primitives we developed for the 
        language -- most importantly, systems for reactively recomputing     
        our UI and synchronizing changes with the server -- we're just no 
        longer using the slightly nicer syntax (and functional style) 
        that Lunascript provided.
    
        Long term, we may revive the Lunascript compiler. We think this 
        may be especially appealing once we shift from focusing Asana as 
        a single product to Asana as a platform. But for the immediate 
        future, we're focused on releasing our first product at the 
        expense of continuing work on Lunascript proper.

~~~
ardit33
Nice find. I think it Lunascript might the classical case of programmer
naiveté: "I can re-invent the wheel so much better, and it will take not that
much time". Usually is part of the process of maturing up as a
programmer/engineer. Get the main stuff done (wow, this looks like a cool
idea), but soon you are treading in deep waters as soon as the technology
start hitting the edge cases, and day to day usability.

My self have started a couple of these overambitious projects, without
realizing the amount of work it takes to get something in production level.
Sure you can cover the base functionality pretty quickly, but it is the edge
cases and polishing and making a robust solution that actually take the most
time.

Sometimes these over-ambitious projects, succeed (Linux is the prime example),
but usually they do because there is a huge need in the market for such
product.

Perhaps Lunascript is something more 'interesting in paper, but not that great
in practice'.

~~~
jacques_chester
> Sometimes these over-ambitious projects, succeed (Linux is the prime
> example), but usually they do because there is a huge need in the market for
> such product.

Linux was not _that_ ambitious to start with. That's why it succeeded: while
everyone else was waiting for Hurd or AT&T-free BSD, Linux was rapidly gaining
momentum.

~~~
jpadvo
> I'm doing a (free) operating system (just a hobby, won't be big and
> professional like gnu)

[http://www.thelinuxdaily.com/2010/04/the-first-linux-
announc...](http://www.thelinuxdaily.com/2010/04/the-first-linux-announcement-
from-linus-torvalds/)

------
aston
That blog post is from a year ago. In the intervening time, Asana's actually
moved away from developing Lunascript. [1] Instead, they're just coding in
Javascript. There's a lesson in there somewhere [2]

[1] [http://www.quora.com/Why-is-Asana-developing-their-own-
progr...](http://www.quora.com/Why-is-Asana-developing-their-own-programming-
language-\(Lunascript\)/answer/Jack-Stahl)

[2] <http://www.joelonsoftware.com/articles/fog0000000018.html>

~~~
jackstahl
:P It's important to note that we abandoned (or "put on hold") Lunascript, but
_not_ Luna. The vision for Luna always revolved around making it easy to write
bug-free, real-time, responsive, collaborative, interactive webapps. The
syntax of Lunascript over directly using the framework in Javascript was
always a nice-to-have.

I'm not denying your lesson, of course. To this day we still have some
Lunascript in the codebase, and it does create some developer friction that
costs real time. In retrospect, I'm sure it seems obvious that we should
skipped the language and just built the framework.

However, it's important to understand that the language itself was built
mostly by Justin very early in the company's history, and basically no work
was poured into it after we hired employees and built out the product. One
framing of Lunascript is two guys taking a few months to try a few big ideas
out before building a company they want to do the right way. We always knew we
would have to compromise on ideals once we moved forward, but we wanted to see
what stuck. I think a lot of the reason we're under scrutiny here is because
people look at the time since D+J left Facebook and are like "what did you
guys do with all that time?" The answer is the company didn't get started in
earnest until almost a year later when we hired Greg and Malcolm.

------
netmau5
Rewriting a web framework from the ground up is so often a trap made alluring
by the illusion of repeated code. Could there be a more optimal way of writing
UI code? Of course. But a lot of UI code should just be treated for what it
is: largely unmaintainable and unextendable, especially in the face of design
changes. I'd love to spend a weekend hacking out a sexy, interactive app, but
I'm not yet willing to invest 2 years to save a couple days of redundant
development. I'll leave that for the companies not worried about making money
or do it on the side through an open source project.

~~~
barrkel
Two people, six months - most of it discussion, ~40K C# code, in my previous
job we had a framework, compiler, debugger, mini IDE, app server with a kind
of tiny in-memory database (supported object-graph-style navigation) that let
us write interactive UIs using databinding with minimal repeated or hacky
code, and a whole bunch of other hard-to attain features (for example,
application code version rollovers with old sessions running in parallel with
new versions until they're finished with, without needing to restart any
process or machine anywhere). I've seen it done - more than that, I've been
part of doing it - and I have yet, in the intervening 4 years, to see anything
as well suited to its purpose.

It's cheap and easy to be cynical about these kinds of things. But it's very
important to realise that there is so much that is possible today, but will be
dismissed by cynics, that tomorrow we'll say "sure, that was easy, anybody
could have done it" - but very few did.

~~~
netmau5
I've never seen this problem better solved in a web framework than in some
combination of libraries. I'm sure it can be done and I welcome people who
want to do it, all I'm saying is that I couldn't justify the ROI on it myself.
On our projects, we get 90% of the way there by using a server-side REST
library coupled with a small Javascript library on the client to handle the
common paths.

Anywho, cynics are useful- they make us reconsider the value proposition we
are putting forward. However, an idea shouldn't be discarded just because a
cynic addressed it :)

------
davidmathers
Short version:

 _A Lunascript application specifes a data model and a function from the model
to the view or user interface, annotated with handler functions from user
inputs to model mutations. From this the Lunascript compiler produces a
functioning Web 2.0 application — the client-side JavaScript, the server-side
SQL, and everything in between_

 _Debugging can still be somewhat tricky, but we are disciplined about
creating and improving debugging tools_

 _We hope to release Lunascript more widely once it’s more mature_

------
catshirt
the few core features of the video seem generally unnecessary. automatic data
binding on multiple clients and auto syncing with offline storage is cool- but
not really imperative for most apps to get started (which is where tools like
this will shine).

that said, the project is obviously young and i obviously know very little
about it, so i am interested to see how it develops.

 _that_ said, this is a problem many have tried to solve (without writing
their own language), and (imho) failed. backbone is (imho) taking the first
step in the right direction. to be clear, i am not comparing lunascript to
backbone directly. they seem to be two very different solutions for the same
problem.

------
draegtun
Been posted to HN a few times before. Here is one from just over a year ago
with lots of comments: <http://news.ycombinator.com/item?id=1097235>

------
jhrobert
To some extend Angular is doing something similar today and it's available,
<http://angularjs.org>

It does not synchronize multiple clients yet, but I certainly wish it will ;
with Comet becoming increasingly easy to integrate, this may happen sooner
than expected.

