

LLJS: Low-Level JavaScript - wamatt
http://lljs.org/

======
zx2c4
Despite my usual cynicism about #javascripthipster projects, this does
actually look kinda neat.

The one thing that rubbed me the wrong way is the "let" keyword. Why can't we
just declare variables without it, like C does? I suppose because they want to
rely on JavaScript's own scoping rules?

What would be cooler would be if they could just totally do away with making
actual JavaScript variable declarations or function calls, save for the set of
typed arrays, pushing and popping variables on and off the stack for function
calls, and then coming up with some horrible hack for implementing jmps in a
language with no goto. I'm sure this wouldn't really make things more
efficient, but it'd be interesting to read.

I guess though, there's always the source of emscripten for that delight.

~~~
mbebenita
Relying on JS function calls and variable declarations is actually more
efficient in this case since the underlying JS JIT can perform a lot of
optimizations (SSA / Register Allocation). We do stack allocation for structs
and local variables for which you need to take the addresses of.

The "let" keyword is left in there because we wanted to stay compatible with
JS. So any JS program is also an LLJS program. This way it would be easy to
integrate into an existing code base. As for the "let" vs. "var" debate, we
chose "let" because of its block scoping semantics and because we didn't want
to let variable declarations alias each other with different types.

------
Ygg2
Running examples on Chrome with Win 7 crashes the tab. It's not that big deal,
but for now other than a neat way for crashing your browser I don't see any
application for this framework/library.

~~~
sitkack
Crashes iPad 1 with iOS 5.1

~~~
akadien
Half of the web seems to crash iPad 1 these days.

~~~
hellrich
Not enough RAM.

~~~
brooksbp
Nearly all of the web crashes my iPhone 3G.

------
lucian1900
This is actually pretty interesting. Some of the performance benefits of C
(known types, little and predictable allocation) without its total lack of any
safety. Syntax still sucks, but not much can be done about that while still
looking like JS.

On the other hand, any runtime that infers structure (like V8 or PyPy) will
make most of the performance benefits moot, leaving only predictable
allocation (fewer and shorter GC pauses).

~~~
tomp
The syntax doesn't matter; if the browsers implement something like this, it
will make javascript a much more compelling target for compilers (even of
fast, statically typed languages), so you can make your own syntax above it!

~~~
lucian1900
I meant that the syntax still has plenty of pitfalls. Compilers can already
uses the same features lljs is using and just generate JS.

------
suprememoocow
Oh dear. The site immediately crashes Chrome (Version 22.0.1229.79 m) on
Windows XP.

~~~
zapu
Same here. Also Chrome and Windows XP. But it manages to load after few
refreshes.

But I can't run any of the "demos".

------
zumosol
benchmark: time for the loop with signed integers: lljs = 116 ms, sbcl =
0.026, so lljs is still five times slower than sbcl in my computer (64 bits,
ubuntu). Compiled in: 32 ms
\----------------------------------------------------- Timer: 116 ms: Empty
For loop with signed integers. Timer: 604 ms: Empty For loop with unsigned
integers. Timer: 115 ms: Empty For loop with untyped integers.
\----------------------------------------------------- Executed in : 835 ms.

(time (loop for i fixnum below 50000000 do (progn nil)))

Evaluation took: 0.026 seconds of real time 0.028001 seconds of total run time
(0.024001 user, 0.004000 system) 107.69% CPU 53,460,529 processor cycles 0
bytes consed

NIL

------
djhworld
Nice.

    
    
      For now, we allocate one large chunk of memory 32 MB and let  malloc and free manage it.
    

32mb sounds like a lot

~~~
achille
The render process on very page you're on right now consumes 116mb, see:
<http://i.imgur.com/gCA1C.png>

~~~
haldean
Are you on a Retina display? That screenshot is beautiful (and huge).

------
m0skit0
I don't see what benefits this has C doesn't... maybe someone will see them.
Anyway cool idea and runs flawlessly in Firefox 15.0.1@Ubuntu 12.04.

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

~~~
agentultra
<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?

~~~
andreasvc
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?

~~~
agentultra
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.

------
jhrobert
Cool. This leverages JIT compilers ability to generate fast code (at the
expense of language expressiveness, for it obviously works well with static
style code only).

I wonder what a "JavaScript JIT optimized C dialect" would be? Ie. what are
the C mechanisms that are too expensive with today's JIT engines?

------
djhworld
Can any javascript people explain this piece of code

    
    
        const $M = require('memory');
    

That the compiler outputs as JS? Is the 'require('memory')' something that is
native to the JS runtime?

~~~
mbebenita
"require('memory')" gives you back a JS module that's written in LLJS
(<http://git.io/vHeH2g>). It exports several typed array views and a few
functions like malloc() / free(). It's all JavaScript, nothing native.

~~~
djhworld
So clients will have to download this to their machines (via CDN?)

~~~
cshesse
It looks like if you want the memcheck functionality on the client,
memcheck.js must be distributed with your "compiled" javascript code.

------
yalogin
I don't work with JS. Can someone explain to me how I can use it as a
developer? Should I be writing code in the intermediate representation and
then compile it into JS?

------
p0nce
Neat but the target language does not seem like regular Javascript.

~~~
judofyr
Ehm, it's valid JavaScript. What is not "regular" about it?

~~~
djhworld
He probably meant to say "readable"

~~~
evincarofautumn
Generated code rarely is. The compiler I maintain at work had “readable
output” as one of its early goals. That was abandoned around when we started
adding optimisations.

------
mgaudin
Same here. Crashes for Windows 7 Chrome Version 22.0.1229.92 m

------
error54
Crashes tab on load. Chrome 24.0.1284.2 on WinXP.

------
davvid
this keeps crashing my golden oldy iOS device. it must be webkit since others
are getting chrome crashes too.

~~~
dugmartin
Immediate crash for me too on my iPad 1 with iOS 5.1.

------
overbroad
Oxymoron.

