## JS

I am not up to it at the moment, but how about someone summarize the developments in the Javascript world (lljs, asm.js etc.) for those not following that world too closely? Thanks.

## Comment viewing options

### AltJS

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

### naive questions, hoping to spur basic commentary

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?

### Does JS make sense without a

Does JS make sense without a DOM? Or is a DOM always present even in a server side deployment?

I think the popularity of Node.js shows that JS without a DOM still makes sense. It's still web programming though; I'm not sure JS is that interesting as a language on its own, though, so I would guess that that keeps it confined to developers who already have to know it to be able to develop code that runs in the browser.

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?

As I understand it, JS assumes a top-level object. In the browser, this is the "window" object. Then, all unqualified variable names that aren't defined in the local scope are looked up on that top-level object. So outside the browser, I think you'd just have a leaner top-level object, containing only as much as you need.

### These days Web browsers are

These days Web browsers are usually made out of three components: a JS platform, a 'Web engine' (HTML/CSS parsers, layout algorithms, etc.) and the 'chrome' (UI, configuration, OS integration, etc.). These parts are pretty-much self-contained and interchangable, which makes the JS platform usable without the rest of the browser.

Some common JS platforms are V8, *Monkey (* is a wildcard) and Rhino. Their non-browser uses are:

Shells:
These serve a similar purpose to other shells like Python's, ie. bash-with-less-crazy-syntax. They generally come with file and console IO. They're very bare-bones (no DOM, no real module/library mechanism, etc.). I've played with them for writing self-contained libraries, for example http://gitorious.org/search-optimisation-streams

Servers:
node.js is the classic one here. It only cares about V8, so there's no cross-(JS-)platform gotchas. It uses various bits of CommonJS ( http://www.commonjs.org ) eg. its module system. The point of frameworks like node.js is to be asynchronous and event-driven, rather than main-loop driven.

Testing:
Testing server-side code is easy, but JS-heavy sites need to test their Javascript. Tools like Selenium will automate an entire browser, but something else is needed for unit testing. This is one of the main use-cases for Rhino; it runs on the JVM, so many organisations can plug it into their existing testing infrastructure.

Scripting:
Many desktop apps and games are using JS as a scripting language. One example is the Gnome Shell. GNU Guile has/had some JS compatibility too.

The general rule seems to be that Web companies (especially startups) don't like having to integrate multiple languages. Javascript is a necessity for client-side code, so why not use it on the server too? If you've got it on the server and client, why not use it for your console scripts? It may not be the best tool for the job, but at least everyone can understand each others' code (in theory).

### I'll attempt to name some projects

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.

### Also firmly in the

Also firmly in the replacing camp is Google's Dart. I haven't looked much at it since I don't think it's interesting to me as a language (and it's been widely derided by people I trust). 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).

I'm on the Dart team, so I can provide some more detail here.

1. Despite that abysmal leaked memo, I don't think anyone on the team seriously thinks it will replace JavaScript. Dart just intends to provide an alternative. Reasonable people may still prefer JavaScript and both can and should coexist.
2. I'm not sure what your definition of "lower level" is, but JS seems lower-level than Dart to me. Dart has optional static types, but those are layered on top of dynamic runtime behavior, so it's still as high-level as JS operationally. Its notation for defining types, methods, and functions is declarative instead of imperative, which to me means higher-level.

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

TypeScript's scope is quite different from Dart's. It's an extension of JS where Dart isn't. This makes adoption much easier, but also significantly narrows their scope. For example, TypeScript has no runtime library which means things like better collection types or DOM APIs are out of their scope. I'm not saying one approach is better than the other, but the two languages are not that similar outside of their type systems and target platform.

I'm curious as to why you like TypeScript more than Dart. The impression I get here is that your main data point is that they have similar type systems. Since the type system is what was widely derided about Dart here, what makes TypeScript better?

### Not an expert

By "replacing JavaScript", I mean, not run on top of JS. That is, if the native/preferred way of running Dart is to run it on its own (Chrome-specific) VM, then it's less about extending JS/transpiling to JS and more about a separate ecosystem.

I don't have a very informed opinion on Dart and TypeScript, as I tried to convey in my previous post. I was merely echoing commentary I've read from sources I respect, some of it on Twitter, and as such not very nuanced.

Also note that I'm following along mostly as a interested web technology observer, but also one who very much dislikes JavaScript itself. To my (Python-informed) eye, the "standard library" is woefully underdeveloped (though getting better with ES6) and weak typing is an absolute disaster to work with (also informed by many years of PHP experience).

So, I don't actually have a very informed opinion on Dart vs TypeScript, I'm just summarizing opinions that I've picked up. I've weakend some of the strong language in my previous post, I shouldn't have editorialized as much.

### Depends on who you ask

That is, if the native/preferred way of running Dart is to run it on its own (Chrome-specific) VM, then it's less about extending JS/transpiling to JS and more about a separate ecosystem.

A bunch of people on the Dart team are VM hackers, so in their heart of hearts, the VM is where it's at. Most of us, though, think transpiling to JS is equally if not more important. What matters is letting people write Dart apps that are widely accessible to as many users and platforms as possible. From the user's perspective, dart2js and the VM are just implementation details.

### New DSL opportunities

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.