Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of JavaScript - Brendan Eich

brendaneich.github.com

Post reply on HN
Print view View original

241–250 of 266 posts

Re: The State of JavaScript - Brendan Eich

#241

Post by haberman »

othermaciej wrote: post #231
BrendanEich wrote: post #226

Earlier quoted context omitted.

The slide I showed is not misleading. NaCl is not portable, PNaCl is still not ready for prime time based on Google's own actions, and you protest too much and do not practice what you preach. "Mozilla" meaning me, bzbarsky, blizzard (previously), roc on the plugin-futures list, others have been forthright compared to the mostly-silent other browser vendors, who haven't even spoken via corporate or individual channel…

I've expressed my personal opinions about NaCl here on HN before too: http://news.ycombinator.com/item?id=2057611

For what it's worth, I think the comment you linked is far more fair and balanced criticism. If all of the statements I was hearing from Mozilla people sounded like that, I would have no beef.

Re: The State of JavaScript - Brendan Eich

#242

Post by gsnedders »

BrendanEich wrote: post #198
cliffbean wrote: post #193

Earlier quoted context omitted.

The link he cited still does apply. It discusses several different issues. PNaCl's portability only covers a subset of them.

Thanks! I happen to agree with with Dan Gohman ( http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... ), but I'm not sure where Chris Lattner ended up on this. Much is possible in software, so perhaps some day, or under some transformation, LLVM bitcode would be suitable as a stable long-term object file format. There's still a point here: PNaCl is pushing a stone up a very tall hill. ANDF and other Univer…

FWIW, the aim for LLVM is to avoid breaking the bitcode format now 3.0 has shipped — not that it's platform independent or anything else yet.

Re: The State of JavaScript - Brendan Eich

#243

Post by gsnedders »

_urga wrote: post #219
gsnedders wrote: post #137

Earlier quoted context omitted.

Because there's more interest in improving the (publicly accessible) web as a platform than improving installed web apps. Regardless, to expose such a low-level API would eliminate one of the big advantages of the web: given a browser, I can use any web app on any device. Given, for example, given a TV (which are typically closed platforms, but increasingly often include a fully featured browser), you likely wouldn't…

No, it would not eliminate the big advantage of the web as you say, merely deepen it. See Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

None of what timbl said in that post (nor what anything, from memory, in that thread said) covered shipping native code to the browser: it was merely talking about privileged web apps, which is a very different problem area (and one that should definitely be explored!).

Re: The State of JavaScript - Brendan Eich

#244

Post by gsnedders »

pcwalton wrote: post #100
SeanLuke wrote: post #86

This presentation saddened me. The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical…

"So they stick to adding lipstick to the pig. But JavaScript isn't like other languages: its fundamental errors are so glaring, and impact so negatively on the language, that the benefit of jumping to a "JavaScript 2.0" massively outweighs its incompatibility disadvantages." "Jumping to a JavaScript 2.0" is the hard part. Any successor to JavaScript has to have a compatibility story with all the JavaScript code out t…

The biggest challenge with multiple VMs is doing GC over both: cross-VM GC is a current research topic, and nothing has shown to be doable without a noticeable perf impact.

Re: The State of JavaScript - Brendan Eich

#245

Post by BrendanEich »

robin_reala wrote: post #228
BrendanEich wrote: post #227

Earlier quoted context omitted.

Why?

House style: http://ycombinator.com/newsguidelines.html Please don't sign comments, especially with your url. They're already signed with your username. If other users want to learn more about you, they can click on it to see your profile.

Ok, sorry about violating house style. Old habits die hard.

Re: The State of JavaScript - Brendan Eich

#246

Post by bzbarsky »

cmccabe wrote: post #221
bzbarsky wrote: post #210

Earlier quoted context omitted.

I think you missed my point. Say you have an open-source project with a single owner, who makes all the decisions about it, and is willing to totally change it around to suit his needs. Would you stake your business on use of that open-source project? Only to the extent that you're sure your needs align with the project owner's. Unless, of course, you're planning to fork anyway. That's where NaCl is at the moment. It…

Let's check wikipedia. "Proprietary software or closed source software is computer software licensed under exclusive legal right of the copyright holder.[1] The licensee is given the right to use the software under certain conditions, while restricted from other uses, such as modification, further distribution, or reverse engineering" Muddying the waters by referring to open source software as proprietary software do…

You're confusing "proprietary software" and "proprietary technology". They're not the same thing.

There are lots of examples of open-source software implementing proprietary technologies of various sorts (example: x264). There are lots of examples of proprietary software implementing open technologies of various sorts (example: Opera).

I'm not talking about the licensing model for the NaCl source code; I'm talking about the openness or not of the entire NaCl technology stack.

As far as folks at Mozilla go, I think they might point you at http://www.readwriteweb.com/archives/how_to_spot_openwashing...

Re: The State of JavaScript - Brendan Eich

#247

Post by nwmcsween »

With regards to the comments here:

I don't think pNaCl could ever happen how do you get an IR general but with enough detail to capture enough information to be able to optimize effectively and without pulling in half of llvm codegen?

The issue isn't a web 'bytecode' the issue is a standardized compiler bytecode.

Also haberman are you still working on the gazelle parser?

Re: The State of JavaScript - Brendan Eich

#248

Post by bzbarsky »

cmccabe wrote: post #222
BrendanEich wrote: post #208

Earlier quoted context omitted.

Rust has a healthy number of committers who are not employed by Mozilla. I will let pcwalton fill in details if necessary. "Proprietary" as in "sole proprietor" is appropriate for a project with zero governance, launched by Google after some incubation closed-source, dominated by Googlers. NaCl is not adopted because it's machine-dependent! PNaCl is not ready . Show me Chrome Web Store games compiled with it and not…

According to the Apache project, a project is "considered to have a diverse community when it is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)." Rust might meet that standard in the future, but it is not there yet. With regard to JavaScript versus NaCl / PNaCl / etc-- I've heard…

There's nothing to "support" yet with PNaCl. It's still at the "we have no idea how to make this work" stage, last I checked.

And if it _could_ be gotten to work, you still haven't addressed why Mozilla should be willing to get on the Pepper "upgrade to keep up with all this unspecified stuff we're changing" treadmill.

It's not just scars from Flash and ActiveX; it's a distinct reluctance to bet everything on a technology you have 0 control over, and which one of your direct competitors controls completely. Now why would Mozilla be hesitant to do that? You tell me.

Re: The State of JavaScript - Brendan Eich

#249

Post by BrendanEich »

haberman wrote: post #241
othermaciej wrote: post #231

Earlier quoted context omitted.

I've expressed my personal opinions about NaCl here on HN before too: http://news.ycombinator.com/item?id=2057611

For what it's worth, I think the comment you linked is far more fair and balanced criticism. If all of the statements I was hearing from Mozilla people sounded like that, I would have no beef.

Maciej and I agree, but you are holding Mozilla to a different standard from Apple. Another reason I'm striving to ignore you (for both our sakes).

Re: The State of JavaScript - Brendan Eich

#250

Post by _urga »

gsnedders wrote: post #243
_urga wrote: post #219

Earlier quoted context omitted.

No, it would not eliminate the big advantage of the web as you say, merely deepen it. See Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

None of what timbl said in that post (nor what anything, from memory, in that thread said) covered shipping native code to the browser: it was merely talking about privileged web apps, which is a very different problem area (and one that should definitely be explored!).

Yes, my comment was concerning the top-down approach taken by browser vendors, and that web apps need to be empowered with low-level APIs such as TCP and POSIX. I don't think I said or TBL said that we need to ship native code to browsers to do this. We don't. We don't need another language. Javascript is fine. We do need better low-level APIs. We do need to get away from relying on browser vendors to spec and implement everything correctly, because with such a massive surface like they're targeting they won't. We do need to push this responsibility out to the edges. We need to drastically reduce the standard API and move the functionality from high level (as in IndexedDB) to low level (as in POSIX). We need a strong powerful stable small core and OSS must do the rest. That's the general idea. The finer details can be nitpicked and that won't invalidate the general idea. Browser vendors are simply doing way too much.
Post reply on HN