Lambda the Ultimate

AltJS is a good list, though it may not be as structured as you like.

I hoped Ehud would get more responses. Do you mind if I ask naive questions? Just to provoke a thread or two of discussion? I can't participate beyond asking questions, because I don't know much yet, and likely won't learn more than I need for a personal project later. I'd most like to hear about JS as a target, either in a browser or outside if that's possible. (Is it possible? See, a naive question.)

I've heard a lot of about JS, so most of what I know is hearsay. My attitude is mostly neutral, but Dr. House would say everyone has an agenda. So I'll try to summarize mine: I don't care much, but I can see using it. I don't know Brendan beyond a brief chat in the late 90's, and I have almost no history of JS discussion. Sometime in the early to mid 90's, an old boss of mine contacted me to ask if I could write a clone of JS (because I liked languages). I asked, where's the spec? After skimming, I got back to him and replied: No, because it assumes a DOM exists, and a lot of semantics are wrapped up in that — I don't have the DOM and other features looked light. So you see, I still wonder about DOM dependencies. Does JS make sense without a DOM? Or is a DOM always present even in a server side deployment?

What depends on what? I can ask this a lot of ways, in terms of dependencies in any layer you want to discuss. (I'm fully ignorant, so you can say anything without my objecting, "But I know that already.") I won't recognize any tech involved, beyond names alone, so any explanation will only make sense if each term is briefly defined. The good part is: I don't mind if you try to make me look stupid; I don't care, and being lectured like an idiot can be informative. (I'll play dummy as needed.) Suppose you love a library named foo.js, and use that to illustrate a point. At best I may ask, "Is that for async stuff?" Because I don't know the first thing about it. Better form might say instead, "leverage foo.js here, which is used to do XYZ in general, with specific details ABC." Then I'll get a glimmer.

I get the idea JS assumes a browser as operating system. Is that a good metaphor? Outside a browser, do you pretend there's a browser? Or use another subset of JS that assumes almost nothing?

I may use a browser as UI someday for a daemon, which otherwise had no front end other than what you add to it that sends presentation for whatever protocol was involved. Probably JS would make sense in some contexts. That would likely involve compiling something else to JS, in my case, so you can see why I care enough to learn more. Thus each low-level library I hear about, like asm.js, sounds tantalizing as a low-dependency target that might simplify tasks of UI generation in a browser for a daemon doing nothing at all related to either JS or a browser.

Is it feasible to learn enough JS for such a task without having to learn so much it's like becoming a full-time frontend developer? I have no such interest, and no one will ever pay me to learn JS for frontend work when they want me to hunt ogres in backend code instead. I guess I'm interested in a view of JS for folks who have no intention of becoming web app devs. Is there such a view? Or is JS embedded in a world view that assumes the only thing you could possibly want to do is develop web apps?

Are there any books on learning the smallest amount about JS possible to approach use as a compilation target? A book that doesn't assume you don't know how to program, but are hoping to be a web app dev when you grow up? I'm sure you get what I mean. I guess I worry such a book would only be aimed at someone who wanted to become a total expert in JS; that wouldn't be much better.

I can ask more naive questions if anyone wants more priming. You can also answer a naive question I didn't ask; just say, "I'll pretend you had asked ... and here's the answer: tada." That's helpful too. [Edit: to -> do; can't -> can; other rewording. Gratuitous dialog.]

Crash: Stupid question. Go to Google, type "javascript", hit enter.
Wil: Right, why didn't I think of that?

So one of the things with JavaScript is that lots of people don't really like it that much, but they still want to write browser apps. Therefore, a number of organizations/projects/people are coming up with alternative languages/run-time environments that compile to JS, because JS is so widely deployed that it's very hard to replace.

So, on the one hand, you have the camp that says we should have something lower-level in the browser (aka "bytecode for the web"). I think the biggest project here is Google's NaCl, an attempt to compile a statically verified subset of C (or C++?) into something that can be run inside the browser environment (i.e. with access to DOM and other web-as-platform infrastructure/APIs). NaCl is mostly a custom compiler, AFAIK, in other words, not so portable. The next step up from that is PNaCl, which can be described as an attempt to do NaCl by building on LLVM infrastructure, which should in theory make it more portable. The major perceived problem with this is, as communicated by Mozilla, that it extends the web-as-platform with a set of native API's (mostly called Pepper) that so far is very tied to Chrome internals and is not at all developed in the open or, really, in any organized way.

Also firmly in the replacing camp is Google's Dart. I haven't looked much at it, but it's not had a very positive reception. It's a lower-level language (i.e. at least with optional static typing) which comes with both a compiles-to-JS mode and an actual VM (Chrome-only, IIRC).

Similarly, but apparently somewhat better, is Microsoft's TypeScript. It should be similar in scope to Dart, but more cleanly extends JavaScript. Also with optional static typing, I think.

Mozilla so far rejects Pepper/NaCl for being too platform-specific, and argues that JS is here to stay, and is actually good enough to be used itself as bytecode-for-the-web, i.e. a compiler target. To prove this, they have been working on Emscripten, which is an LLVM-based C++-to-JavaScript compiler which has gotten many good results; they can basically compile whole 3D gaming engines and your run of the mill UNIX libraries to stuff that will somehow run in the browser, with decent performance (and actual JavaScript, so portable to all browsers and built on the existing web/JS platform).

The asm.js work is informed by what Emscripten has been doing so far: it basically provides source-code level hints in JS that make JS look a whole lot like LLVM IR. For example, they will annotate variables that the compiler knows is a number with a '+'. By putting a "use asm" directive or something on top of that, JS VMs that know how to deal with the dialect can pretty much compile it down to native code directly instead of doing the whole JIT thing. This apparently is working in recent Firefox Nightly builds (the compiler stuff is known as OdinMonkey), and supposedly allows to run such JS at 2x native speeds.

Hope that helps. I'll answer more questions to the best of my knowledge.

I'm particularly excited by two big enabling technologies for DSLs:

1. Parallel JS. WebCL/WebGL/Rivertrail are giving different forms of data parallelism, with a bent towards visualization. However, they're fairly low-level, so programming by hand is hard. Libraries (e.g., ThreeJS), and I hope DSLs (such as my own :)) are exciting here. Looking further, I expect parallel DSLs for domains beyond visualization.

2. Sourcemaps and other dev tool protocols. These let DSLs and other JS-as-assembly systems reuse the browser runtime and debuggers in a legible way. Sourcemaps, for example, let's you step through the DSL using the browser's debugger, and errors in the generated javascript get automatically mapped into the source DSL.