3 ms·

Javascript's absolutely ubiquitous distribution characteristics have resulted in all sorts of irrational behaviour. If the W3C or the browser makers collective

Javascript's absolutely ubiquitous distribution characteristics have resulted in all sorts of irrational behaviour. If the W3C or the browser makers collectively had put some thought into making it possible for other languages to be linked into the client in a sane way (i.e. rather than the existing plugin regime), or defined some proper IL that app authors could compile to, Javascript wouldn't be on its way to being the compilation target for the web.

azakai 16y ago
You make it sound like they were incompetent, lazy or evil. Or perhaps I misunderstood you, sorry if so. But the fact is, they did think a lot about using other languages on the web, and about proper ILs as well. The fact is, there has been no good way to do either, if you want a standards-based platform with multiple compatible implementations. You can take some existing IL like Java bytecode, but (1) that stuff is patented, and (2) there is no hope of cross-vendor agreement on what that IL should be, and all of them have various issues anyhow (for example, Java and .NET bytecode were designed with static languages in mind). JavaScript is winning simply because it's there, it works, and everybody supports it. Yes, it has frustrating limitations, but it's hard to see a practical alternative. We will simply need to overcome those limitations - and that is possible.
- cemerick 16y ago
  That was perhaps a little harsh in the phrasing; I wasn't really implying any of those things. I think I am saying that this appears to have been a blind spot on the part of the web standardization crowd and the browser makers. Maybe I'm entirely wrong though, and there were efforts that simply hit hard problems, as you say. I'd never heard of any discussions around determining a proper IL, though; if you can, a link so relevant MLs and such would be most appreciated.
  - azakai 16y ago
    Here's Brendan Eich (creator of JS) talking about something even simpler, a bytecode standard for JS in browsers, http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122 and here is him talking on HN about JS vs Python, Lua etc. in browsers, http://news.ycombinator.com/item?id=1905155 http://news.ycombinator.com/item?id=1905155
    - cemerick 16y ago
      Many thanks for those. I obviously haven't digested them yet, but I will.
sedachv 16y ago
Why do you insist on an IL? The real reason why JavaScript won out over Java and ActiveX is exactly because it's a programming language and not an IL. Inline JavaScript in HTML pages is the killer feature of JavaScript. From a technical point of view, you also need to think about how scripts interact with other dynamically loaded scripts. That means standardizing on function calling convention, symbol tables, types and object representation. There's no way to solve these things with something like bytecode (which is why there were never any Java applets that load other Java applets), you need a dynamically-typed programming language. So R4RS Scheme may have been a better choice, but that's not what Netscape marketing wanted, so what.

azakai 16y ago

You make it sound like they were incompetent, lazy or evil. Or perhaps I misunderstood you, sorry if so. But the fact is, they did think a lot about using other languages on the web, and about proper ILs as well. The fact is, there has been no good way to do either, if you want a standards-based platform with multiple compatible implementations. You can take some existing IL like Java bytecode, but (1) that stuff is patented, and (2) there is no hope of cross-vendor agreement on what that IL should be, and all of them have various issues anyhow (for example, Java and .NET bytecode were designed with static languages in mind). JavaScript is winning simply because it's there, it works, and everybody supports it. Yes, it has frustrating limitations, but it's hard to see a practical alternative. We will simply need to overcome those limitations - and that is possible.

cemerick 16y ago
That was perhaps a little harsh in the phrasing; I wasn't really implying any of those things. I think I am saying that this appears to have been a blind spot on the part of the web standardization crowd and the browser makers. Maybe I'm entirely wrong though, and there were efforts that simply hit hard problems, as you say. I'd never heard of any discussions around determining a proper IL, though; if you can, a link so relevant MLs and such would be most appreciated.
- azakai 16y ago
  Here's Brendan Eich (creator of JS) talking about something even simpler, a bytecode standard for JS in browsers, http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122 and here is him talking on HN about JS vs Python, Lua etc. in browsers, http://news.ycombinator.com/item?id=1905155 http://news.ycombinator.com/item?id=1905155
  - cemerick 16y ago
    Many thanks for those. I obviously haven't digested them yet, but I will.

sedachv 16y ago

Why do you insist on an IL? The real reason why JavaScript won out over Java and ActiveX is exactly because it's a programming language and not an IL. Inline JavaScript in HTML pages is the killer feature of JavaScript. From a technical point of view, you also need to think about how scripts interact with other dynamically loaded scripts. That means standardizing on function calling convention, symbol tables, types and object representation. There's no way to solve these things with something like bytecode (which is why there were never any Java applets that load other Java applets), you need a dynamically-typed programming language. So R4RS Scheme may have been a better choice, but that's not what Netscape marketing wanted, so what.