It’s just data

Hobgoblin of Little Minds

Brendan Eich: So, you kids want CoffeeScript, do you?

I tried out CoffeeScript, and was impressed.  A clean and consistent syntax, optimized for modern use cases including string interpolation and event based programming, and one that generates human readable JavaScript.  Couple it with HAML and SASS, and the maintainability of web pages goes way up.

Apparently, Brendan has a thing against significant newlines, but has no problem with the word in having different meanings depending on whether or not its usage is surrounded by parenthesis or not.  My preference leans towards languages with a higher degree of internal consistency.

In regards to maintainability, for CSS specifically I’ve been working on this: [link]. In the examples directory you’ll find source .hcss files and expected .css files. All of these “tests” "pass", and should give you an idea of what it does.

I tried Sass and LessCSS but they didn’t do much for me because my main annoyance is the cognitive dissonance between the structure of HTML and CSS files. I’ve just finished porting a commercial project entirely to HCSS and it’s been awesome. I added an entire admin widget to it earlier today in a couple of hours, by writing the markup first and simply copying it over to the .hcss file and adding styles. It was a breeze.

HCSS lets you organize the CSS as an entire structure (starting with the html tag) and also separate chunks of nested tags. Both work ok. Personally I’ve been doing the latter as it feels a bit more flexible yet still chaos-preventing.

Posted by Jonas Galvez at

Web Standards links - 22 Nov 2010 to 28 Nov 2010

Could it be the future of the Web on the server side = HAML + SASS + CoffeeScript Formalize CSS rendering of Forms across browsers. Cross-domain Ajax with Cross-Origin Resource Sharing Second W3C Web and TV Workshop The Definitive Guide To Website...

Excerpt from karlCOW at

peterhoffmann: RT @karlpro: HTML+SASS+CoffeeScript = (future) WebDev stack?

peterhoffmann: RT @karlpro: HTML+SASS+CoffeeScript = (future) WebDev stack? [link]...

Excerpt from Twitter / peterhoffmann at

Sam, I’m saddened that my blog was misread here, but then some people thought it was all a joke.

1. I stated clearly why I think significant whitespace (not newlines, I never wrote anything like that, and indeed JS with Automatic Semicolon Insertion [ASI] depends on newlines being significant sometimes) is a problem on the web. People strip JS of horizontal whitespace, by hand (by accident) and using tools. You could argue that a CoffeeScript-aware minifier can do the right thing — of course it can, and anyway Coffee is usually compiled server-side — but the point is that JS has nothing like significant indentation and people expect this property to hold.

2. In the comments, interacting with David Flanagan, I came down in favor of parenthesization not changing the meaning of “in”, banning for (x in o) altogether in the hypothetical paren-free Harmony. So the meaning of “in” was never seriously in doubt, but I still think those who claim “in” must only ever test property name bound on object or prototype chain are being foolishly consistent.

3. I like CoffeeScript, it’s great. But we can’t wave a wand and turn JS into it, and we (and Jeremy) should not want to put it through the Ecma standards process. That would hurt both CoffeeScript and JS.

This leaves us with room for improvements to JS. Based on 1, I do not believe significant indentation instead of bracing to be a candidate improvement. Do you?


Posted by Brendan Eich at

not newlines, I never wrote anything like that,

???  Here’s what I was referring to:

(don’t try significant newlines on me — I’ve learned my lesson :-/)

banning for (x in o) altogether in the hypothetical paren-free Harmony

That clearly requires an opt in.

I like CoffeeScript, it’s great. But we can’t wave a wand and turn JS into it


should not want to put it through the Ecma standards process

That’s orthogonal to this discussion.

I do not believe significant indentation instead of bracing to be a candidate improvement.

For Harmony?  Definitely not.

My feeling (FWIW) is that JS needs to evolve in ways that don’t require an opt-in, and once that becomes impossible, much more radical proposals become possible.  Perhaps not significant white space, but string interpolation and a much more compact syntax for declaring functions might be possible.

Posted by Sam Ruby at

BrendanEich: @sayrer

BrendanEich: @sayrer [link]...

Excerpt from Twitter / BrendanEich at

(don’t try significant newlines on me — I’ve learned my lesson :-/)

Yet JS has significant newlines and I used ASI in the first paren-free example in the blog. I clearly meant that I was not going to add more newline significance, but the context and specifically this part:

Pythonic significant whitespace is too great a change, and bad for minified/crunched/mangled web scripts anyway. JS is a curly-brace language and it always will be.

are about significant whitespace, as in, indentation. Please respond to this.

That clearly requires an opt in.

Harmony requires opt-in.

That’s orthogonal to this discussion.

So? Is this discussion under some one-dimensional constraint? I feel like I’m debating via tweets! How about the big picture: what to do to lighten JS’s that-70’s-show C-based syntax?

My feeling (FWIW) is that JS needs to evolve in ways that don’t require an opt-in

Those ways can’t involve new syntax, so they can be done now via library code, or via new APIs such as Proxies, coming in Harmony.

On what ground does your feeling stand? It’s arbitrary to say “new semantics only, no new syntax” unless you think object detection is the only way to degrade gracefully. Yet that’s not true, because “no new syntax” is also ahistorical: JS has gained new syntax in every new ECMA edition, and faster in particular implementations and those that cloned the features (SpiderMonkey, Rhino, JSC, Opera’s Futhark, even V8).

So why can’t JS have new syntax?


Posted by Brendan Eich at

Please respond to this

“I never wrote anything like that” is clearly a false statement.

I have written enough in Python languages to realize that both Python’s approach is workable and good (and that non-Python programmers arguments against that design feature are invalid), and written enough in non-Python languages to realize that alternative approaches are also workable and good.  I believe that significant whitespace can work well in standalone scripts, even on the web.  I do believe that there is a problem with such in the following use cases: attribute values (e.g. onClick), URIs (e.g. bookmarklets), and templates (e.g. EJS).

In the specific case of CoffeeScript, I don’t believe that this choice is capricious or arbitrary.  Defining anonymous functions to be used only once is a common enough practice in JavaScript, particularly when using tools like JQuery or node.js, that special syntax for this construct is worthwhile.  And furthermore, significant whitespace contributes greatly to making the syntax chosen for CoffeeScript to work well for this use case.

Harmony requires opt-in

Just a personal view, but the short version is that I view that as unfortunate, and quite possibly something that will not survive the process.

Is this discussion under some one-dimensional constraint?

OK, I’ll expand.  I don’t believe that CoffeeScript — whether or not it goes through the ECMA process — is in any way going to hurt the web.  I don’t believe that to be true in any scenario.  I don’t believe it to be true if CoffeeScript turns out to be a niche language.  I don’t believe it to be true if it is positioned as a and goes through the full ECMA process.  I don’t believe it to be true if it is positioned as an equal alternative to Harmony.

what to do to lighten JS’s that-70’s-show C-based syntax

The long version is my feeling is that replacements to ES5 either needs to be evolutionary and not violate Ruby’s postulate, or revolutionary in a way that adds enough nice features to the point that most new programs are not valid ES5.

If the latter path is taken, optional parenthesis on function calls and allowing if and for statements to be written without any line noise characters is a big win.  I feel similarly about allowing if and for statements as modifiers and comprehensions.

So why can’t JS have new syntax?

I call Strawman.  There is plenty of new syntax in Harmony.  Meanwhile, for-in in ES5 is what it is.  None of the proposals to fix this short of a radical change appeal to me.

I merely said that I prefer internal consistency.  I also believe that if there is an opt-in, the change needs to be substantial.

Posted by Sam Ruby at

I hope this comment gets through, unlike my last two attempts.

Any inconsistencies on my side are of course mine, but since we’re both TC39 members, I’m still concerned about whether Sam and I are aligned on big-picture concerns. The good news (finally) is that I think we are; we seem to disagree only over degree not kind of syntactic change needed to justifiy opt-in versioning.

I’d love to standardize CoffeeScript if it were possible. I don’t think it is, and I doubt it would be good for Coffee in the bargain. We could certainly try, at some very high opportunity cost, to get TC39 and Jeremy to take this on. More on this in my blog.

Based on years of experience, I’ve been somewhat less ambitious in TC39: I want improvements to JS’s syntax as well as semantics, which means explicit version opt-in for protection from confusion on the part of both human readers and downrev browsers. This is the plan of record on the committee, in spite of Sam’s doubts about opt-in prevailing in the next edition.

I do not agree that only CoffeeScript is different-looking enough that it would be tolerably free of confusion when injected under opt-in versioning. Polyfills allow all sorts of JS dialects and completely unrelated languages to run in script elements, via DOM extraction and in-browser compilation and execution.

These alternate syntaxes won’t be standardized cross-browser quickly or ever, of course. And loading all scripts as text, then running them, hurts in several ways. But people can and do choose to do this, for good programmer productivity as well as less-good language chauvinism reasons.

My sole point in proposing paren-free (and only paren-free, in the case of for-in loop head) syntax is to improve the JS that is actually implemented cross-browser, with native code and JITs, with script tag prefetching, and all the other benefits that polyfill languages lack.

Why we can’t improve JS somewhat less than “radically” and void fatal confusion under opt-in versioning is not clear to me, but the productivity costs of leaving JS syntax more or less alone, thereby pushing anyone who feels these costs are too high toward polyfill language front ends and/or server-side translators, are crystal clear. I think these costs are too high in the long run not to try improving JS’s syntax, and in ways TC39 members can swallow.

The “no more significant newlines” stance I took somewhere in my paren-free post was narrowly about if-then (and while, same deal) statements, which I argued need something explicit separating the if condition from an expression statement as the “then” clause.

Sam (private correspondence) kindly pointed out [link] the rationale for Python’s mandatory significant-colon instead of just a significant newline. That FAQ entry cites summary experience with Python’s progenitor, ABC, which apparently did what CoffeeScript does by using only a significant newline, no colon, against the idea of doing without a non-space separator.

This is kind of a tempest in a teapot, and anyway I stick to my guns in wanting bracing or a keyword between if-conditions and then-expressions. I don’t think I’m being inconsistent on this minor point.

The big-picture tradeoff between indentation based block structure and bracing is a much better, harder trade to debate. I believe we can’t get that change through TC39, especially implementors, and I would bet real money JS hackers and tooling, which freely delete horizontal space characters, would bounce off such a change, hard. I could be wrong about that, though.

Indentation-based block structure is easy on eyes and hands/wrists, for sure.


Posted by Brendan Eich at

Hey — this conversation just picked up in a big way. To mix metaphors and throw my two cents into the ring...

CoffeeScript isn’t an appropriate JavaScript-Next candidate, because it doesn’t go far enough: it’s entirely limited to what’s possible to achieve on lowest-common-denominator JS engines. Which, in practice, means that it’s limited to all the quirks and bugs of JScript in IE6. For example, negative array indices. It would be awfully nice if array[-1] was the last element in the list, but JS semantics won’t allow it. Only a language that makes a complete break would be able to do such a thing.

In my opinion, the true next-web-language should be built from scratch, without any of the cruft that’s accreted around JavaScript over the years. It should be worked on in parallel to the next version of JavaScript, and the next version of JavaScript should be a fully backwards-compatible, opt-in syntax, a-la Harmony.

And in the meantime, browsers could easily start supporting more compile-to-JS languages by providing some simple facilities, the first of which would be the ability to map line numbers to line numbers in generated JavaScript, either through a big JSON map, or with magic trailing comments. That’s about all that’s needed to have solid alternate language debugging in the Chrome inspector, or Firebug. I’d much rather have that sort of pragmatic support than an attempt at standardization. Little languages should be given a chance to prove their viability first, without needing to wait for the slow grind of browser evolution to catch up.

Posted by Jeremy Ashkenas at

Jeremy: thanks for the good idea on source coordinate mapping, I’ve filed it at to get a post-Firefox4 prototype started.

That bug alludes to an old hack we implemented, after CPP’s #line:

//@line number “filename”

with the right SpiderMonkey embedding option makes the next line be attributed to filename:number. It was meant for pre-processed XUL, where such magic comments would be rare. Your idea should avoid having too many such noise comments, and instead encode the total mapping efficiently in the JSON.

I agree we can’t and shouldn’t try to make CoffeeScript a JS-next. This leaves two big problems, I’m interested in solutions to both:

1. How much does JS become more usable over time, out of the box? After resisting ideas like paren-free syntax and even negative indexes, I’ve started casting a colder eye at the confusion and incompatibility objections. I’m just getting started, and it may be that in the end, we can do little other than add rather than revise. But (see 2) usability is a global and long term optimization problem, and being locally and short-term conservative may simply stagnate JS without relief.

2. What’s the “Netscape 2” analogue, the vector by which a non-committee-designed true next-web-language could spread to all browsers? It won’t be via a plugin. It could be a polyfill with enough support for performance and development. The debugging support is only part of the story. Better hooks into script tag handling, including speculative script fetching and execution, seem important.

Maybe something else will happen to shake things up, but both of these suggest short-term experiments. I may file some more bugs.


Posted by Brendan Eich at

Thanks for the Bugzilla ticket.

This doesn’t need to be an either-or question. Of course JS should continue to evolve in ways that don’t require an opt-in, and of course JS isn’t going to be the language of the web forever. I’m not party to TC39 committee discussions, but I would imagine y’all are well aware of that fact: the web is going to be around for a long time, and at some point in the future, there will be a viable alternative to JavaScript. I think you can plan for both, and works towards both at once. The vector by which a new language can spread to all browsers is the browser-makers recognizing this fact, and welcoming the possibility of a new language that better suits modern web development. Polyfills can only ever get us partway there.

So by all means, evolve JavaScript, provide hooks to make source-to-JS languages more viable, and at the same time start planning for what the next web language might be.

Posted by Jeremy Ashkenas at

Sam Ruby, Brendan Eich, and Jeremy Ashkenas on CoffeeScript and "JS-next"


Excerpt from oursignal's feed at

I believe that a new feature in javascript should be the support for continuation style like fibers in ruby. This for avoid spaghetti code when nesting more than 5 or 6 function for make async call.

Posted by sasuke at

Javascript: Un interessante dibattito

Sul sito di Sam Ruby ho trovato un interessante post su javascript e coffeescript con uno scambio di commenti tra Sam Ruby, Brendan Eich e Jeremy Ashkenas....

Excerpt from Il Metaprogrammatore at

My thoughts match Jeremy’s.

In my mind there is a big difference between new syntax which is totally optional and won’t work with older clients, and a hard break in which there is no way to express common concepts in a way that works with both older and newer clients.  I don’t have a crystal ball, but my intuition is that what will ultimately win the day as a viable direct successor to ES5 is a path that allows virtually all of the old stuff to work and adds attractive new stuff.

It is worth noting that C++ started life as a preprocessor.  Nowadays C++ compilers don’t tend to produce an intermediate C, and to this day, many people use C++ merely as a “better C”, i.e. one that allows declarations to be placed at first usage and with a line comment.  Furthermore, I note that some of the improvements that came with C++ (like the aforementioned comment syntax) has migrated back to many C implementations.

Posted by Sam Ruby at

Jeremy: the condition in TC39 that I named “Harmony” ( is delicate. Changing JS (revising existing syntax and semantics) under opt-in seems hard — even opt-in is questioned (here, by Sam, but he’s not the only one to do so).

Adding to the language is not so hard, but then you get a strictly bigger language, with conservative additions that don’t hang together well. TC39 makes mistakes too, so as these additions creep in over the years, some of them walk along a dependent path toward a bad place, and we can’t back up.

Ideally there’s no either/or regarding improving JS vs. a new language. Yet in practice, the question I keep facing is whether there’s much we can do beyond adding a few things (e.g. generators — not fibers or full coroutines, those won’t fly among all the vendors) that we’ve implemented and shipped in Firefox for over four years. I intend to keep working on this front, but it is taking its toll.

Could TC39 recognize the best new language and standardize it? I think not if it’s significantly different in runtime semantics from JS. So your “do both” suggestion is good, if it is possible: evolve JS while tracking up-and-coming languages, and try to align JS as it evolves with the best-of.

Yet we already have disharmony over whether to evolve JS in anything less than a radical re-do, which would (my gut says) fail in the TC39 consensus-based process if we try it all at once and prematurely, and with big opportunity costs.

Which brings me back to Sam’s argument that opt-in should not make meaning shifts for given syntax. It’s a fair point, which ES5 strict mode goes against, ditto a lexical-scope-only Harmony.

So I don’t think we should prohibit such meaning shifts, but I agree we can get away with only one or two. That’s why (in [link] — I think this is what Sam missed in writing this post) I clarified what the paren-free mode of Narcissus does: no for (x in o) at all. Not a meaning shift, an obsoleting of old syntax.

Can that fly? I have no idea, but it would reduce confusion.

Opt-in could enable:

(a) removing old forms (ES5 “use strict” removes “with” statements)
(b) adding new forms (JSON in ES5, “let” or modules in Harmony)
(c) existing form meaning shifts (arguments in ES5 strict, lexical-only scope in Harmony)

I hope a mix of (a) and (b) are possible, and paren-free fits in that combination. (c) is risky and ideally we would avoid it, but we want to eat just one more cookie (lexical scope only) and then quit.

I hope this helps. Does it?


Posted by Brendan Eich at

Sam Ruby, Brendan Eich, and Jeremy Ashkenas on CoffeeScript and “JS-next”

Comments View full post on Hacker News...

Excerpt from Techarama at

Certainly it helps, and I think we’re all in general agreement here. The biggest question isn’t “what is desirable?”, but “what is possible?”, “what is likely to be accepted by browser vendors?”, and “what is likely to be embraced by the larger JavaScript community?”. So, while I’m sorry to hear that the struggle is taking its toll on you, I’m afraid you have to continue to fight the good fight. JavaScript is too important for anything less.

It sounds like it would be helpful for the Harmony effort to start categorizing proposed changes to JS into the categories we’ve teased out above:

The first category can be added immediately when TC39 agrees on the addition, the second category can be added when TC39 agrees on a scheme for opting-in to the new version of JS, and the third category can be (very unlikely) added when TC39 agrees to allow second language in to the browser, however closely related to JavaScript it happens to be.

Finally, TC39 might not be able to pick a JS-Next, but the web certainly is. TC39 might not be able to design a JS-next by consensus, but you aren’t going to find one unless you ask for it. Better browser support for compile-to-JS languages is the first step in enabling the experimentation that will demonstrate which new ideas will work well on the web. Let a thousand little languages bloom, before picking your bouquet.

Posted by Jeremy Ashkenas at

Hopefully this isn’t too tangent. I really feel that rather than planning the next js in parallel, if that is the direction and if it is an entirely new development, that a byte code would be a million times more useful to developers. I suppose the added cost there is the possible undoing of many optimizations in the current js engines. Would that also be true of an entirely new languange? There may be a bunch of things to that that I am not realizing.

Posted by adunn at

I sometimes think that the we look to far forward in designing things that we ignore what we already have sitting around us. What’s stopping us from taking more established languages and doing the research of embedding those? Lua itself seems like a close fit. Others might be more appropriately hosted in something like NaCL but even then, there is little reason to wait for a new language. JS backends for languages are just obscure examples of this. What we learn from that effort might make it clearer to people on what new languages might need and people like Jeremy Ashkenas can lead those efforts. Let’s embrace type="text/polyglot"!

Posted by Brian Mitchell at

The toll is not just on me. Everyone in TC39 feels it.

Imagine putting a Python or CoffeeScript language through a years-long committee process, without the rapid prototyping and iteration afforded by things like PEPs or open source development.

I’m questing for a better way to advance JS that still results in standards every few years that browser vendors actually implement. Putting ECMA-262 Edition 5 on github and letting it be forked is not the right approach, since the spec is sufficiently hair, yet not machine-checked, that it would be hard to hack and even harder to use.

Narcissus is an easier playground in which to hack. Forks welcome. It is a bit poky, though. It needs a compiler as well as an interpreter; I may work on this over the holiday break.

The categories you list do help and we’ve used them before, but they are not as crisp as you might think. Even could break code that didn’t object-detect carefully, or that depended on quirks of a self-hosted map that preceded the ES5 one. We definitely broke some sites that added their own JSON object to the global scope, without parse and stringify methods, and then detected only “JSON” in global before assuming it was their JSON object and not the ES5 one. The sites changed their content soon enough, since they were just object-detecting incorrectly, but there’s always risk of a quirk becoming a de-facto standard.

I don’t agree that changing JS in Harmony to have lexical-only scope makes for a “second language” from JS. Is ES5-strict a second language because it makes creating global variables by assignment a runtime error?

Probably it is not worth trying to pin down exactly what kind and amount of changes make two, not one plus a fraction, languages. I agree the fraction has to be pretty small.

The benefit of lexical-only scope looks to TC39 to be big enough that it’s worth attempting, under the opt-in that is already required for your second category (new syntax). If we have to back off, we will. Harmony will be prototyped and user-tested before any standard is finalized.

I hope it’s clear that I do agree on the web being a better filter than TC39 for any JS-next, but unless browser vendors change standards body and process, it’ll still fall on TC39 to pick, if not simply to ratify, the de-facto winner. There may not be one clear winner. That’d be ok too if we add enough support for performance and debugging of JS-hosted languages.


Posted by Brendan Eich at

[from chl] sam ruby: hobgoblin of little minds


Excerpt from Delicious/network/earl at

Brian: As far as I can see, NaCl is never going to get into Microsoft or Apple browsers. We’re not eager to add it to Firefox because it’s useless without Pepper2, which is a pile of APIs that are currently too chromium-specific and in part duplicative of similar APIs in Gecko. We also question the benefits of native code for the web, vs. the costs — Mozilla does not agree with Google on this trade-off.

This is just one example of the trouble ahead in trying to add more languages to browsers. Imagine C-Python and the native parts of the Python standard library that aren’t already OS-specific and simply wrong for the web. We’ve had C-Python XPCOM bindings in Firefox for years, and now WebKit has Python bindings, but these are not web-ready. Beyond security fixing, the JS and Python heaps are disjoint, so connecting objects across them without a cycle collector makes a leak.

That’s not the end of it, either. To avoid N^2 language bridging explosion, we’d need a cross-browser language bridge akin to Mozilla’s XPConnect or js-ctypes. That would be a multi-year piece of work even to begin to standardize.

Multi-language runtimes exist but they’re costly and inevitably biased toward their “lead language”. Only Java and the CLR have endured, with big corporate backers, and their implementations still aren’t interoperable enough, fast-and-small enough, and unencumbered enough to get into successful browsers.

Beyond all the lower-level technical challenges, which any one browser project could take on and conquer in a five year mission (which might easily be canceled after season 3), you’d have to get all the browsers to agree on the canonical runtimes, the security model, and the upgrade model.

NaCl would indeed be easier, since you’d have only one compiler and runtime, even though big and complex.

But again, the odds of Microsoft and Apple adopting NaCl are close to zero.


Posted by Brendan Eich at

Sam Ruby, Brendan Eich, and Jeremy Ashkenas on CoffeeScript and "JS-next"


Excerpt from illmatix's feed at

Brendan: I don’t know the specifics of NaCL’s API but that does make sense. On the other hand I think it’s not a question of native code as much as it is a question of virtual machines vs. languages (just considering the LLVM backend). I do think that steps need to be taken that allow more than just the browser vendors to try ideas. If I need to download the mercurial repo mozilla uses, so be it, but it needs to be first class.

I also don’t imagine languages being added in without modification (i.e. Lua is embeddable but one wouldn’t include certain dangerous modules). CPython would also need to be trimmed to a DOM-friendly set of libraries. The DOM interface does have the problem of not fitting into all languages very well but it is simple enough that I think it would still be possible to bridge these and wrap them up in a similar way that most people code with jQuery vs. the DOM. Regardless, most of the modification would for suitable languages (which there are many) would involve dropping libraries and adding one or two very small libraries.

On the argument of available libraries, it’s true that much would have to be crafted still. This is true in the case of a new language too so I don’t see it as an exclusive problem to allowing people to experiment and support existing languages.

In my mind, there would be no language bridging other than through interfaces provided by the browser. Things like DOM events or API’s like web workers. If more are needed they could be added. Passing references is messy and is easily the cause of many security holes in design. Simple message passing is clearer and has proven to make systems more resilient to failures. It also means I could easily replace parts of a system with alternatives if a browser couldn’t support a module I passed in written in language X.

While that leaves questions open to how big porting some languages might be, I haven’t seen it approach the complexity of either a young and immature language being deployed at web scale (see early JScript problems) or moving a committee to evolve a ubiquitous standard at a reasonable rate (I am sure TC39 has it’s share of non-trivial challenges which can’t be concluded quickly).

Posted by Brian Mitchell at

Brian: bridging through interfaces provided by the browser means cycles across the heaps. A DOM node can have ad-hoc properties added to it; event listeners can be added to event targets. These need to be reflected across the language bridge, or else isolated fully (but then you’ll get nonsense states where JS handles an event and Lua can detect indirectly that there’s a listener, yet not access it).

It’s fine to praise simple message passing, but the interfaces provided by the browser today, especially the DOM, don’t work that way.

Ok, let’s ignore the cycle collection problem or assume it can be solved.

You seem to be minimizing the costs to all browser vendors of figuring out security for all these language runtimes, agreeing on the version(s) to support for interoperation, and upgrading them. This is a huge problem. It truly is a multi-year mission. The coordination costs are high too. Right now, most browser vendors don’t have the resources to sink this cost, and any that might, either lack market power to cause others to follow (Google; and Google is working on the NaCl route instead), or are in a bad position to force the issue (Microsoft, both for open source patent fears and legitimate regulatory concerns; also, Microsoft is not upgrading IE6-8 users on Windows XP, so their market power is limited due to their own internal porting economics).

That’s another thing: not only Microsoft, but also Opera and possibly other browsers will not ship implementations derived from open source. They’d have to clean-room a workalike.

It won’t do to say “web developers can choose what users happen to have installed.” That costs both devs and users and it’s essentially plugin hell, which already failed with a great narrowing to Flash (and now Flash is undergoing both HTML5/CSS/JS disruption and shunning by Apple).

Ignoring browsers that can’t take open-source language runtimes, there are all the integration, factoring, security fix, memory management, etc., patches that must flow back to the various open source language implementations, with good cross-browser coordination and release timing.

The cost of a multi-language-runtime in all browsers with coherent security, DOM and other shared-mutable interface support, and cycle collection is stupendous. It is much bigger than HTML5 (given HTML-reality on all moden browsers) or another JS version.

Even if it were economic for all the major browser vendors to undertake the effort, the follow-on costs of standardizing the languages so web developers could count on interop look terribly high — both for the standards body and browser vendors, and for the languages themselves. Do Lua, C-Python, etc. really want to be frozen in browser-amber every few years?

If you think you can solve that problem, you’re asking for even more free money. I don’t see how this can be pulled off among Microsoft, Mozilla, Google, and Apple — even ignoring Opera and others on mobile. And do consider mobile. Internet-enabled mobile is about to cross (or already has crossed) the line with respect to desktop internet PCs. C-Python, Lua, Ruby, etc. in addition to JS on relatively memory- and cycle-poor smartphones is an even taller order.


Posted by Brendan Eich at

Brendan: You’ve just painted a pretty compelling picture of the reasons why we won’t be seeing a multi-language browser soon, and, I think, the best answer I’ve ever read to the “Why don’t we have <script type="text/python"> in the browser yet?” question...

It’s all the more reason to start attempting to support compiled-to-JS languages in a serious way. If we’re limited to polyfills and opt-ins for the foreseeable future, little languages on top of JavaScript are going to be some of the best nurseries for those ideas and their possible implementations.

Posted by Jeremy Ashkenas at

Jeremy: of course I agree and we’re working on being a better compiler target, and your point about source coordinate mapping earlier here (thanks again for provoking me to file a bug; it has been a while since we did //@line) shows there is more to do than just add target “instructions” to be better as “the x86 of the web”.

We have to draw lines for (obviously) memory safety and (more subtly, since it is a compromise among vendors) interoperable implementability. For instance, some compiler-writers (see the hacker news thread on this blog post) want full continuations, but those break native vs. self-hosted functional abstraction if the VM can’t capture across native activations. You can bet that some VMs won’t, others will. Single-frame continuations (generators) are therefore the most we’re planning on.

Being a good compiler target won’t be an exclusive focus or overriding priority for us in TC39, however. JS is widely handcoded still, and probably will be for a long while, even with good compilers targeting it, better debuggers for those polyfills, etc. Between wanting better usability and facing demands from large-scale apps for modules, lexical scope, proxies, etc., we have to work on JS as a more usable source language too.


Posted by Brendan Eich at

Brendan: Thanks for the well written points. I guess we won’t likely ever see a page use multiple languages but does that single language really have to be JavaScript?

I’m not sure I agree that security is a bigger issue that it is right now. Most of those issues being solved are about intentional operation of APIs and largely exposed as limitations in what function calls in JS can affect. Of course, I’m assuming that most languages would have their standard libraries removed save for pure code. Privilege escalation can happen with unintentional bugs too but I think that has more to do with code line count than number of languages. Maybe I’m missing the point there but it’s not going to be easy to manage security either way and I see things like HTML 5 extensions causing a much bigger burden here than languages.

The DOM might cause problems with interoperation if translation is literal and references are used directly. Still, the DOM api is a lot closer to creating a strict bridge than other efforts like Appcelerator’s Kroll. Mostly because at that point the integration points are known and enumerable. Heap cycling is a problem but I think that’s more of an assumption that a majority of uses would have large numbers of cases where two languages would be used to implement the same parts of a page. The reason I mention message passing is that it’s pretty easy to build isolated components in the DOM that operate on the DOM API alone and only communicate with other code through serialized messages (usually delivered because of event handlers). Now, I will admit I don’t like the DOM API but I’m not here to reinvent that either. If it were in favor of supporting other languages, I could see a refined subset of the DOM exposed rather than full spec compliance.

As far as other vendors needing to derive their own implementations for everything, that’s a fine argument if you care to make them the committee driving this, but I don’t think vendors like that will have much of an option if something good comes along that people develop for (see how even unfinished HTML 5 spec components are being used/implemented). That was their choice and their cost to pay (or the committee’s), not mine.

What I see it coming down to in this argument is maintenance cost and possibly initial development cost if you go to support everything under the sun. If the cost falls on the browser vendor, I can see why we’ll likely never see any real move made. However, if something like this becomes easier to prototype, maybe someday we’ll see obvious options that prove to be cost effective improvements to the ecosystem. I guess I’ll have to try to compile the mozilla repo again (autotools kept breaking me last time) or maybe look at webkit some more. I hope that developers can become a valuable part of the prototype ecosystem.

Posted by Brian Mitchell at

Brian: your last paragraph hits on the way to get other languages supported in browsers: crowdsource, lower development and (critical!) distribution costs, get browser vendors out of the loop.

This means using JS as the target language — and compiler host language too, to relieve authors of server-side translation at least during development.

Such browser-based JS-hosted compiler/runtime combos are a subset of the technique nicknamed “polyfill” aka regressive enhancement. Winning language polyfills could prefigure eventual standardization and native cross-browser support.

It’s happening, and not just with CoffeeScript. Another example: Python in the browser via Skulpt [link].


Posted by Brendan Eich at

What we really need in the browser is a fast, targetable “language” — opcodes or whatever — for compiler-writers.

Javascript is an awkward assembly language, but that’s increasingly how a lot of people are using it (Objective-J, Volta, GWT, etc.).

If we had that, then all this discussion around Python or Coffeescript or COBOL or let vs. (in) vs. newlines or whatever would be moot.

Posted by Michael Brundage at

Michael: what we really need is a Pony. If we had one, a lot of things would be moot. Seriously, it’s not at all clear that opcodes ("or whatever") are the answer.

Flash has opcodes, also versionitis and too few compilers that get more than niche use compared to Adobe’s tools. Java failed in the browser. The CLR is not going to make it cross-browser for several big reasons.

Opcodes require verification. They over-lower to an abstract machine that (over time) is a mismatch for both source languages and physical machines. Add inevitable mistakes in the opcode design and you get versionitis or stagnation.

Not much different from JS, but at the cost of verification and over-lowering, not to mention just having to run an ahead-of-time compiler before pressing reload.

Machine integer types would be a win, and JS suffers from lack of them outside of the bitwise operators' implicit conversions. This is being rectified: [link].

As for “fast”, JS is more optimized now than almost all other dynamic languages (Mike Pall’s LuaJIT2 is the touted counterexample, but fresh re-benchmarking is needed). For this to be a productive exchange, it would help if you threw up some numbers (either what you want, or what you’ve achieved and found too slow). See [link] for a simple emulator trace-compiler in JS.

I’m a realist. There’s not going to be some “opcodes or whatever” in browsers any time soon that web developers can rely on, apart from plugins (and plugins are in decline by any measure). Meanwhile, beefing up JS as compiler target and source language is on browser vendors' agendas, in the market and in Ecma TC39.

Like the sterile dinosaurs in “Jurassic Park” who evolve fertility, JS has a chance. Nature will find a way, given a healthy ecosystem. ;-)


Posted by Brendan Eich at

This Hacker News thread on bytecode in browsers / stuck with JS and no Pony might be of interest: [link]


Posted by Brendan Eich at


[link] [link] [link] [link]...

Excerpt from 〈 SL 〉 at

jashkenas on CoffeeScript hits 1.0 -- Happy Holidays, Proggit.

Yep, this is certainly the single most bothersome thing about dealing with CoffeeScript in the browser at this point — and it’s why we try to keep the compiled JS as readable as possible. Fortunately, it looks like browsers are going to start...

Excerpt from programming at

Happy birthday, CoffeeScript

CoffeeScript is a great language, but more than that, it’s an invitation to think and dream about our ideal developer experience. And then to make that dream into a reality....

Excerpt from stdout » en at

Sam Ruby: Hobgoblin of Little Minds

RT @karlpro: HTML+SASS+CoffeeScript = (future) WebDev stack? [link]...

Excerpt from Peter Hoffmann's Bookmarks at

Agrémentez votre JavaScript avec CoffeeScript 1.0

CoffeeScript est un langage qui se compile en JavaScript ( licence MIT ). Il vise à proposer une syntaxe alternative, plus agréable, au JavaScript, mais reste très proche de celui-ci au niveau de la sémantique. Par exemple, le code coffee suivant :...

Excerpt from DLFP - Dépêches de page principale at

jashkenas auf CoffeeScript hits 1.0 -- Happy Holidays, Proggit.

Yep, this is certainly the single most bothersome thing about dealing with CoffeeScript in the browser at this point — and it’s why we try to keep the compiled JS as readable as possible. Fortunately, it looks like browsers are going to start...

Excerpt from programming at

Web Standards Links - 6 December to 12 December 2010

WebSoket WebSocket disabled in Firefox 4 Disabling the WebSocket protocol in Opera WebSockets in the tempest zone for security issues Is Chrome 4 the next IE 6? WebSockets, we are the first HTTP Amazon proves that REST doesn’t matter for Cloud APIs...

Excerpt from karlCOW at

Happy birthday, CoffeeScript

Yesterday, Jeremy Ashkenas gave all of us a little Christmas present and released CoffeeScript 1.0 , precisely one year after its first release, 0.1. CoffeeScript is a language inspired on Python and Ruby, which compiles into Javascript. Yes,...

Excerpt from | thoughts about journalism and technology at

Javascript line number mapping

Magically formatted comments will change the reported line number of javascript errors in some browsers; They look like this: //@line n “f” n is the line number and f is the file name. Unfortunately, //@line appears to be ungoogleable. Does anyone...

Excerpt from Javascript line number mapping - Stack Overflow at

__andy__ on Coffeescript in the browser comes a step closer

I was sceptical after seeing the title of this submission. CoffeeScript? Really? But actually the bug report doesn’t mention it at all, it’s about mapping line numbers of generated JavaScript back to the original source (which yes, could be...

Excerpt from JavaScript at

Add your comment