LLJS: Low-Level JavaScript

Re:LLJS: Low-Level JavaScript by andreasvc on Tuesday October 09, 2012 @07:56AM (#4631005)

Does C run in Firefox? No? Well there you have your benefit.

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by agentultra on Tuesday October 09, 2012 @09:49AM (#4631453)

http://www.cs.cornell.edu/home/ulfar/cuba/paper/

Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way.

Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by LnxPrgr3 on Tuesday October 09, 2012 @11:23AM (#4631995)

Google's already on it: https://developers.google.com/native-client/

Some part of this seems unsafe intuitively, but then I'm reminded sandboxed interpreted languages don't have the best security track record either.

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by andreasvc on Tuesday October 09, 2012 @11:13AM (#4631941)

An important reason is security. The security of any web language is of vital importance, for obvious reasons. When you go low level or introduce umpteen different languages, maintaining the same level of security becomes increasingly challenging.

But I agree with you that JS is an unfortunate language to be stuck with (although many people appear to be content with it). I especially dislike that it's weakly typed.

Isn't Google's NativeClient something like what you're suggesting though?

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by agentultra on Tuesday October 09, 2012 @12:29PM (#4632437)

I'm not suggesting anything, the paper I linked just described one such method for executed untrusted binary code through the browser.

At a cursory glance it looks like NativeClient is built on a sandbox and doesn't allow arbitrary binary applications to run natively on the OS. It doesn't allow system calls and looks like some sort of run-time manages memory on behalf of the application.

If you're at all interested, it cannot hurt to read the paper I linked to. It was written in 1997 and requires a little bit of historical forgiveness but the ideas are rather quite interesting.

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by mbetter on Tuesday October 09, 2012 @10:57AM (#4631836)

You get on that, let me know how it turns out.

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by billwashere on Tuesday October 09, 2012 @07:58AM (#4631012)

How about emscripten then? https://github.com/kripken/emscripten

*Not that I would.

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by andreasvc on Tuesday October 09, 2012 @08:03AM (#4631029)

Well that seems to be a competitor. If you'd asked me the benefit of emscripten over this I wouldn't have known, but the question was about C.

[ Parent | on HN ]

Re:LLJS: Low-Level JavaScript by mbebenita on Tuesday October 09, 2012 @09:14AM (#4631302)

The benefit over Emscripten is that LLJS makes it easier to mix JS and C-like code and skip the C/C++ tool chain. Of course, the drawback is that you miss out on all the LLVM optimizations.

[ Parent | on HN ]