8 ms·

JavaScript is Not Web Assembly

178 points by niggler 14y ago

simonsarris 14y ago
I fear that this is one of those "I've heard someone make a metaphor and taken it too literally, then rebutted that literalism broadly." I imagine 99% of the time that metaphor is made the author would be just as happy saying "JS is the new C", it simply doesn't roll off the tongue as well.
- Helianthus 14y ago
  It's not, in fact; it's a good extension and modification of the metaphor. Not that the original metaphor is wrong or useless; but thinking of javascript as C provides some glimpse into the risks of what made C++ problematic. The author picks Coffeescript as an example of a fairly sensible approach to the problem, but "the language-wank crazy" are taking a lot of risky approaches.
  - deleted 14y ago
    [deleted]
- Cushman 14y ago
  I agree with the first part, disagree with the second. "JavaScript is assembly" is, in my estimation, usually a rather blase metaphor for the idea of JavaScript as a compile target. People don't say "JavaScript is the new C" because generally you don't target C. (Generally you don't target assembly, either, but the distinction between assembly and machine code is academic to most people.) And it's no surprise that we're getting lost in this; making arguments based on metaphors rather than the thing itself is a classic trap. We should make an effort where possible to talk about what JavaScript is rather than what it "is".
  - scott_s 14y ago
    I guess it depends on how general you mean "generally" to be, but there is a history of people targeting C for new and experimental languages. It's a convenient target because we have a good idea of what kind of assembly will be created for a given chunk of C, and you can get architecture independence for free.
    - Cushman 14y ago
      > and you can get architecture independence for free And you target JavaScript for precisely the same reason :) Perhaps the better way to say it is this: C is a language which was once written by hand, but which is increasingly being used as a target for higher-level languages. The same thing is happening to JS, but at least to me "JavaScript is the new C" is not a particularly useful way to express that similarity.
  - vidarh 14y ago
    > because generally you don't target C. (Generally you don't target assembly, either, but the distinction between assembly and machine code is academic to most people.) You're excluding a large chunk of compilers with those two generalizations. Targeting assembly rather than directly emitting machine code is extremely common (gcc being one of the obvious examples), and targeting C is very common for new/experimental languages.
    - Cushman 14y ago
      All I'm trying to say is that "a target for higher-level languages" is not a defining attribute of C in a way that makes "JavaScript is the new C" a helpful analogy.
  - deleted 14y ago
    [deleted]
  - fauigerzigerk 14y ago
    "making arguments based on metaphors rather than the thing itself is a classic trap" Well, yes and no. I do agree that it often goes completely wrong and can be very misleading. But the JavaScript/assembly argument is more an analogy than it is a metaphor, and analogies are a very important function of intelligence and a tool for making important discoveries. That said, I like your generalization "compile target" a lot more than calling JavaScript assembly.
  - epsylon 14y ago
    There are a lot of compilers that target directly C.
- deleted 14y ago
  [deleted]
- amirouche 14y ago
  This can help https://news.ycombinator.com/item?id=4630057 https://news.ycombinator.com/item?id=4630057 «JS is the web's “virtual machine”» Brendan Eich
- fkdjs 14y ago
  You really shouldn't try to use metaphors when making an argument. Someone says A is like B, another person disagrees that A is like C. But no, says another, A is like D. Finally, an internet troll points out A is like B and D, but definitely not like C. By then, everyone's brain gives up trying to figure it all out. If you're gonna make a point, make a point, it's that simple.
  - biot 14y ago
    Are you arguing that metaphors have no value when explaining a concept? I'm sure Shakespeare would be a whole lot more boring without the use of metaphor: To be, or not to be: one could ponder: Whether one's sense of self-worth increases In direct proportion to one's ability to accept adversity, Or to address challenges, And in so doing solve said challenges? Personally, I prefer the original: To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? [Apologies in advance for the inevitably botched translation.]
    - pekk 14y ago
      Shakespeare was not arguing about programming languages, though.
      - biot 14y ago
        The comment I replied to said "You really shouldn't try to use metaphors when making an argument." Was Shakespeare not using his characters to present an argument for dramatic effect?
        fkdjs 14y ago
        Shakespeare is entertaining and metaphors are fun. Do you disagree with a poem and bring up logical fallacies? Of course not, we read them for entertainment value and anything we learn is a bonus. That is separate from metaphors used when trying to discuss the nuances of an argument within the confines of trying to have a logical argument. Poems and Shakespeare aren't supposed to be logical all the time, that would be boring.
- spinlock 14y ago
  Glad to see this is the top comment. Makes me believe hackernews is still a smart place.
apunic 14y ago
> JavaScript is not the Assembly of the Web. It’s the C of the web. The to-JS languages are lining up to become the C++ of the web. Point well made.
- deleted 14y ago
  [deleted]
jfaucett 14y ago
OP nailed it on this one - got nothing else to add :)
leeoniya 14y ago
i think the "JS is assembly for the web" strictly refers to the fact that you cannot write closer-to-the-metal code than javascript. it'c certainly not the C-of-the-web either, but some combination of the two. i do agree that there are more parallels to C than to asm, but nit-picking the differences will lead to no adage at all :) "Assembly varies wildly between architectures" - but javascript runs on a single architecture. it's just that browser vendors all implement the same one. the other points are valid, but i dont think this was ever supposed to be that deep a comparison.
- stormbrew 14y ago
  > i think the "JS is assembly for the web" strictly refers to the fact that you cannot write closer-to-the-metal code than javascript. This exactly. JS is the lowest level of code you can reliably run through a browser. That makes it, by definition, the 'metal' of the web. And that will probably not change for a very long time.
- pekk 14y ago
  you "cannot" write closer-to-the-metal code only because of artificial controls on the platform, not because of how low-level it is.
jiggy2011 14y ago
So, because coffeescript doesn't optimise well for different JS platforms then JS is not like assembly?
- jiggy2011 14y ago
  Seem to be getting a lot of downvotes here, is there something in the article that I missed? I don't see if there's any reason it would be impossible to build a compiler for a very high level expressive language like say Haskell and have it generate javascript code that would be well optimised for a particular runtime (maybe via asm.js). The article seems to make the argument that javascript is not analogous to assembler because coffeescript is basically just syntactic sugar. Argument 3, "You still need to grok the DOM, or node, or whatever other platform your program is interacting with, and that’s probably documented in JavaScript." is especially weird because I don't see how that isn't true with assembler also. Asm written for Windows is going to be doing different stuff to asm written for Linux.
vault_ 14y ago
I don't think equating languages that compile to javascript with C++ improves the analogy all that much. If anything a better analog would be a language that compiles to C like Chicken Scheme or Vala. I also don't think that comparing one's language to C++ is necessarily a good way to advertise it. ;)
- Helianthus 14y ago
  That's the point. Languages lining up to become the C++ of the web is actually a better way of looking at the field.
  - spacemanaki 14y ago
    No it's not. There are a bunch of language implementations that compile to C, with semantics nothing like C++. Just as there are a bunch of language implementations that compile to JS but have semantics that differ from JS or whatever "JS++" would be.
    - Helianthus 14y ago
      ...My point being that JS++ would be repeating the mistakes of C++.
- mseepgood 14y ago
  The first C++ (at that time "C with Classes") compiler, cfront, compiled to C code.
  - ibotty 14y ago
    but that's a looong time ago.
rayiner 14y ago
Maybe it's most accurate to say that Javascript is the x86 of the web. Modern CPU's have a totally different internal semantics but emulate the x86 machine model externally. Seems pretty parallel to how asm.js works.
- philwelch 14y ago
  Aside from all the ARM CPUs we carry around in our pockets, you mean.
  - rayiner 14y ago
    Left off the "x86" in "modern x86 CPUs"
    - philwelch 14y ago
      It's still a bad analogy since more devices probably understand JavaScript than understand x86 nowadays.
      - rayiner 14y ago
        The analogy was getting at the fact that in asm.js, JavaScript is used almost as a byte code input to a compiler that has a very different underlying machine model, just as x86 is used as such by modern x86 CPUs. In both cases the somewhat strange dynamic has arisen from the pervasiveness of devices that understand x86, JavaScript. Whether JavaScript or x86 is more prevalent is really neither here nor there.
zachrose 14y ago
I use CoffeeScript as an alternative syntax, on a similar level of the tooling stack as auto-completion in a text editor.
whadar 14y ago
Who wrote JavaScript is web assembly in the first place?
- michaelwww 14y ago
  I would appear to be Erik Meijer: JavaScript is an assembly language. The JavaScript + HTML generate is like a .NET assembly. The browser can execute it, but no human should really care what’s there. http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...
  - whadar 14y ago
    Oh dear... .NET assembly != assembly (x86, RISC, etc.) And NOBODY writes .NET assembly by hand. JS on the other hand is coded by so many
- rocky1138 14y ago
  https://news.ycombinator.com/user?id=trapezor https://news.ycombinator.com/user?id=trapezor said this to me the other day when I incorrectly mentioned that Javascript was not a compiled language. I like the comparison of Javascript = C of the web versus Javascript = assembly of the web.
  - whadar 14y ago
    Yes. C is more to the point. I like to think about js more as interpreted language...
ArchD 14y ago
I think he misses one of the important points of comparing JS with assembly. Not only is assembly unportable, it's hard to read and hard to write for a human being. People use languages like Coffeescript not necessarily to deal with portability, but to avoid the quirks of JS that make it hard to read and write.
- coldtea 14y ago
  All 10 of them? Because people have been writing huge programs in plain JS just fine. More often than not, Coffeescript is used for plain vanilla front end code, the kind of that people can do in JS with their eyes closed.
  - ArchD 14y ago
    I'm sure the quirks can be dealt with given enough time and energy to climb the learning curve, but some people just don't want to spend energy on it when they can learn another language. I, for example, don't deal with JS daily and can't remember those quirks by heart.
Aardwolf 14y ago
If I deploy a game in JavaScript (or Flash...), and release it on the Internet, then people are actually going to play it! If instead the game has to be downloaded and installed, chances of someone bothering are almost nihil.
- jiggy2011 14y ago
  I don't think that's necessarily true. Sure installation puts up a higher barrier but you can probably overcome that by making installation easy (app stores etc) and making sure you have plenty of videos & screenshots on your site to make the game look appealing. I have a feeling that people place a higher value on games that they install anyway (I know I do) and may be more likely to replay it if it's in their Steam list or has an icon on their desktop. Whereas flash games are often seen as pretty disposable.
  - camus 14y ago
    because most flash games are crappy anyway. some could have a greater audience if there was an offline disttibution.
jervisfm 14y ago
If JavaScript is more like the C of the web rather than the assembly of the web, then what can be considered as the assembly of the assembly of the web ? Or is this an invalid question to ask ?
- lallysingh 14y ago
  Plugins, possibly NativeClient. In many languages, C is the output of the compiler. C's treated as portable assembler. I think that's the proper analogy here. Those languages don't have something lower-level than C.
Arelius 14y ago
There is just so many holes in his comparison that even if it's broadly a good point. It's lost in the details. His whole argument depends on the comparison between Javascript and generally "Assembly" but as he argues against the label "Web Assembly" the proper comparison is from Javascript and X Assembly, where X may be X86 for instance. > If you are designing a language, compiling it to JavaScript is a pretty attractive option, for much the same reason that compiling C to machine code is an attractive option: running it in more places. No, you compile C to machine code because that is it's execution model, or perhaps because of performance. You do not "compile C to machine code to run it in more places" This however is not central to his argument. > They’re mostly backwards compatible with JavaScript Not languages compiled through the emscriptn model. > You still need to grok the DOM, or node, or whatever other platform your program is interacting with, and that’s probably documented in JavaScript. The same is true for compiled languages. The fact that they are often documented in C is just an artifact. > They break almost all of the tooling that exists for JavaScript debugging Anyone who has ever worked on a new compiled language knows that this is also problems of compile-to-asm languages. > CoffeeScript programs don’t vary any less across architectures than the JavaScript programs it creates. Again, this is true in the C->X86 ASM also. > CoffeeScript does not offer an order of magnitude difference in expressiveness This is the strongest point of his argument, but just goes to show that he takes the metaphor much too strongly, and misses the whole point of it in the first place.
- Justsignedup 14y ago
  The best analysis. The only thing I'd add is: There is literally no other language you can write in that will run against the following, Oh multiplex for osx, linux, windows, ios, android, symbian, and windows phone, blackberry, etc whenever possible: IE, Firefox, Opera, Safari, Chrome, Old android browser, webkit derivitives, etc. JS is the only language available everywhere so everything targets it. That's that. No other reason. Ideally a bytecode would be created with standard libraries and a browser extension and js fallback for a more efficient language that even js can be compiled to. But we have this not atm.
  - KMag 14y ago
ibotty 14y ago
> JavaScript is not the Assembly of the Web. It’s the C of the web. The to-JS languages are lining up to become the C++ of the web. that's just uninformed. both analogies are wrong. but yours is even more so. c++ is usually compiled down to assembly w/o going through c (there have been a few but it has not been mainstream for _many_years). so coffeescript or any other to-js language is _not_ the c++ of the web! the author implies, that (say) coffeescript is to js as c++ is to c. but before (s)he gives two reasons about c over assembly. 1. assembly is variable, c is a constant, 2. c is way more expressive. there is some truth in the first on, that one does not hold for js. whether it really holds for assembly is debatable given how much porting is involved for arm devices. and if you think about asm.js you might think that's a different assembly (js to asm.js is like asm to simd instructions maybe?). the second point might not hold for coffeescript, but look at closure, fay or elm. they are very distinct from javascript.
- xd 14y ago
  "there is some truth in the first on" What do you mean "some truth" .. different CPU architectures have different assembly language .. what's to get? Oh, and SIMD instructions are an extension to the x86 instruction set .. not an abstraction. What is your background on low level development, may I ask?
  - ibotty 14y ago
    maybe i did not make myself very clear. i tried to address the analogy which is implied by these two points. and it is true, that for coffeescript on javascript, coffeescript is not more constant and js is not more variable. but that's not the point of the argument javascript were the assembly of the web. the point is, that all these languages compile down to js. as c and c++ compile down to assembly. and honestly the "c is constant" is not right some of the time either. consider small/big endianness, different libcs. heck, even the syntax changed (k&r surely looks and feels different). my comment on simd instructions to assembly was an analogy to asm.js and javascript.
- munificent 14y ago
  > The to-JS languages are lining up to become the C++ of the web. What I find funny about this remark was that I think it was intended to be disparaging because the meme these days is that C++ sucks. But C++ is actually wildly successful and is the bastion of many very large, complex, fast, applications that would be very challenging to write in vanilla. Yes, you can stick to just C, but many many programmers have profitably switched to C++ instead. Almost the entire game industry, most desktop applications that people use for their jobs, web browsers and even JavaScript engines themselves are all written in C++. If the new crop of compile-to-JS languages are in a similar boat, then sign me up!
philfreo 14y ago
His biggest argument is that CoffeeScript isn't run on "multiple architectures". However you could consider multiple browsers to be "multiple architectures". While this isn't super common, it's entirely possible to have CoffeeScript/Foo to compile to different "builds" of JS -- one that gets loaded in modern browsers, and another that gets loaded in older IE where built-in ES5 functions aren't available.
mseepgood 14y ago
I always found it silly to compare an expensive language like JavaScript, that couldn't be further away from the machine, to assembly language. A language where data stuctures are hash maps with string keys, where numbers are boxed doubles on the heap, etc. An array of points in C: http://s3.mrale.ph/images/array-of-points-structure-c.png http://s3.mrale.ph/images/array-of-points-structure-c.png An array of points in JavaScript: http://s3.mrale.ph/images/array-of-points-structure-javascript.png http://s3.mrale.ph/images/array-of-points-structure-javascri...
- camus 14y ago
  nobody serious said javascript was the assembly of the web,that's the issue.
  - xd 14y ago
    But there lies the issue, it IS serious when you cross meanings in any professional field.
- Lerc 14y ago
  That is not the only way to do it in Javascript though. if you allocate an ArrayBuffer then you are dealing with a plain block of bytes that you can treat as points (or anything else). These are the things that Javascript has been growing to facilitate the idea of js as asm. Emscripten uses ArrayBuffers to allow C to compile to JS without the messiness.
- MostAwesomeDude 14y ago
  You really feel that JS "couldn't be further away from the machine?" What about languages that don't have a specified execution model? Haskell and other MLs, for example.
  - gngeal 14y ago
    I believe that these languages do have a specified execution model (how would you execute them without one?), they just don't have any hard prescription as to how to map it onto hardware the same way that, for example, C does.
Lerc 14y ago
There are far more meaningful reasons why JavaScript is not Web assembly than metaphor wrangling. There are things that you simply cannot do in JavaScript that you can in assembly. Many of those are horrible practices with little use. In assembly, if the computer can do it you can do it. C retains most of those abilities because it compiles to Assembly/Machine code. How does one even write the unix cat command in JavaScript? The structure of while(read())write() does not go down well in JavaScript. JavaScript needs to be able to fork, wait and preempt if it wants to be assembly.
- macspoofing 14y ago
  >There are things that you simply cannot do in JavaScript that you can in assembly. Urgh. Way to completely not understand the "assembly of the web" metaphor. OF COURSE JavaScript is not literally like assembly.
  - Lerc 14y ago
    I understand the different interpretations of the metaphor. That's the problem with metaphors, they are open to interpretation. With Javascript the term assembly for the web has been used seriously by people in a variety of contexts. Brendan Eich has argued against a bytecode vm approach to a low level powerful system, saying that Javascript can provide that low level functionality. This is very much the viewpoint that the capability can be considered comparable to assembly. I don't think that is correct but I recognise that that is what some people refer to as assembly for the web. I really don't care what it is called and what metaphor is used, that is all trivial compared to the fact that Javascript is not up to performing all the tasks that it should be able to do if it wishes to be a comprehensive platform.
    - macspoofing 14y ago
      >Javascript is not up to performing all the tasks that it should be able to do if it wishes to be a comprehensive platform. Like what?
mion 14y ago
With all the interesting things going on right now on planet Earth, it amazes me that a post about "The Correctness of JavaScript Analogies" makes it to the top on HN.
JulianMorrison 14y ago
C is not C. That is, the C you get out of a language that is doing optimization of high level stuff into legal, portable C as a compile target is not the language you'd use if you, a human, were coding in C. And this is very analogous to, for example, the code generated by a high level language targeting modern JS. It's going to allocate stuff on arrays, and use cryptic pointers, and do things the odd way around when it turns out to be faster. It's going to have unhelpfully named variables, and no unnecessary whitespace or comments, and it's going to operate silently on dangerous-looking assumptions that it's proven safe at a higher level. Sure, generated C interops easily with manual C, just like generated JS interops easily with traditional hand coded JS, but they have little in common except their formal grammar.
ricardobeat 14y ago
I thought this was going to be about Emscripten, asm.js, compiled "desktop languages"? CoffeeScript and other to-js languages are not what people mean when talking "javascript is web assembly".
- acqq 14y ago
  Exactly. Looks like OP "missed the joke" completely.
United857 14y ago
Well, with the advent of asm.js and various tools like emscripten that compile down to it, perhaps it's a bit more of an apt analogy now.
spacemanaki 14y ago
Previously... https://news.ycombinator.com/item?id=2997952 https://news.ycombinator.com/item?id=2997952
xd 14y ago
Far to many comments are coming across like they where from students fresh out of compilers 101 .. please guys; cool your engines, for the sake of the community.
S4M 14y ago
This is a repost. Comments from the original submission: http://news.ycombinator.com/item?id=2997952 http://news.ycombinator.com/item?id=2997952
r0s 14y ago
> They break almost all of the tooling that exists for JavaScript debugging. I just don't see the utility of pre-processors for JS or CSS. I know I'm in the minority here, are developers really working without debugging? I can't wrap my head around that workflow.
- lowboy 14y ago
  I code in CoffeeScript a fair bit, and I don't find it's that bad even without source maps[0] because of the similarity between CS source and JS output. I can put in debugger statements and breakpoints just as I would in vanilla JS. [0]: http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...
  - codesuela 14y ago
    this, the notion that CoffeeScript generated code resembles some kind of arcane binary like output is wrong. As knowing the basics of JavaScript is pretty much a requirement for working with CoffeScript I never ever encountered any problems when debugging generated code because is not obfuscated and easy to read and the compiler doesn't do anything you didn't specifically write in your CoffeeScript. I am going to go out on a limb here and say that I think compiled CoffeeScript is easier to read then most peoples hand written JS. What makes code unreadable is the Closure compiler which is completely different beast.
- papsosouid 14y ago
  >I just don't see the utility of pre-processors for JS or CSS. I'm not sure how CSS comes into the discussion, it isn't executed, and thus isn't debugged. And things like SASS and LESS are fairly simple, straightforward pre-processors. >I know I'm in the minority here, are developers really working without debugging? I don't think so. You couldn't pay me enough to write javascript. But I have to end up with some javascript because browsers don't support anything reasonable. So I use a haskell -> javascript compiler. I still have to read javascript to debug what is going wrong, but at least I don't have to write it.
pan69 14y ago
The author of this post misses the point of the expression completely. The expression has nothing to do with assembly language but it has to do with the fact that Javascript will be further and further abstracted away over time but yet, all these abstractions will compile down to Javascript. In due time no one will be programming in Javascript except for a few geeks. This is similar to what happened to assembly language and in that way Javascript compares to assembly language.
- samatman 14y ago
  That seems like an odd prediction to make for an expressive, dynamic, C-like language. It's nice to have other options, but I suspect that large amounts of vanilla Javascript will be written for many years to come.
  - pan69 14y ago
    I'm sure that in the late 70's or early 80's people said the same thing about assembly language and guess what, even today there are still people programming in assembly. The point is that languages change faster than the platforms they run on. Why else would there be CoffeeScript or Haxe? It's just a natural evolution. To us Javascript might seem perfectly acceptable as a programming language but only time will tell if the next generation of programmers will feel the same about that.
    - fusiongyro 14y ago
      Yes, but they also said that about SQL, starting in the 90s. The more high-level the thing you're trying to hide is, the more likely it'll keep peeking out from underneath your abstraction layer.
- spinlock 14y ago
  Do you know who made the original comparison? It seems like the context of the statement is the only way to groc the semantics.
podperson 14y ago
> If you are designing a language, compiling it to JavaScript is a pretty attractive option, for much the same reason that compiling C to machine code is an attractive option: running it in more places. This sentence badly written. The point of the article is that Javascript is the C of the web, and if this sentence were put together correctly it would make the point.
tlrobinson 14y ago
He seems to be offended by people comparing JavaScript to assembly, but when people say "JavaScript is web assembly" they're usually making a specific point about how you can write languages that compile to JavaScript, not an overall judgement of the language. Of course JavaScript has more in common with C than assembly, but context matters.
stcredzero 14y ago
"JavaScript is web assembly" is actually a bastardization of "JS is web bytecode." And really, that's just shortcut for saying it's the closest thing we have, but in many cases, it's good enough and it's certainly better than nothing.
frozenport 14y ago
Maybe its the LLVM of the web?
justizin 14y ago
This would be a lot more interesting if any of the conclusions it draws were remotely cogent, except that JavaScript is Not Web Assembly, and that it is (kind of) like C. The to-JS languages are nothing like C++, you just don't need to compare in this way, these things are apples and oranges. The JVM is more like the assembly target of the web, and it's a horrid failure in security and stability. Maybe some folks should start anew with something like LLVM as a target, with the first conversations about security. That would probably suck too, though. Things don't have to be the Things of Things. That's what we should take away from this.
namank 14y ago
Umm...ok. So what is the assembly of the web? I feel like the author should be given a lesson in rhetoric.
jmspring 14y ago
First, everything needed to run on the JVM. Now, everything must compile down to javascript and run in the JS vm. The cycle will continue.
ahoge 14y ago
"JS is the crappy ill-suited compiler target everyone is forced to use." Now, if you say instead that it's low-level ("assembly"), fans of JS feel smug about using it instead of being offended. However, at the same time you hint that JS is something which shouldn't be written by humans.
aaronbrethorst 14y ago
"CoffeeScript may require fewer tokens, sure, but not 10 to 1 fewer." True, but I find that its real power is in not forcing me to remember all sorts of crazy-ass stuff that's only relevant because JavaScript, as a language, is just sort of batshit crazy. Case in point: I'm doing some work right now that requires me to use JavaScript[1]. Today, I was writing your typical 'is this variable undefined or not?' if-clauses: if (typeof foo !== 'undefined') { bar(); } Obviously, I don't do this enough, because I ended up having to look the stupid thing up instead of just knowing it ("I know I have to use === for equality; is the equivalent 'not-equals' version only two equals signs or three?", and so forth). In CoffeeScript, in comparison, I'd simply write: bar() if not foo? It takes a lot less mental energy for me to remember the second version than the first. Also, if I had a nickel for every time I've had to write var that = this... Anyway, suffice it to say that CoffeeScript may not be an order of magnitude more expressive, but it's cheap enough to get up and running that its benefits are well, well worth it to me. [1] It's an iOS app that has a critical component built into a UIWebView, and there is absolutely no way to make this stuff native, seeing how it's rendering HTML. I guess I could rig up some awful build phase voodoo that would compile my .coffee files, but that sounds ridiculous.
firlefans 14y ago
The author claims that C has "an order of magnitude more expressiveness" than assembly with no basis for the statement, but ok. He then throws all the "compile-to-JS" languages together even specifically mentioning Sibilant which has macros. If there is another 10x expressivity gain to be had by adding any language feature then surely macros are it.
lucian303 14y ago
Absolutely. People who add complexity to software development neeclessly have it completely backwards.
bjhoops1 14y ago
document.getElementsByTagName("body")[0].innerHTML.replace(/metaphor/gi,"simile");

178 points by niggler 14y ago

I fear that this is one of those "I've heard someone make a metaphor and taken it too literally, then rebutted that literalism broadly." I imagine 99% of the time that metaphor is made the author would be just as happy saying "JS is the new C", it simply doesn't roll off the tongue as well.

Helianthus 14y ago
It's not, in fact; it's a good extension and modification of the metaphor. Not that the original metaphor is wrong or useless; but thinking of javascript as C provides some glimpse into the risks of what made C++ problematic. The author picks Coffeescript as an example of a fairly sensible approach to the problem, but "the language-wank crazy" are taking a lot of risky approaches.
- deleted 14y ago
  [deleted]
Cushman 14y ago
I agree with the first part, disagree with the second. "JavaScript is assembly" is, in my estimation, usually a rather blase metaphor for the idea of JavaScript as a compile target. People don't say "JavaScript is the new C" because generally you don't target C. (Generally you don't target assembly, either, but the distinction between assembly and machine code is academic to most people.) And it's no surprise that we're getting lost in this; making arguments based on metaphors rather than the thing itself is a classic trap. We should make an effort where possible to talk about what JavaScript is rather than what it "is".
- scott_s 14y ago
  I guess it depends on how general you mean "generally" to be, but there is a history of people targeting C for new and experimental languages. It's a convenient target because we have a good idea of what kind of assembly will be created for a given chunk of C, and you can get architecture independence for free.
  - Cushman 14y ago
    > and you can get architecture independence for free And you target JavaScript for precisely the same reason :) Perhaps the better way to say it is this: C is a language which was once written by hand, but which is increasingly being used as a target for higher-level languages. The same thing is happening to JS, but at least to me "JavaScript is the new C" is not a particularly useful way to express that similarity.
- vidarh 14y ago
  > because generally you don't target C. (Generally you don't target assembly, either, but the distinction between assembly and machine code is academic to most people.) You're excluding a large chunk of compilers with those two generalizations. Targeting assembly rather than directly emitting machine code is extremely common (gcc being one of the obvious examples), and targeting C is very common for new/experimental languages.
  - Cushman 14y ago
    All I'm trying to say is that "a target for higher-level languages" is not a defining attribute of C in a way that makes "JavaScript is the new C" a helpful analogy.
- deleted 14y ago
  [deleted]
- fauigerzigerk 14y ago
  "making arguments based on metaphors rather than the thing itself is a classic trap" Well, yes and no. I do agree that it often goes completely wrong and can be very misleading. But the JavaScript/assembly argument is more an analogy than it is a metaphor, and analogies are a very important function of intelligence and a tool for making important discoveries. That said, I like your generalization "compile target" a lot more than calling JavaScript assembly.
- epsylon 14y ago
  There are a lot of compilers that target directly C.
deleted 14y ago
[deleted]
amirouche 14y ago
This can help https://news.ycombinator.com/item?id=4630057 https://news.ycombinator.com/item?id=4630057 «JS is the web's “virtual machine”» Brendan Eich
fkdjs 14y ago
You really shouldn't try to use metaphors when making an argument. Someone says A is like B, another person disagrees that A is like C. But no, says another, A is like D. Finally, an internet troll points out A is like B and D, but definitely not like C. By then, everyone's brain gives up trying to figure it all out. If you're gonna make a point, make a point, it's that simple.
- biot 14y ago
  Are you arguing that metaphors have no value when explaining a concept? I'm sure Shakespeare would be a whole lot more boring without the use of metaphor: To be, or not to be: one could ponder: Whether one's sense of self-worth increases In direct proportion to one's ability to accept adversity, Or to address challenges, And in so doing solve said challenges? Personally, I prefer the original: To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? [Apologies in advance for the inevitably botched translation.]
  - pekk 14y ago
    Shakespeare was not arguing about programming languages, though.
    - biot 14y ago
      The comment I replied to said "You really shouldn't try to use metaphors when making an argument." Was Shakespeare not using his characters to present an argument for dramatic effect?
      - fkdjs 14y ago
        Shakespeare is entertaining and metaphors are fun. Do you disagree with a poem and bring up logical fallacies? Of course not, we read them for entertainment value and anything we learn is a bonus. That is separate from metaphors used when trying to discuss the nuances of an argument within the confines of trying to have a logical argument. Poems and Shakespeare aren't supposed to be logical all the time, that would be boring.
spinlock 14y ago
Glad to see this is the top comment. Makes me believe hackernews is still a smart place.

apunic 14y ago

> JavaScript is not the Assembly of the Web. It’s the C of the web. The to-JS languages are lining up to become the C++ of the web. Point well made.

deleted 14y ago
[deleted]

jfaucett 14y ago

OP nailed it on this one - got nothing else to add :)

leeoniya 14y ago

i think the "JS is assembly for the web" strictly refers to the fact that you cannot write closer-to-the-metal code than javascript. it'c certainly not the C-of-the-web either, but some combination of the two. i do agree that there are more parallels to C than to asm, but nit-picking the differences will lead to no adage at all :) "Assembly varies wildly between architectures" - but javascript runs on a single architecture. it's just that browser vendors all implement the same one. the other points are valid, but i dont think this was ever supposed to be that deep a comparison.

stormbrew 14y ago
> i think the "JS is assembly for the web" strictly refers to the fact that you cannot write closer-to-the-metal code than javascript. This exactly. JS is the lowest level of code you can reliably run through a browser. That makes it, by definition, the 'metal' of the web. And that will probably not change for a very long time.
pekk 14y ago
you "cannot" write closer-to-the-metal code only because of artificial controls on the platform, not because of how low-level it is.

jiggy2011 14y ago

So, because coffeescript doesn't optimise well for different JS platforms then JS is not like assembly?

jiggy2011 14y ago
Seem to be getting a lot of downvotes here, is there something in the article that I missed? I don't see if there's any reason it would be impossible to build a compiler for a very high level expressive language like say Haskell and have it generate javascript code that would be well optimised for a particular runtime (maybe via asm.js). The article seems to make the argument that javascript is not analogous to assembler because coffeescript is basically just syntactic sugar. Argument 3, "You still need to grok the DOM, or node, or whatever other platform your program is interacting with, and that’s probably documented in JavaScript." is especially weird because I don't see how that isn't true with assembler also. Asm written for Windows is going to be doing different stuff to asm written for Linux.

vault_ 14y ago

I don't think equating languages that compile to javascript with C++ improves the analogy all that much. If anything a better analog would be a language that compiles to C like Chicken Scheme or Vala. I also don't think that comparing one's language to C++ is necessarily a good way to advertise it. ;)

Helianthus 14y ago
That's the point. Languages lining up to become the C++ of the web is actually a better way of looking at the field.
- spacemanaki 14y ago
  No it's not. There are a bunch of language implementations that compile to C, with semantics nothing like C++. Just as there are a bunch of language implementations that compile to JS but have semantics that differ from JS or whatever "JS++" would be.
  - Helianthus 14y ago
    ...My point being that JS++ would be repeating the mistakes of C++.
mseepgood 14y ago
The first C++ (at that time "C with Classes") compiler, cfront, compiled to C code.
- ibotty 14y ago
  but that's a looong time ago.

rayiner 14y ago

Maybe it's most accurate to say that Javascript is the x86 of the web. Modern CPU's have a totally different internal semantics but emulate the x86 machine model externally. Seems pretty parallel to how asm.js works.

philwelch 14y ago
Aside from all the ARM CPUs we carry around in our pockets, you mean.
- rayiner 14y ago
  Left off the "x86" in "modern x86 CPUs"
  - philwelch 14y ago
    It's still a bad analogy since more devices probably understand JavaScript than understand x86 nowadays.
    - rayiner 14y ago
      The analogy was getting at the fact that in asm.js, JavaScript is used almost as a byte code input to a compiler that has a very different underlying machine model, just as x86 is used as such by modern x86 CPUs. In both cases the somewhat strange dynamic has arisen from the pervasiveness of devices that understand x86, JavaScript. Whether JavaScript or x86 is more prevalent is really neither here nor there.

zachrose 14y ago

I use CoffeeScript as an alternative syntax, on a similar level of the tooling stack as auto-completion in a text editor.

whadar 14y ago

Who wrote JavaScript is web assembly in the first place?

michaelwww 14y ago
I would appear to be Erik Meijer: JavaScript is an assembly language. The JavaScript + HTML generate is like a .NET assembly. The browser can execute it, but no human should really care what’s there. http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...
- whadar 14y ago
  Oh dear... .NET assembly != assembly (x86, RISC, etc.) And NOBODY writes .NET assembly by hand. JS on the other hand is coded by so many
rocky1138 14y ago
https://news.ycombinator.com/user?id=trapezor https://news.ycombinator.com/user?id=trapezor said this to me the other day when I incorrectly mentioned that Javascript was not a compiled language. I like the comparison of Javascript = C of the web versus Javascript = assembly of the web.
- whadar 14y ago
  Yes. C is more to the point. I like to think about js more as interpreted language...

ArchD 14y ago

I think he misses one of the important points of comparing JS with assembly. Not only is assembly unportable, it's hard to read and hard to write for a human being. People use languages like Coffeescript not necessarily to deal with portability, but to avoid the quirks of JS that make it hard to read and write.

coldtea 14y ago
All 10 of them? Because people have been writing huge programs in plain JS just fine. More often than not, Coffeescript is used for plain vanilla front end code, the kind of that people can do in JS with their eyes closed.
- ArchD 14y ago
  I'm sure the quirks can be dealt with given enough time and energy to climb the learning curve, but some people just don't want to spend energy on it when they can learn another language. I, for example, don't deal with JS daily and can't remember those quirks by heart.

Aardwolf 14y ago

If I deploy a game in JavaScript (or Flash...), and release it on the Internet, then people are actually going to play it! If instead the game has to be downloaded and installed, chances of someone bothering are almost nihil.

jiggy2011 14y ago
I don't think that's necessarily true. Sure installation puts up a higher barrier but you can probably overcome that by making installation easy (app stores etc) and making sure you have plenty of videos & screenshots on your site to make the game look appealing. I have a feeling that people place a higher value on games that they install anyway (I know I do) and may be more likely to replay it if it's in their Steam list or has an icon on their desktop. Whereas flash games are often seen as pretty disposable.
- camus 14y ago
  because most flash games are crappy anyway. some could have a greater audience if there was an offline disttibution.

jervisfm 14y ago

If JavaScript is more like the C of the web rather than the assembly of the web, then what can be considered as the assembly of the assembly of the web ? Or is this an invalid question to ask ?

lallysingh 14y ago
Plugins, possibly NativeClient. In many languages, C is the output of the compiler. C's treated as portable assembler. I think that's the proper analogy here. Those languages don't have something lower-level than C.

Arelius 14y ago

There is just so many holes in his comparison that even if it's broadly a good point. It's lost in the details. His whole argument depends on the comparison between Javascript and generally "Assembly" but as he argues against the label "Web Assembly" the proper comparison is from Javascript and X Assembly, where X may be X86 for instance. > If you are designing a language, compiling it to JavaScript is a pretty attractive option, for much the same reason that compiling C to machine code is an attractive option: running it in more places. No, you compile C to machine code because that is it's execution model, or perhaps because of performance. You do not "compile C to machine code to run it in more places" This however is not central to his argument. > They’re mostly backwards compatible with JavaScript Not languages compiled through the emscriptn model. > You still need to grok the DOM, or node, or whatever other platform your program is interacting with, and that’s probably documented in JavaScript. The same is true for compiled languages. The fact that they are often documented in C is just an artifact. > They break almost all of the tooling that exists for JavaScript debugging Anyone who has ever worked on a new compiled language knows that this is also problems of compile-to-asm languages. > CoffeeScript programs don’t vary any less across architectures than the JavaScript programs it creates. Again, this is true in the C->X86 ASM also. > CoffeeScript does not offer an order of magnitude difference in expressiveness This is the strongest point of his argument, but just goes to show that he takes the metaphor much too strongly, and misses the whole point of it in the first place.

Justsignedup 14y ago
The best analysis. The only thing I'd add is: There is literally no other language you can write in that will run against the following, Oh multiplex for osx, linux, windows, ios, android, symbian, and windows phone, blackberry, etc whenever possible: IE, Firefox, Opera, Safari, Chrome, Old android browser, webkit derivitives, etc. JS is the only language available everywhere so everything targets it. That's that. No other reason. Ideally a bytecode would be created with standard libraries and a browser extension and js fallback for a more efficient language that even js can be compiled to. But we have this not atm.
- KMag 14y ago

ibotty 14y ago

> JavaScript is not the Assembly of the Web. It’s the C of the web. The to-JS languages are lining up to become the C++ of the web. that's just uninformed. both analogies are wrong. but yours is even more so. c++ is usually compiled down to assembly w/o going through c (there have been a few but it has not been mainstream for _many_years). so coffeescript or any other to-js language is _not_ the c++ of the web! the author implies, that (say) coffeescript is to js as c++ is to c. but before (s)he gives two reasons about c over assembly. 1. assembly is variable, c is a constant, 2. c is way more expressive. there is some truth in the first on, that one does not hold for js. whether it really holds for assembly is debatable given how much porting is involved for arm devices. and if you think about asm.js you might think that's a different assembly (js to asm.js is like asm to simd instructions maybe?). the second point might not hold for coffeescript, but look at closure, fay or elm. they are very distinct from javascript.

xd 14y ago
"there is some truth in the first on" What do you mean "some truth" .. different CPU architectures have different assembly language .. what's to get? Oh, and SIMD instructions are an extension to the x86 instruction set .. not an abstraction. What is your background on low level development, may I ask?
- ibotty 14y ago
  maybe i did not make myself very clear. i tried to address the analogy which is implied by these two points. and it is true, that for coffeescript on javascript, coffeescript is not more constant and js is not more variable. but that's not the point of the argument javascript were the assembly of the web. the point is, that all these languages compile down to js. as c and c++ compile down to assembly. and honestly the "c is constant" is not right some of the time either. consider small/big endianness, different libcs. heck, even the syntax changed (k&r surely looks and feels different). my comment on simd instructions to assembly was an analogy to asm.js and javascript.
munificent 14y ago
> The to-JS languages are lining up to become the C++ of the web. What I find funny about this remark was that I think it was intended to be disparaging because the meme these days is that C++ sucks. But C++ is actually wildly successful and is the bastion of many very large, complex, fast, applications that would be very challenging to write in vanilla. Yes, you can stick to just C, but many many programmers have profitably switched to C++ instead. Almost the entire game industry, most desktop applications that people use for their jobs, web browsers and even JavaScript engines themselves are all written in C++. If the new crop of compile-to-JS languages are in a similar boat, then sign me up!

philfreo 14y ago

His biggest argument is that CoffeeScript isn't run on "multiple architectures". However you could consider multiple browsers to be "multiple architectures". While this isn't super common, it's entirely possible to have CoffeeScript/Foo to compile to different "builds" of JS -- one that gets loaded in modern browsers, and another that gets loaded in older IE where built-in ES5 functions aren't available.

mseepgood 14y ago

I always found it silly to compare an expensive language like JavaScript, that couldn't be further away from the machine, to assembly language. A language where data stuctures are hash maps with string keys, where numbers are boxed doubles on the heap, etc. An array of points in C: http://s3.mrale.ph/images/array-of-points-structure-c.png http://s3.mrale.ph/images/array-of-points-structure-c.png An array of points in JavaScript: http://s3.mrale.ph/images/array-of-points-structure-javascript.png http://s3.mrale.ph/images/array-of-points-structure-javascri...

camus 14y ago
nobody serious said javascript was the assembly of the web,that's the issue.
- xd 14y ago
  But there lies the issue, it IS serious when you cross meanings in any professional field.
Lerc 14y ago
That is not the only way to do it in Javascript though. if you allocate an ArrayBuffer then you are dealing with a plain block of bytes that you can treat as points (or anything else). These are the things that Javascript has been growing to facilitate the idea of js as asm. Emscripten uses ArrayBuffers to allow C to compile to JS without the messiness.
MostAwesomeDude 14y ago
You really feel that JS "couldn't be further away from the machine?" What about languages that don't have a specified execution model? Haskell and other MLs, for example.
- gngeal 14y ago
  I believe that these languages do have a specified execution model (how would you execute them without one?), they just don't have any hard prescription as to how to map it onto hardware the same way that, for example, C does.

Lerc 14y ago

There are far more meaningful reasons why JavaScript is not Web assembly than metaphor wrangling. There are things that you simply cannot do in JavaScript that you can in assembly. Many of those are horrible practices with little use. In assembly, if the computer can do it you can do it. C retains most of those abilities because it compiles to Assembly/Machine code. How does one even write the unix cat command in JavaScript? The structure of while(read())write() does not go down well in JavaScript. JavaScript needs to be able to fork, wait and preempt if it wants to be assembly.

macspoofing 14y ago
>There are things that you simply cannot do in JavaScript that you can in assembly. Urgh. Way to completely not understand the "assembly of the web" metaphor. OF COURSE JavaScript is not literally like assembly.
- Lerc 14y ago
  I understand the different interpretations of the metaphor. That's the problem with metaphors, they are open to interpretation. With Javascript the term assembly for the web has been used seriously by people in a variety of contexts. Brendan Eich has argued against a bytecode vm approach to a low level powerful system, saying that Javascript can provide that low level functionality. This is very much the viewpoint that the capability can be considered comparable to assembly. I don't think that is correct but I recognise that that is what some people refer to as assembly for the web. I really don't care what it is called and what metaphor is used, that is all trivial compared to the fact that Javascript is not up to performing all the tasks that it should be able to do if it wishes to be a comprehensive platform.
  - macspoofing 14y ago
    >Javascript is not up to performing all the tasks that it should be able to do if it wishes to be a comprehensive platform. Like what?

mion 14y ago

With all the interesting things going on right now on planet Earth, it amazes me that a post about "The Correctness of JavaScript Analogies" makes it to the top on HN.

JulianMorrison 14y ago

C is not C. That is, the C you get out of a language that is doing optimization of high level stuff into legal, portable C as a compile target is not the language you'd use if you, a human, were coding in C. And this is very analogous to, for example, the code generated by a high level language targeting modern JS. It's going to allocate stuff on arrays, and use cryptic pointers, and do things the odd way around when it turns out to be faster. It's going to have unhelpfully named variables, and no unnecessary whitespace or comments, and it's going to operate silently on dangerous-looking assumptions that it's proven safe at a higher level. Sure, generated C interops easily with manual C, just like generated JS interops easily with traditional hand coded JS, but they have little in common except their formal grammar.

ricardobeat 14y ago

I thought this was going to be about Emscripten, asm.js, compiled "desktop languages"? CoffeeScript and other to-js languages are not what people mean when talking "javascript is web assembly".

acqq 14y ago
Exactly. Looks like OP "missed the joke" completely.

United857 14y ago

Well, with the advent of asm.js and various tools like emscripten that compile down to it, perhaps it's a bit more of an apt analogy now.

spacemanaki 14y ago

Previously... https://news.ycombinator.com/item?id=2997952 https://news.ycombinator.com/item?id=2997952

xd 14y ago

Far to many comments are coming across like they where from students fresh out of compilers 101 .. please guys; cool your engines, for the sake of the community.

S4M 14y ago

This is a repost. Comments from the original submission: http://news.ycombinator.com/item?id=2997952 http://news.ycombinator.com/item?id=2997952

r0s 14y ago

> They break almost all of the tooling that exists for JavaScript debugging. I just don't see the utility of pre-processors for JS or CSS. I know I'm in the minority here, are developers really working without debugging? I can't wrap my head around that workflow.

lowboy 14y ago
I code in CoffeeScript a fair bit, and I don't find it's that bad even without source maps[0] because of the similarity between CS source and JS output. I can put in debugger statements and breakpoints just as I would in vanilla JS. [0]: http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...
- codesuela 14y ago
  this, the notion that CoffeeScript generated code resembles some kind of arcane binary like output is wrong. As knowing the basics of JavaScript is pretty much a requirement for working with CoffeScript I never ever encountered any problems when debugging generated code because is not obfuscated and easy to read and the compiler doesn't do anything you didn't specifically write in your CoffeeScript. I am going to go out on a limb here and say that I think compiled CoffeeScript is easier to read then most peoples hand written JS. What makes code unreadable is the Closure compiler which is completely different beast.
papsosouid 14y ago
>I just don't see the utility of pre-processors for JS or CSS. I'm not sure how CSS comes into the discussion, it isn't executed, and thus isn't debugged. And things like SASS and LESS are fairly simple, straightforward pre-processors. >I know I'm in the minority here, are developers really working without debugging? I don't think so. You couldn't pay me enough to write javascript. But I have to end up with some javascript because browsers don't support anything reasonable. So I use a haskell -> javascript compiler. I still have to read javascript to debug what is going wrong, but at least I don't have to write it.

pan69 14y ago

The author of this post misses the point of the expression completely. The expression has nothing to do with assembly language but it has to do with the fact that Javascript will be further and further abstracted away over time but yet, all these abstractions will compile down to Javascript. In due time no one will be programming in Javascript except for a few geeks. This is similar to what happened to assembly language and in that way Javascript compares to assembly language.

samatman 14y ago
That seems like an odd prediction to make for an expressive, dynamic, C-like language. It's nice to have other options, but I suspect that large amounts of vanilla Javascript will be written for many years to come.
- pan69 14y ago
  I'm sure that in the late 70's or early 80's people said the same thing about assembly language and guess what, even today there are still people programming in assembly. The point is that languages change faster than the platforms they run on. Why else would there be CoffeeScript or Haxe? It's just a natural evolution. To us Javascript might seem perfectly acceptable as a programming language but only time will tell if the next generation of programmers will feel the same about that.
  - fusiongyro 14y ago
    Yes, but they also said that about SQL, starting in the 90s. The more high-level the thing you're trying to hide is, the more likely it'll keep peeking out from underneath your abstraction layer.
spinlock 14y ago
Do you know who made the original comparison? It seems like the context of the statement is the only way to groc the semantics.

podperson 14y ago

> If you are designing a language, compiling it to JavaScript is a pretty attractive option, for much the same reason that compiling C to machine code is an attractive option: running it in more places. This sentence badly written. The point of the article is that Javascript is the C of the web, and if this sentence were put together correctly it would make the point.

tlrobinson 14y ago

He seems to be offended by people comparing JavaScript to assembly, but when people say "JavaScript is web assembly" they're usually making a specific point about how you can write languages that compile to JavaScript, not an overall judgement of the language. Of course JavaScript has more in common with C than assembly, but context matters.

stcredzero 14y ago

"JavaScript is web assembly" is actually a bastardization of "JS is web bytecode." And really, that's just shortcut for saying it's the closest thing we have, but in many cases, it's good enough and it's certainly better than nothing.

frozenport 14y ago

Maybe its the LLVM of the web?

justizin 14y ago

This would be a lot more interesting if any of the conclusions it draws were remotely cogent, except that JavaScript is Not Web Assembly, and that it is (kind of) like C. The to-JS languages are nothing like C++, you just don't need to compare in this way, these things are apples and oranges. The JVM is more like the assembly target of the web, and it's a horrid failure in security and stability. Maybe some folks should start anew with something like LLVM as a target, with the first conversations about security. That would probably suck too, though. Things don't have to be the Things of Things. That's what we should take away from this.

namank 14y ago

Umm...ok. So what is the assembly of the web? I feel like the author should be given a lesson in rhetoric.

jmspring 14y ago

First, everything needed to run on the JVM. Now, everything must compile down to javascript and run in the JS vm. The cycle will continue.

ahoge 14y ago

"JS is the crappy ill-suited compiler target everyone is forced to use." Now, if you say instead that it's low-level ("assembly"), fans of JS feel smug about using it instead of being offended. However, at the same time you hint that JS is something which shouldn't be written by humans.

aaronbrethorst 14y ago

"CoffeeScript may require fewer tokens, sure, but not 10 to 1 fewer." True, but I find that its real power is in not forcing me to remember all sorts of crazy-ass stuff that's only relevant because JavaScript, as a language, is just sort of batshit crazy. Case in point: I'm doing some work right now that requires me to use JavaScript[1]. Today, I was writing your typical 'is this variable undefined or not?' if-clauses: if (typeof foo !== 'undefined') { bar(); } Obviously, I don't do this enough, because I ended up having to look the stupid thing up instead of just knowing it ("I know I have to use === for equality; is the equivalent 'not-equals' version only two equals signs or three?", and so forth). In CoffeeScript, in comparison, I'd simply write: bar() if not foo? It takes a lot less mental energy for me to remember the second version than the first. Also, if I had a nickel for every time I've had to write var that = this... Anyway, suffice it to say that CoffeeScript may not be an order of magnitude more expressive, but it's cheap enough to get up and running that its benefits are well, well worth it to me. [1] It's an iOS app that has a critical component built into a UIWebView, and there is absolutely no way to make this stuff native, seeing how it's rendering HTML. I guess I could rig up some awful build phase voodoo that would compile my .coffee files, but that sounds ridiculous.

firlefans 14y ago

The author claims that C has "an order of magnitude more expressiveness" than assembly with no basis for the statement, but ok. He then throws all the "compile-to-JS" languages together even specifically mentioning Sibilant which has macros. If there is another 10x expressivity gain to be had by adding any language feature then surely macros are it.

lucian303 14y ago

Absolutely. People who add complexity to software development neeclessly have it completely backwards.

bjhoops1 14y ago

document.getElementsByTagName("body")[0].innerHTML.replace(/metaphor/gi,"simile");