Live data from Hacker News

The State of JavaScript - Brendan Eich

brendaneich.github.com

11–20 of 266 posts

Re: The State of JavaScript - Brendan Eich

#11
The last slide was interesting: http://brendaneich.github.com/Strange-Loop-2012/#/50

  - First they said JS couldn't be useful for building 'rich internet apps'
  - Then they said it couldn't be fast
  - Then they said it couldn't be fixed
  - Then it couldn't do multicore/GPU
  - Wrong every time
  - My advise: always bet on JS
It turns out that JS might soon be a mature language which can be used to build real apps. That future has arrived (or at least you can see the train).

es6/7+hardware accelerated graphics+ continued broadband adoption and speed increases (gigabit internet) make the 'web as a platform' dream a reality. I'd love to peek at Microsoft's medium term plan to deal with this.

Also: I wonder how long until we see a full replacement for something like eg:3DSMAX with GUI on the client and rendering done in the 'cloud'?

Re: The State of JavaScript - Brendan Eich

#14
> 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 standardized at this point either.

> No view source.

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. I'm guessing it will be about as readable as the portable BitCode that comprises the PNaCl image (which you could view if you really want to).

It's disappointing to continuously see this anti-NaCl propaganda from Mozilla. Here you have a promising and highly innovative technology that is pushing the bounds of what is possible on the web. It's being developed completely in the open with papers and code being published continuously. Mozilla's mission is "to promote openness, innovation and opportunity on the web." I just can't see what part of that mission involves campaigning against an open technology that could advance the web and help it compete with native apps.

I could understand if their position was "we're reserving judgment until it's portable, stable, and standardized." I could understand "we want to be more involved in the process." I could understand "we are waiting to see if it can demonstrate a compelling advantage over JavaScript." But everything I have heard indicates that they are publicly and completely opposed to ever supporting it, which will make it all the harder for them to ever change their mind on this point without losing face.

I grew up watching Mozilla develop from an unstable binary called "apprunner" into a full-featured open-source browser with cutting edge extension capabilities. I downloaded almost every single milestone and tried it out, craving the day when I could ditch crappy old Netscape 4 for good. I got warm fuzzies when the Mozilla Foundation was created; it felt good knowing that there would always be a way to use the web with open source software, and that there would always be an advocate for openness and freedom. I just never expected to see them fighting against open technology. It's disappointing.

Re: The State of JavaScript - Brendan Eich

#16

The last slide was interesting: http://brendaneich.github.com/Strange-Loop-2012/#/50 - First they said JS couldn't be useful for building 'rich internet apps' - Then they said it couldn't be fast - Then they said it couldn't be fixed - Then it couldn't do multicore/GPU - Wrong every time - My advise: always bet on JS It turns out that JS might soon be a mature language which can be used to build real apps. That futur…

It's disingenuous to claim that javascript is not a "real" language already. This is like claiming that PHP or VB aren't "real" languages. You may not like it, you may think it's missing crucial, key features, but there is a lot of JS code out there in the wild producing value for businesses and customers and generating billions of dollars in revenue.

Edit: looks like I misread the parent post, my apologies.

Re: The State of JavaScript - Brendan Eich

#17
Aside 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 for a decade in its pre-V8 state of abysmal performance, it's entirely reasonable to assume that it would have slept away another decade had it not been jarred out of its slumber by V8. So it would be nice to see some respect where it's clearly due...

Re: The State of JavaScript - Brendan Eich

#18

> 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…

> 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.mozilla.org/DevTools/Features/SourceMap

Re: The State of JavaScript - Brendan Eich

#19

The last slide was interesting: http://brendaneich.github.com/Strange-Loop-2012/#/50 - First they said JS couldn't be useful for building 'rich internet apps' - Then they said it couldn't be fast - Then they said it couldn't be fixed - Then it couldn't do multicore/GPU - Wrong every time - My advise: always bet on JS It turns out that JS might soon be a mature language which can be used to build real apps. That futur…

It's disingenuous to claim that javascript is not a "real" language already. This is like claiming that PHP or VB aren't "real" languages. You may not like it, you may think it's missing crucial, key features, but there is a lot of JS code out there in the wild producing value for businesses and customers and generating billions of dollars in revenue. Edit: looks like I misread the parent post, my apologies.

Looks like I didn't communicate too well. I wholeheartedly agree that JS is a real language. It's my main language and I've written tens of thousands of lines of the stuff. It has it's quirks but I like coding in it. My "JS as a 'real' language" was a tongue-in-cheek go at those who constantly criticise it for being a toy language. I've edited my original comment.

Re: The State of JavaScript - Brendan Eich

#20
post #18

> 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…

> 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…

> 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.

So make a toolchain that runs in the browser. There's nothing stopping you from building NEXE modules at runtime; you could compile LLVM itself for NaCl and embed the whole toolchain in the browser and compile at runtime.

Post reply on HN