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

91–100 of 266 posts

Re: The State of JavaScript - Brendan Eich

#91

Post by nahname »

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…

>Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical scoping.

==, numbers as strings => Problem: Type Coercion eval => Problem: Interpreted Language incorrect definitions of false => Problem: Type Coercion semicolon insertion => Problem: Language improper lexical scoping => Problem: Not block scope?

>The class bit particularly made me sad: JavaScript has a perfectly cromulent, even elegant, object model in the form of prototypes.

Both forms of object creation are valid.

[Object.create] http://jsfiddle.net/X4Bxq/

[new] http://jsfiddle.net/UGTga/

Both take advantage of prototypes (the later takes full advantage today, with all browsers. The former requires a hack where you lose your type information).

What is more important is that they are both awkward. So much so that most "JavaScript" programmers don't even use them. Those that do, spend most of their time arguing on which one is more correct. This is a problem. Introducing 'class' would sort this out by providing an easier syntax for class creation and an end to the arguments.

Re: The State of JavaScript - Brendan Eich

#92

Post by MatthewPhillips »

_urga wrote: post #67
ANTSANTS wrote: post #42

Earlier quoted context omitted.

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…

You're right. Browsers are constraining innovation to a top-down approach, where browser vendors try to design and implement alternatives to things like TCP, POSIX. What would be better is if browser vendors exposed a core low-level API to trusted installed web apps (as opposed to web pages) and then let open source build on that. For example, instead of coding up IndexedDB and leaving no alternative, just provide pr…

How would you expose POSIX on Windows?

Re: The State of JavaScript - Brendan Eich

#93

Post by MatthewPhillips »

cliffbean wrote: post #84
mercurial wrote: post #63

Earlier quoted context omitted.

The "no view source" argument is pretty weak. Most major websites nowadays serve you unreadable compressed JS soup already. Personally, I'd love to have a cross-browser bytecode alternative to Javascript, preferably running in a VM accessible outside of a web browser.

A lot of people say they want a bytecode for the web. The problem is, bytecode vs text is just an encoding issue, and it's practically insignificant. It's a platform either way, and the real issues are what services the platform will provide. For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download,…

People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.

Re: The State of JavaScript - Brendan Eich

#94

Post by MatthewPhillips »

debacle wrote: post #76

The fact is that adding classes to JavaScript fundamentally alters the lispyness of the language in a detrimental fashion. I don't want to see JavaScript turned into Java script.

People already use it as though it had classes, so it makes sense to add the sugar. It will prevent errors such as SomeObject.prototype.foo = {} by not allowing data on the class body.

Re: The State of JavaScript - Brendan Eich

#95

Post by pcwalton »

MatthewPhillips wrote: post #93
cliffbean wrote: post #84

Earlier quoted context omitted.

A lot of people say they want a bytecode for the web. The problem is, bytecode vs text is just an encoding issue, and it's practically insignificant. It's a platform either way, and the real issues are what services the platform will provide. For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download,…

People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.

I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#.

Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all semantics of all programming languages, and I don't believe such a VM can exist anyway.

Re: The State of JavaScript - Brendan Eich

#96

Post by eranation »

mun2mun wrote: post #37
eranation wrote: post #23

Earlier quoted context omitted.

I wonder what he would have said about TypeScript, it seems that it was launch after this conference (though there is a large chance he was in the loop, no pun intended)

He seems ok with it http://twitter.com/BrendanEich/status/254010839701544960

Too bad he wasn't in the loop though, MS could have gained some additional momentum involving him: https://twitter.com/BrendanEich/status/255649668548136960

Re: The State of JavaScript - Brendan Eich

#97

Post by debacle »

MatthewPhillips wrote: post #94
debacle wrote: post #76

The fact is that adding classes to JavaScript fundamentally alters the lispyness of the language in a detrimental fashion. I don't want to see JavaScript turned into Java script.

People already use it as though it had classes, so it makes sense to add the sugar. It will prevent errors such as SomeObject.prototype.foo = {} by not allowing data on the class body.

Some people already use it as though it had classes.

I don't like those people.

Re: The State of JavaScript - Brendan Eich

#98

Post by MatthewPhillips »

pcwalton wrote: post #95
MatthewPhillips wrote: post #93

Earlier quoted context omitted.

People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.

I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#. Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all se…

Not sure about the JVM, but .NET compiles to an intermediate language called CIL before creating the bytecode. I agree with you, but to bytecode advocates, this is an emotional issue. They do not want JavaScript to be the first-class language and their pet language to be "held back" by it.

Re: The State of JavaScript - Brendan Eich

#99

Post by _jmar777 »

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…

I think you're being too hard on JavaScript there. Type coercion, ASI, and function scoping are all language features, not errors. Likewise, eval is not an error; it's dangerous, but it's also a feature (and one that nearly all dynamic/scripted languages provide). As Crockford said, "JavaScript is the only language people feel like they don't need to learn to use." That statement alone describes why so many developers end up scratching their heads at stuff like `1 == "1"`. That's not an error or an oversight in the language - it's a feature that the developer didn't realize he/she was using. It's hard to make it 10 minutes in ANY educational material on JavaScript that doesn't explain equality (==) vs identify (===) comparisons in JavaScript.

Lastly, the new class stuff doesn't actually change the inheritance/object models in JavaScript. It's syntactic sugar on top of prototypes, and the "weird constructor stuff" is quite analogous to existing constructor functions. For example, from the [ecmascript wiki](http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...): "Class declarations/expressions create a constructor function/prototype pair exactly as for function declarations."

I'm clearly a bit of a fanboi and obviously biased, so take all of this with a grain of salt - but most of these new language features are a good thing. I'm glad to see JavaScript evolving in big ways. It was getting boring watching new editions come out with nothing more interesting than Array.prototype.reduce in them. Especially when you consider server-side contexts like Node.js, stuff like typed arrays, generators, Maps, etc. are welcome additions.

Re: The State of JavaScript - Brendan Eich

#100

Post by pcwalton »

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 there, as well as the DOM APIs and so forth. Either you ship two VMs, in which case each page has two incompatible worlds (yet both can access the DOM -- think about the massive complexity this entails), or you have to think about language versioning, which requires at the very least a functioning static module system.

Post reply on HN