Earlier quoted context omitted.
Yes. There's just no substitute for time. It's impressive to see something put together quickly, but the result is inevitably lacking in some (or more) ways. In this talk, I couldn't decide whether his saying JS was written in ten days was a rueful admission that it's only natural for it to be a huge pile of shit, or some self-aggrandizement based on how quickly he managed to write it. I always found JS rather tastel…
Hume's Guillotine slices again! Please think through this keynote at a conference. I was asked to talk about the early days of JS. Why do you suppose that I am aggrandizing by describing "is" (or "was") as if "ought" can be derived in a moral sense? JS happened, I made it in ten days because it wouldn't have happened otherwise. Had I thought it through, I might have insisted on more time -- but then: VBScript. We don…
JavaScript at 20
271–280 of 327 posts
Re: JavaScript at 20
#272Earlier quoted context omitted.
> Man, python on the server and in the browser. What a world that would be. If you're going to imagine that as a utopian alternative to JS, be sure to be thorough about it and imagine 1995 Python dominating the browser landscape for years and then the advancement path the language has taken on the server playing out among several browsers. Then come back and tell everybody how much prettier it looks than JS (for bonu…
> The differences between these languages aren't that big and they're largely aesthetic. They are pretty big. At work I work on a Django-backed project that has a very fat JavaScript front-end client, and JavaScript is incredibly painful to work with compared to Python. It's not merely aesthetics, but JavaScript in the browser is severely lacking in language features that allow it to scale to larger code-bases.
Re: JavaScript at 20
#273Earlier quoted context omitted.
Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have acce…
> I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time. > With the threading issue, Web Workers are boxed up so tightly that t…
I'd say that the weaknesses of web workers is absolutely relevant. Though you see it as protecting the coder from themselves, there are design patterns out there, like publish/subscribe, that are useful in letting threads communicate, but not generating race conditions. DOM access and the like can be done sanely, but Javascript doesn't even give you that option.
Given the reasons described, it's a rather poor compile target. It's a plodding beast of a language that mishandles numbers, requires circuitous coding to handle basic concurrency, and otherwise behaves in ways other languages don't. Transpiling just barely hides its flaws.
I will restate that it is a hack, and a rather ugly one. Its attempts to maintain compatibility leave us with a virtual machine that is increasingly obsolescent. An "assembly language" designed in 2013 shouldn't be lacking support for 64 bit integers (or 8-bit or 16), should have good support for vectorization, and should provide some sort of register and/or stack model so that you can better clue in the vm as to what items are going to be frequently used in functions. The missing features could be handled much like JSON was early in its life, by including a library as a fallback. It would probably end up looking ugly as hell, but at the same time, it would work, and give a lot more long-term benefits.
Regarding alternative languages, Javascript isn't always the best language to describe a problem in. Sometimes your program's better written in C, or Lisp, or Fortran even. Why should you force your problem to fit the language?
Regarding stagnation, you can move quickly, yet not really go anywhere useful. COBOL had 7 major versions and several minor in 14 years. Does it mean that it's a useful language today? The stagnation comes in terms of how people think of problems, and how they try to wedge those problems to fit into Javascript. The web would be a much better place if we allowed more experimentation into languages and behavior.
Re: JavaScript at 20
#274Earlier quoted context omitted.
Chrome was trying to do this: https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.
...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have an active interest in holding back the Web to protect their native app platforms, while one would rather reign in Hell (through its position of shared mastery over the Web hairball) than go broke in Heaven. As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation.
Re: JavaScript at 20
#275Earlier quoted context omitted.
> Man, python on the server and in the browser. What a world that would be. If you're going to imagine that as a utopian alternative to JS, be sure to be thorough about it and imagine 1995 Python dominating the browser landscape for years and then the advancement path the language has taken on the server playing out among several browsers. Then come back and tell everybody how much prettier it looks than JS (for bonu…
> The differences between these languages aren't that big and they're largely aesthetic. They are pretty big. At work I work on a Django-backed project that has a very fat JavaScript front-end client, and JavaScript is incredibly painful to work with compared to Python. It's not merely aesthetics, but JavaScript in the browser is severely lacking in language features that allow it to scale to larger code-bases.
Also JavaScript has a pretty good variety of languages that compile to it. If you like C#/Scala/Swift use TypeScript. If you like Java use Dart. If you like Lisp ClojureScript.
Re: JavaScript at 20
#276Earlier quoted context omitted.
...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
> but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have…
Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.
Re: JavaScript at 20
#277Earlier quoted context omitted.
> but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have…
Nope! (On everything you wrote, including "the" and "and".) Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.
Re: JavaScript at 20
#278Earlier quoted context omitted.
14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond: > asm.js doesn't support threading. asm.js supports threading, actually, through Web Workers and SharedArrayBuffer. > it can't run native code. This is true, but asm.js is relatively close to the metal. It's not very far from assembly language. > it doesn't support meaningful debugging. This is a tooling issue. While the situation is bad…
Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have acce…
Re: JavaScript at 20
#279Earlier quoted context omitted.
Nope! (On everything you wrote, including "the" and "and".) Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.
So that others may judge for themselves: https://news.ycombinator.com/item?id=3092921
My point then was that if Google had had MS's IE4-6-era market share and lack of scruples, they could have pushed Dart into Chrome and started using it in their web properties, and the lack of equivalent performance between DartVM and dart2js -- especially due to lack of bignums and other affordances in JS, which lack Google materially increased by choosing to invest in Dart over JS -- would have stunk. It would have verged on the monopoly abuse of which MS was in fact convicted.
My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote.
Browser vendors have to keep JS improving. That's a given. Adding the extra costs of DartVM and the inter-heap GC and write barriers to glue it into the shared DOM client side is a huge tax, which would have helped kill Mozilla faster. MS and Apple wouldn't pay that tax. Why should anyone? Again it's not about JS being uncompetitive. "Competitive" is what browsers are when they run web content better and faster. Dart has very little to do with this.
JS is very, very hard to replace, for reasons I summed up as "physics" (apologies to Rutherford) and won't belabor here. Yet the Dash memo proposed to do just that, to replace JS, using lame assertions about how JS couldn't be fixed.
That was not just lame posturing and excuse-making for a Lars Bak retention program. Given Google's power, it was a disservice to the Web as a standards-based and ever-evolving platform, whose caretakers are obligated to keep working on it in the open, not try proprietary end-runs. (Yes, of course, many people at Google work hard to improve the Web. Good for them, but not relevant to what happened with Dash.)
I'm happy to say I was wrong to worry about Google succeeding in acting like MS did with ActiveX/VBScript. Not that some at Google didn't try (or won't again with other stuff), but they failed with Dart. I predicted that, too, as an ultimate outcome after wasting years and megabucks -- including real opportunity costs to V8 and JS. So too did many at Google predict this crater.
Dart's a compile-to-JS language now, not due to any preference for JS by anyone at any browser vendor.
Get it yet?
Re: JavaScript at 20
#280Earlier quoted context omitted.
Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not de…
> Works on OSes. We have a choice. The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude. Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js. > Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choic…
Also, the kernel's written in C (maybe Rust in part, soon). So much for language choice!
Sure, in userland, many languages compile to assembly. Hmm, where have I heard that word lately?