Hacker Newsnew | comments | show | ask | jobs | submit login

Hey - I'm one of the interns that worked on this.

I have my own reservations about JavaScript the language, but after seeing what John had built when I started, I believe that this is undoubtedly the right way to go.

If we wanted to use another language to accomplish similar goals, the options would be:

1. Run the code on the server. This dramatically increases latency, introduces more security concerns and would dramatically increase our costs as this would inflate our server load dramatically. Really, its the latency here that makes this a no-go. As you use the number scrubber, it's re-executing several times a second, and that's just not going to work out with client-server communication (even with websockets).

2. Run a different language that compiles to JS and runs in the browser. As it stands, the overhead of doing this is also too much. It would be shipping a compiler or parser down to every client. CoffeeScript may be the most reasonable option there, but it has many of the same warts as JavaScript anyway. Any parser/compiler needed introduces an extra step in the pipeline and would inevitably reduce responsiveness.

While JavaScript the language certainly has its problems, it's what it lets you do that counts here.




Run a different language that compiles to JS and runs in the browser. As it stands, the overhead of doing this is also too much.

Not at all--it takes some work, but especially if most programs are less than a few hundred lines long, the overhead is far less than you think!

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: