Hacker News new | comments | show | ask | jobs | submit login

For folks that are curious, we wanted to get these changes out the door -- strict mode syntax errors being a big one -- so that source maps can be the focus of the next release (probably 1.4.0).



source maps can be the focus of the next release (probably 1.4.0)

Source maps in Firefox and Chrome will be one of the most important pieces of software infrastructure since Javascript itself. It will be the realization of Stallman's "one script to unite them all" vision for GNU GUILE from the "Tcl wars." A pity that it isn't Lisp, but there is enough goodness in Javascript (and Coffeescript) to make me very optimistic.


Regarding source maps... it feels like the solution to the wrong problem. Why are we still pushing minified/obfuscated Javascript to the browser anyway? What's wrong with standardizing on a bytecode format instead (e.g. JVM)?


That's a bit like asking why I work out instead of snapping my fingers and turning into a Greek demigod. One is clearly preferable on its own merits — but it's just not going to happen any time soon.

Source maps are relatively easy: There's a public standard, a couple of browser makers have agreed to it, and it doesn't need universal acceptance since it's only for development. Basically, it doesn't require a lot of coordination.

A universal bytecode is almost the exact opposite — easy to describe in the abstract, but a coordination nightmare. I've never heard an actionable plan for making it happen. Just getting the community to agree on a standard bytecode would be a Herculean task†, and then you have to get Apple, Google, Mozilla and Microsoft to all say, "Yes, I'm willing to chain my VM to this bytecode at significant engineering expense."

Basically, feel free to work on this if you want, but you can't expect everybody else to hold their breath until it happens.

You might think that "Herculean task" is an exaggeration, but just look at how much discussion and compromise was needed to get agreement on stabby function syntax for Harmony. And still people kvetched even once there was "agreement"!


With a common bytecode there would probably be a chance for languages to be fast and not stuck with translations to JavaScript for the next decade.


Citation extremely needed here. Bytecode isn't a magic speed potion — the implementation is what will determine how fast it runs. For example, V8 ROFLstomps over the JVM-based Rhino JavaScript implementation.

At any rate, any bytecode the JavaScript VM people agreed to would almost certainly correspond very closely to JavaScript, so it's not clear that a standard bytecode would make alternative languages much faster. On top of that, the optimizers in current JavaScript implementations are highly tuned for JavaScript, so a bytecode-compiled program running on V8 might actually be slower than the JavaScript we have today.

Basically, without an implementation, this all sounds like pie-in-the-sky talk to me.


I'll never understand the bytecode zealots and their insistence that browser makers scrap the years of JavaScript optimization they've done and start from scratch on some new format that will likely take another 10 or 15 years to get right.

You have what you want. You don't have to right in JavaScript any more. There are dozens of alternatives, and there are only going to be more. Source maps means you'll never even have to look at JavaScript. Please be happy!


Why should that "scrap years of JavaScript optimization"? That doesn't make sense. (Completely ignoring the fact, that JavaScript is not fast and will never be.)

Source-to-source-translation _always_ sucked and that's known for a few decades already.


> Why should that "scrap years of JavaScript optimization"? That doesn't make sense.

The bytecode that browsers compile JavaScript to are incompatible with each other. They would either have to pick one (wouldn't happen) or design one together (wouldn't happen).

A designed by committee bytecode would also effectively eliminate browser vendors' ability to compete on speed.

> Source-to-source-translation _always_ sucked and that's known for a few decades already.

In what way? From what I read Gambit Scheme compiles to C that is as fast as hand-crafted C. I would assume that CoffeeScript is no slower than regular old JavaScript. So if not speed, how are these things sucking?


Furthermore, some engines don't even have bytecode or even an interpreter and directly generate machine code (V8).


This is in the works already with Google's PNaCl. I believe the bytecode format is based on LLVM IR.


AFAIK, PNaCl is heavily deemphasized in favor of vanilla NaCl.


JVM in the browser had wide adoption and plenty of resources behind it, and failed miserably. Why should we try it again ?


>Why is this cool? Because I can debug CoffeeScript in the browser! <insert Kool Aid man "OH YEAH!" here>

>But why is this REALLY COOL? Because I can potentially debug any language in the browser as long as it has a source map.


For folks that had no idea "source maps" was a meaningful term, http://css.dzone.com/articles/source-maps-coffeescript


I might actually get some fellow devs to start accepting CoffeeScript after my 6 months of hounding them.


Nice source map support will be huge.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: