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

51–60 of 266 posts

Re: The State of JavaScript - Brendan Eich

#51

Post by anil_mamede »

skyhook_mockups wrote: post #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 futur…

But without an ecosystem of frameworks like OSX or .NET, it will be difficult to develop apps with good and consistent experience.

Re: The State of JavaScript - Brendan Eich

#52

Post by laughinghan »

skyhook_mockups wrote: post #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 futur…

I'm honestly surprised he didn't mention Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript. http://www.codinghorror.com/blog/2009/08/all-programming-is-...

The crux of the argument is, "As a software developer, I am happiest writing software that gets used. What's the point of all this craftsmanship if your software ends up locked away in a binary executable, which has to be purchased and licensed and shipped and downloaded and installed and maintained and upgraded? With all those old, traditional barriers between programmers and users, it's a wonder the software industry managed to exist at all. But in the brave new world of web applications, those limitations fall away. There are no boundaries. Software can be everywhere."

Re: The State of JavaScript - Brendan Eich

#53

Post by skyhook_mockups »

anil_mamede wrote: post #51
skyhook_mockups wrote: post #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 futur…

But without an ecosystem of frameworks like OSX or .NET, it will be difficult to develop apps with good and consistent experience.

Thats another Then... you could add

  - Then they said it didn't have an ecosystem of frameworks like OSX or .NET
the frameworks will come. It's undeniable that the web, and tooling surrounding it is reaching critical mass.

Re: The State of JavaScript - Brendan Eich

#54

Post by lmm »

laughinghan wrote: post #48
haberman wrote: post #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 st…

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 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 isn't.

As in, Mozilla would implement a common core of NaCL features, perhaps omitting some of the less-core ones that Chrome has, and adding their own extensions, and they could see what was good and what was bad, and experimental features could gradually become part of the standard? Sure, sounds good.

But for google to try and define a standard when they only have the only one immature implementation would just be stupid.

Re: The State of JavaScript - Brendan Eich

#55

Post by masklinn »

eranation wrote: post #23
bcantrill wrote: post #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 f…

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)

> I wonder what he would have said about TypeScript

Likely nothing. The presentation has a slide on compiled-to-JS languages, and a link to a listing site. Eich doesn't seem to mind languages compiled to JS so far.

Re: The State of JavaScript - Brendan Eich

#56

Post by masklinn »

stevekinney wrote: post #49
surrealize wrote: post #44

What's the compile-to-JS language mentioned on http://brendaneich.github.com/Strange-Loop-2012/#/22 with the lambda-in-yin/yang logo? It mentions macros, but nothing on the altjs.org front page mentions macros.

That's Clojure (or—in this case—ClojureScript, which compiles down to JavaScript), which is a Lisp derivative that runs on the JVM. http://clojure.org

And https://github.com/clojure/clojurescript/wiki for the ClojureScript site-ish.

Re: The State of JavaScript - Brendan Eich

#57

Post by masklinn »

alexfarran wrote: post #50
surrealize wrote: post #44

What's the compile-to-JS language mentioned on http://brendaneich.github.com/Strange-Loop-2012/#/22 with the lambda-in-yin/yang logo? It mentions macros, but nothing on the altjs.org front page mentions macros.

ClojureScript a Clojure to JS compiler.

ClojureScript is really defined as a Clojure dialect, it has semantic differences from the "main" Clojure and is a slightly different languages (in part because features are missing from CS, in other parts because things were changed to work better and may or may not be folded back into Clojure).

ClojureScript macros are written in Clojure though.

Re: The State of JavaScript - Brendan Eich

#58

Post by masklinn »

rorrr wrote: post #38

What's the point of "Map" and "Set" in Javascript? Objects can already act like either.

* Objects as maps have limitations: only string keys, and literal objects have a prototype so you inherit potentially risky properties/behaviors

* Objects as sets are kinda terrible, they're not syntactically awesome and you need to override #toString to make them work correctly. They also don't support any set operation which sucks.

Re: The State of JavaScript - Brendan Eich

#60

Post by hermanhermitage »

haberman wrote: post #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 st…

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 clever, but the fact remains less effort would be required to add sandboxing of processes and peons and yield higher performance.

PNaCl from what I recall relies on LLVM which is yet to demonstrate low latency code generation performance - in contrast to older more mature code generators such as TAOS, LuaJit.

Don't get me wrong, I am in favour of a WebCPU component for low latency, near native code emission and execution. I just don't think those with the pedigree are doing the work.

Post reply on HN