I am wondering what would look like Javascript would look like if it was built from the ground to be the ASM of browser languages.
The State of JavaScript - Brendan Eich
111–120 of 266 posts
Re: The State of JavaScript - Brendan Eich
#112Earlier quoted context omitted.
As it should be, until the implementation settles and it's clear what interfaces should be standardized. I believe Brendan Eich is suggesting that the preferred process is for a technology to be defined by a draft of a spec, and have multiple implementations' interfaces settle down before being standardized, rather than having one definitive implementation that unilaterally determines what is settled down and what is…
I've seen it too from multiple people, and I don't think it's hyperbole to call it propaganda. We had a representative from the Mozilla foundation speaking at our local Js conference and I asked him if the situation with NaCl w.r.t. Firefox was because no one has implemented it or because Mozilla is "morally" against it. He answered that Mozilla is categorically against the idea of NaCl.
Mozilla is categorically against the idea of NaCl, yes. Because it's tied to particular hardware.
PNaCl, if it ever happens, will be a separate discussion.
Re: The State of JavaScript - Brendan Eich
#113> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…
Taking your points one at a time:
1) If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited.
2) Google is opposed to anyone else being more involved in the process. Other people have tried.
3) Mozilla has no particular concerns about "losing face" if a pragmatic decision is needed. We're a lot more worried about consequences for users and the web than we are about our egos or "face".
4) Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth. Granted, the source is open, but again it's tied to various Chrome-specific stuff that is underspecified and would be incredibly difficult to integrate into any other browser.
Basically, as far as I can tell your argument comes down to saying that Mozilla should be open to implement PNaCl (not NaCl), if it were being developed completely differently and had different goals. We might be, if that counterfactual held. But it sure doesn't, and I don't see any hope of it holding. If that ever _does_ happen, we can revisit this discussion, of course.
Re: The State of JavaScript - Brendan Eich
#114Aside from my personal distaste for his backing up the semantic truck and dumping it into ES6, I think it's a bit annoying -- to the point of being disrespectful -- that Brendan doesn't mention V8 in his history of JavaScript. Without V8, there is no JavaScript on the server-side (sorry, Rhino and SpiderMonkey), there is no Chakra and there is no TraceMonkey/JagerMonkey/IonMonkey: given that JavaScript had survived f…
> Without V8, there is no JavaScript on the server-side The first implementation of server side Javascript was nearly 20 years ago: http://en.wikipedia.org/wiki/JavaScript#Server-side_JavaScri... Naturally, it was never all that popular, but... it has been around.
I maintained an app using Netscape's LiveWire 12 years ago. Had that project been free (as in beer) I think it could have seen pretty good adoption.
Re: The State of JavaScript - Brendan Eich
#115Earlier quoted context omitted.
See Xax for another approach. The issue here is that NaCl and Xax are proprietary approaches done inside companies coupled very tightly with existing ISAs and not developed entirely in the open. They are both brittle with their own particular weaknesses - NaCl is weak at handling dynamically generated code, and Xax has safety issues (there are user mode instruction sequences that can freeze some x86). PCC may be clev…
> The issue here is that NaCl and Xax are proprietary approaches If you had told me in the 90s when Microsoft was king that someday "proprietary" would be used to describe a completely open-source, documented, published technology that its creator encourages others to adopt, I would have laughed and said it's impossible. > NaCl is weak at handling dynamically generated code They got it working for x86 ( http://static…
"proprietary" is a spectrum, not a binary decision.
You can be open-source, documented (though NaCl is not so documented in practice because of the Pepper dependencies), published, and encouraged to adopt, but if your development is controlled completely by a single company and if you depend on other, undocumented, parts of that company's software stack, then you are more proprietary than something with an open (as in, developed in the open, with many participants) standard and no dependencies on a particular implementation.
Obviously you'd be less proprietary than, say, ActiveX, but that's a pretty low bar nowadays. NaCl is not competing against ActiveX; it's competing against the web platform as it exists. And that's definitely much less proprietary than NaCl.
Re: The State of JavaScript - Brendan Eich
#116Earlier quoted context omitted.
> It's highly unlikely that JavaScript spit out by a code generator (this would be the competition for NaCl) is going to be at all readable. With SourceMaps it's possible to make them readable[1]. Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE. [1] - https://wiki…
There's audio processing stuff that I'd love to do in web browsers, but I refuse to touch Javascript with a ten-foot pole. I am the kind of person that would like NaCl to be adopted outside of Chrome. If you are the kind of person that is more interested in building the "app" part of some application of that kind of program, you have nothing to fear from NaCl -- just think of it as opening up the "standard native cod…
> but I refuse to touch Javascript with a ten-foot pole.
Why? Honest question here: what are the problems that are making you unwilling to even try it? Is performance the main problem?
> just think of it as opening up the "standard native code"
As long as the browser is running on a small set of target hardware architectures. And everyone else gets locked out, right?
If PNaCl ever happens, that might change, but at the moment that's how NaCl works: you tie your "web page" to a particular set of hardware architectures when you use it.
Re: The State of JavaScript - Brendan Eich
#117> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…
PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format.
PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified nowhere and implemented only in chromium.org code.
To say this is "Open Technology" is to reduce "Open" to the level of "Big company Big Bucks Open-washing." There is nothing open about an unspecified research project without a proven multi-party governance structure that's dominated from start to finish by Google, and which only Google could afford to staff and push -- including via big-money distribution deals with game developers and distributors.
As I said at Strange Loop and in past talks, don't shoot the messenger: Microsoft and Apple will never adopt NaCl/Pepper. It is a non-starter as a web standard.
Why pray tell should Mozilla fall on Google's sword here? Why should we beg to be involved more "in the process" years after it started? Who are you to say that NaCl/Pepper is better for developers or anyone else than a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)
NaCl/Pepper looks like an incumbent power's technological folly, similar to Microsoft Active X or Google's Dart-as-a-native-VM. Just because a big company can pay for it does not make it "Open" or "Good" or good for the web.
You've been free with charges of dishonesty, but I'll refrain from drawing conclusions about you from your position except to say that what you write is astoundingly naive -- at best. For anyone building a competitive browser that is not Chrome or chromium-based, what you propose is a money pit in direct and opportunity costs, with no clear path to standardization, where Firefox would always be behind in "Pepper conformance" compared to Chrome. The answer is no.
You'll get the same answer from any other browser vendor not free-riding off of chromium/Google.
Re: The State of JavaScript - Brendan Eich
#118Earlier quoted context omitted.
Edit: Actually, I just realized I'm off here. The June 2009 release of FF was a final release, while the September 2008 release of Chrome was a beta. From what I can tell, though, the beta release of TraceMonkey was a day after the beta release of Chrome. >TraceMonkey shipped before v8 did. No, that's not true. TraceMonkey shipped in June 2009 with FF 3.5. V8 shipped with the first release of Chrome in September 2008…
I was going by this blog post from Brendan Eich: https://brendaneich.com/2011/06/new-javascript-engine-module... Where he says "[...] TraceMonkey, which we launched ahead of Chrome and V8". Maybe "shipped" was the wrong word. I suppose there's some definition of "launched" that makes the statement true; tracemonkey landed, and was announced, in August 2008. But you're right, the Chrome beta (Sept. 2, 2008 according t…
TraceMonkey was announced on 2008-08-23, after 2 months of development[1].
V8 had its first public release together with Chrome 2008-09-02 as you already mentioned, but development appears to have started in 2006 according to some of the copyright notes in the initial SVN export[2].
[1] https://brendaneich.com/2008/08/tracemonkey-javascript-light...
Re: The State of JavaScript - Brendan Eich
#119I would really like support for 64-bit integers and native 64-bit math.
There are some proposals to make this happen... They're all in pretty early stages, sadly.
Re: The State of JavaScript - Brendan Eich
#120Overall pretty impressive feature list. I guess proxy is intended for the monkey patch crowd.
Or for anyone who wants to implement a DOM in JS, say. Or a security membrane (Caja, say). There are a bunch of other use cases too...