Live data from Hacker News

The State of JavaScript - Brendan Eich

brendaneich.github.com

71–80 of 266 posts

Re: The State of JavaScript - Brendan Eich

#71

Earlier quoted context omitted.

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.

Yeah and we'll probably only have to wait another 5 years!

It's funny how .NET languages can have a consistent, predictable and precision framework built up around them and yet somehow we're supposed to believe that JS is better than bytecode.

Re: The State of JavaScript - Brendan Eich

#72

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

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.

It's rather easy to make minimized JavaScript readable again though. For example, Chrome's Web Developer Tools have such feature built-in.

Re: The State of JavaScript - Brendan Eich

#73
post #5

Earlier quoted context omitted.

I just used the mouse wheel and it always went the right order, even if vertical.

Same, but it still seems unintuitive and pointless. Why not just keep them going from left to right? I'm pretty sure the target audience for this only really cares about the content and anything else just gets in the way.

Personally I use it to map my presentation into chapters. It allows me to better know where I'm at while presenting, and allows people reading my slides to get an idea of how it's laid out inside my brain.

It was just used by a colleague to organise his slides into:

Topic ▼ Code example ▼ What that code renders into

The last slide was actually rendered live from the slide before it. Absolutely badass.

Re: The State of JavaScript - Brendan Eich

#75
Need some advice here. I want to learn JavaScript -- but after reading all that, I wonder if all those changes/additions means that I should wait? Or will learning JavaScript now make little difference and all those changes/additions will make sense when enacted?

Re: The State of JavaScript - Brendan Eich

#77

Need some advice here. I want to learn JavaScript -- but after reading all that, I wonder if all those changes/additions means that I should wait? Or will learning JavaScript now make little difference and all those changes/additions will make sense when enacted?

Don't wait. First, no guarantee that stuff will actually get adopted, it's still quite abstract. Second, even if so, it will take a while for browsers to catch up, so people will be coding in current JS for a while. Third, much of the current conceptual hurdles will still be relevant, particularly functional style and async design patterns.

Would highly recommend Javascript: The Good Parts, don't know where I would be without it.

Re: The State of JavaScript - Brendan Eich

#79
post #66

I would really like support for 64-bit integers and native 64-bit math.

What kind of apps would this help with?

JS is never going to take over on the server for me until it can compete with Python's statistics support, I didn't see much in these slides that suggests it could.

Re: The State of JavaScript - Brendan Eich

#80
post #65

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

I agree ... and I'll extend it by asking why you'd "dis" the other languages he attacks. Once again the old adage is proved: "When all you have is a hammer, everything looks like a nail". Let's get over the JS insecurity, admit it's useful for some tasks and that it sucks for others and get on with some useful discussion about when each of those statements is true.

[deleted]
Post reply on HN