6 ms·

No, it's not, and it's certainly not OK. Javascript is a quirky interpreted scripting language created for scripting minor workflow events. It's an afterthought

No, it's not, and it's certainly not OK. Javascript is a quirky interpreted scripting language created for scripting minor workflow events. It's an afterthought by Netscape, duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure. asm.js is one more hack on top of the mess, and while it's technically interesting, and probably very useful (much like the rest of javascript), we shouldn't be building these monstrous feats of engineering on top of such shaky foundations. > there's only one language that works everywhere without installation or trouble and that's JavaScript. This is true. But we've arrived at this situation virtually by chance, and it's a huge mess and we shouldn't be readily accepting it. We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. NaCl seems to be the furthest down the road to this objective so far.

_pmf_ 13y ago
Concise and correct; there's really not much more to say on this topic.
- deleted 13y ago
  [deleted]
tg3 13y ago
Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language, that has many benefits over contemporary languages, regardless of setting. Yes, it has quirks, and yes, there are some things that coming from another language are difficult to grasp, but it is not a Bad Language. The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser. Asm.js is not a "hack on the top of the mess", it's a simplification of "the mess" down to it's simplest, most bytecode-esque parts. And it's performance is shockingly close to Native. Javascript is not the perfect bytecode for the web. But it does work as a bytecode for the web, and with asm.js, it seems that it works decently well. I think efforts are better spent improving Javascript, asm.js, and languages that can target it rather than swimming upstream.
- Herald_MJ 13y ago
  > Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today. It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages. Why anyone thinks server-side javascript is a good idea is beyond me.
  - marknutter 13y ago
    > Why anyone thinks server-side javascript is a good idea is beyond me. That someone would want to use the same language to write both their client and server side code is beyond you?
    - Herald_MJ 13y ago
      When that language is javascript, yes.
      - mwcampbell 13y ago
        Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.
        Herald_MJ 13y ago
        I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries). My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.
johnpmayer 13y ago
> We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. We had one. It was called Java. Actually, we still have it, but it just has such a bad reputation now; users don't trust it because of "security" and developers don't trust it because of "public static cruft()" and "Oracle". But it is still quite capable. Did anyone else first play minecraft in a web applet? It worked incredibly well for me. So I argue that we do have a viable bytecode, we're just ignoring it.
- mwcampbell 13y ago
  Java is not vendor-neutral as JS is. That makes JS better.
  - winter_blue 13y ago
    Not necessarily. Not having a single (hopefully benevolent) entity control a platform means poor standardization -- which leads --> to vendor-specific variants - and voila, you get to the HTML/JS mess that we have today.
- pekk 13y ago
  The experience sucks beyond compare, always has, and blaming the user isn't going to solve that. You have to download a separate plugin with stupid ads in it. If your version is wrong, it won't work or it won't work right. A number of things won't work unless you use the one from Oracle. If you are lucky, a little tray reminder obtrusively harasses you every few weeks to update to a new version. If you don't, you have to worry about unpatched vulnerabilities. Now you come across a page with an applet in it. This applet stuck inside a little rectangle on the page takes a few seconds to kick off at all. Most of the time it looks terrible once it's up. It isn't at all uncommon that it crashes. Many people have experienced this bringing down the browser or even hanging the computer, which is especially awesome when you didn't even ask for the thing to run. This isn't a matter of the users being stupid and not knowing what's good. This isn't good. It has never been good.
  - deleted 13y ago
hosay123 13y ago
> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today. Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.
- PaperclipTaken 13y ago
  Often times, there is enough reason to start over. With computer architectures, this has the risk of making every single existing operating system obsolete on your architecture. If you are planning on hitting a sales volume equivalent to amd64 sales, you can't just start over. Javascript is a different beast. By building Dart into your webrowser, you don't break the web browser. And while starting over will be an uphill battle, you can address much of the sillyness that holds javascript back and complicates it. Perhaps we have hit the limit of practical additions to javascript. The post yesterday showed that asm.js isn't actually faster unless your browser actually supports the optimizations, which makes popularizing optimized asm.js almost as difficult as popularizing Dart. I don't want to be using technology in 40 years that is built upon technology from 40 years ago. At some point we should reset, even the difficult technologies like amd64. How often is not a question I'm qualified to answer but it should happen.
- deleted 13y ago
  [deleted]
- winter_blue 13y ago
  > By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al. LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is. > last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures. So I think the parent poster was right in what he/she said.
fetbaffe 13y ago
JavaScript is successful because it is a hack in it's very core.
espadrine 13y ago
Can't wait to see the rebirth of Java^W NaCl applets. Seriously, though, if you never see the underlying JS, if you code and debug everything in your preferred language and the result is fast, why would you care what your program compiles to? Nobody objects to having their programs compile to PE on Windows, nobody requires Microsoft to use ELF or Mach-O instead! Even though, nowadays, PE is a bunch of pieces of cloth sewed together, nobody cares as long as it works!
mwcampbell 13y ago
Don't despise modest beginnings or sloppy evolution. Sloppy evolution from a very modest beginning has achieved things that we haven't yet come close to matching through deliberate design, such as our own species. And it does this by always taking the next incremental step from what it has, with no regard for the greater elegance of some hypothetical master plan.
- pekk 13y ago
  And yet if we had to either write in or compile all our code down to QBasic in order to make web apps, we would be justified in complaining about that.
  - mwcampbell 13y ago
    A BASIC descendant (VBScript) very nearly did become the scripting language of the Web. If it had gone that way, I'd like to think that I would tolerate it and write useful apps with it, as long as it didn't mean that Microsoft would have lasting control over the spread and evolution of the Web platform.
rmrfrmrf 13y ago
No. If I want byte code, I'll use Java or a native app. This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop. JavaScript is not a bad language. If you're getting caught up in gotchas and 'quirky' behavior, why not just read EMCA-262 [1] ? It lays out all defined behavior of JavaScript so you'll know exactly what the interpreter is doing when it reads your code. [1] http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST...
- mwcampbell 13y ago
  > This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop. Why? The Web platform is the only non-proprietary platform that has serious market-share among end-users and mind-share among developers. Therefore, it's the only thing that has a serious chance of ending the dominance of proprietary platforms. IMO, that goal is important enough to override any aesthetic concerns that we developers might have.
  - rmrfrmrf 13y ago
    > it's the only thing that has a serious chance of ending the dominance of proprietary platforms. That has never been the end goal for HTTP or even the WWW. Furthermore, we have proprietary web platforms today: just look at Facebook, Google+, Twitter, etc. It's in fact MORE fragmented than the OS market is right now. I mean, think about it: if you were trying to design a portable OS-as-a-service, would you REALLY be using a stateless protocol like HTTP for it? We've done a pretty good job of hacking together ways to maintain state over multiple requests, but the fact of the matter is that it's 100% garbage overhead that wouldn't exist at all if we just used a stateful protocol in the first place!
pjmlp 13y ago
It is no different than targeting C.

_pmf_ 13y ago

Concise and correct; there's really not much more to say on this topic.

deleted 13y ago
[deleted]

tg3 13y ago

Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language, that has many benefits over contemporary languages, regardless of setting. Yes, it has quirks, and yes, there are some things that coming from another language are difficult to grasp, but it is not a Bad Language. The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser. Asm.js is not a "hack on the top of the mess", it's a simplification of "the mess" down to it's simplest, most bytecode-esque parts. And it's performance is shockingly close to Native. Javascript is not the perfect bytecode for the web. But it does work as a bytecode for the web, and with asm.js, it seems that it works decently well. I think efforts are better spent improving Javascript, asm.js, and languages that can target it rather than swimming upstream.

Herald_MJ 13y ago
> Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today. It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages. Why anyone thinks server-side javascript is a good idea is beyond me.
- marknutter 13y ago
  > Why anyone thinks server-side javascript is a good idea is beyond me. That someone would want to use the same language to write both their client and server side code is beyond you?
  - Herald_MJ 13y ago
    When that language is javascript, yes.
    - mwcampbell 13y ago
      Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.
      - Herald_MJ 13y ago
        I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries). My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.

johnpmayer 13y ago

> We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. We had one. It was called Java. Actually, we still have it, but it just has such a bad reputation now; users don't trust it because of "security" and developers don't trust it because of "public static cruft()" and "Oracle". But it is still quite capable. Did anyone else first play minecraft in a web applet? It worked incredibly well for me. So I argue that we do have a viable bytecode, we're just ignoring it.

mwcampbell 13y ago
Java is not vendor-neutral as JS is. That makes JS better.
- winter_blue 13y ago
  Not necessarily. Not having a single (hopefully benevolent) entity control a platform means poor standardization -- which leads --> to vendor-specific variants - and voila, you get to the HTML/JS mess that we have today.
pekk 13y ago
The experience sucks beyond compare, always has, and blaming the user isn't going to solve that. You have to download a separate plugin with stupid ads in it. If your version is wrong, it won't work or it won't work right. A number of things won't work unless you use the one from Oracle. If you are lucky, a little tray reminder obtrusively harasses you every few weeks to update to a new version. If you don't, you have to worry about unpatched vulnerabilities. Now you come across a page with an applet in it. This applet stuck inside a little rectangle on the page takes a few seconds to kick off at all. Most of the time it looks terrible once it's up. It isn't at all uncommon that it crashes. Many people have experienced this bringing down the browser or even hanging the computer, which is especially awesome when you didn't even ask for the thing to run. This isn't a matter of the users being stupid and not knowing what's good. This isn't good. It has never been good.
- deleted 13y ago

hosay123 13y ago

> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today. Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.

PaperclipTaken 13y ago
Often times, there is enough reason to start over. With computer architectures, this has the risk of making every single existing operating system obsolete on your architecture. If you are planning on hitting a sales volume equivalent to amd64 sales, you can't just start over. Javascript is a different beast. By building Dart into your webrowser, you don't break the web browser. And while starting over will be an uphill battle, you can address much of the sillyness that holds javascript back and complicates it. Perhaps we have hit the limit of practical additions to javascript. The post yesterday showed that asm.js isn't actually faster unless your browser actually supports the optimizations, which makes popularizing optimized asm.js almost as difficult as popularizing Dart. I don't want to be using technology in 40 years that is built upon technology from 40 years ago. At some point we should reset, even the difficult technologies like amd64. How often is not a question I'm qualified to answer but it should happen.
deleted 13y ago
[deleted]
winter_blue 13y ago
> By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al. LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is. > last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures. So I think the parent poster was right in what he/she said.

fetbaffe 13y ago

JavaScript is successful because it is a hack in it's very core.

espadrine 13y ago

Can't wait to see the rebirth of Java^W NaCl applets. Seriously, though, if you never see the underlying JS, if you code and debug everything in your preferred language and the result is fast, why would you care what your program compiles to? Nobody objects to having their programs compile to PE on Windows, nobody requires Microsoft to use ELF or Mach-O instead! Even though, nowadays, PE is a bunch of pieces of cloth sewed together, nobody cares as long as it works!

mwcampbell 13y ago

Don't despise modest beginnings or sloppy evolution. Sloppy evolution from a very modest beginning has achieved things that we haven't yet come close to matching through deliberate design, such as our own species. And it does this by always taking the next incremental step from what it has, with no regard for the greater elegance of some hypothetical master plan.

pekk 13y ago
And yet if we had to either write in or compile all our code down to QBasic in order to make web apps, we would be justified in complaining about that.
- mwcampbell 13y ago
  A BASIC descendant (VBScript) very nearly did become the scripting language of the Web. If it had gone that way, I'd like to think that I would tolerate it and write useful apps with it, as long as it didn't mean that Microsoft would have lasting control over the spread and evolution of the Web platform.

rmrfrmrf 13y ago

No. If I want byte code, I'll use Java or a native app. This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop. JavaScript is not a bad language. If you're getting caught up in gotchas and 'quirky' behavior, why not just read EMCA-262 [1] ? It lays out all defined behavior of JavaScript so you'll know exactly what the interpreter is doing when it reads your code. [1] http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST...

mwcampbell 13y ago
> This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop. Why? The Web platform is the only non-proprietary platform that has serious market-share among end-users and mind-share among developers. Therefore, it's the only thing that has a serious chance of ending the dominance of proprietary platforms. IMO, that goal is important enough to override any aesthetic concerns that we developers might have.
- rmrfrmrf 13y ago
  > it's the only thing that has a serious chance of ending the dominance of proprietary platforms. That has never been the end goal for HTTP or even the WWW. Furthermore, we have proprietary web platforms today: just look at Facebook, Google+, Twitter, etc. It's in fact MORE fragmented than the OS market is right now. I mean, think about it: if you were trying to design a portable OS-as-a-service, would you REALLY be using a stateless protocol like HTTP for it? We've done a pretty good job of hacking together ways to maintain state over multiple requests, but the fact of the matter is that it's 100% garbage overhead that wouldn't exist at all if we just used a stateful protocol in the first place!

pjmlp 13y ago

It is no different than targeting C.