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

JavaScript at 20

brendaneich.github.io

Post reply on HN
Print view View original

141–150 of 327 posts

Re: JavaScript at 20

#141

Post by nemo1618 »

untog wrote: post #15
collyw wrote: post #14

Earlier quoted context omitted.

JavaScript is further from an ideal language than many out there.

It isn't, because there is no ideal language. Seriously. Even if there was the goalposts would keep moving anyway as things like functional programming get more popular. My ideal language is one that I can use as often as possible in as many different contexts as possible. JavaScript is alright for that.

I think the ideal would be closer to the asm.js side of things than the JS side. It's nice that I can inspect the source of any page and read high-level code, but the tradeoffs aren't worth it anymore. I'd much rather have a generic (and FAST!) low-level language with lots of compilers from/to high-level languages. We sort-of have that today, with languages that compile to JS, but the reality is that 90% of the time you're going to be writing JS, or at least dealing with it. And personally I'd like to avoid that as much as possible.

Re: JavaScript at 20

#142

Post by M2Ys4U »

frik wrote: post #122

Edit2: When do you switch off your transpiler and serve native ES6? In 2020? Original: What do you do in 2017? What if you already code in ES6 and transpile it to JS5 at the moment. Do you simply switch from serving JS5 to JS6? Older browsers (todays current browser) don't support "class", "let" and other new syntax constructs. The just fail with JS errors. Can one browse the web with IE11 and iOS 8 Safari in 2017? (…

You can transpile from ES2015/16 (ES6/7) to ES5 code today. Babel[0] (formerly 6to5) is one such tool that will do just that.

[0] https://babeljs.io/

Re: JavaScript at 20

#143

Post by zastavka »

wppick wrote: post #121

Can someone explain the isNaN part of this slide: http://brendaneich.github.io/ModernWeb.tw-2015/#46 I would expect isNaN("LOL") to be true. Why does he put "true?!", and why does Number.isNaN("LOL") evaluate to false?

`isNaN` as it currently exists isn't terribly useful, because anything that can be type-coerced to NaN will return true. If you want to check if something actually is NaN in JS, the common idiom is to test x !== x, since NaN is the only value in JS that is defined as not being equal to itself (don't blame Eich, blame the IEEE floating-point standard). NaN, despite the name, is a "number" that's a result of floating-point calculations with undefined behavior. Sometimes that's a useful thing to test for.

Adding a new, proper isNaN function under a new namespace (Number) lets them do that without breaking the old functionality.

Re: JavaScript at 20

#144

Post by magicalist »

TazeTSchnitzel wrote: post #134
wppick wrote: post #121

Can someone explain the isNaN part of this slide: http://brendaneich.github.io/ModernWeb.tw-2015/#46 I would expect isNaN("LOL") to be true. Why does he put "true?!", and why does Number.isNaN("LOL") evaluate to false?

I think I can. The old isNaN() coerces to Number, and non-numeric strings become NaN in JS, e.g. +"LOL" is NaN. However, the new isNaN() just returns false if the value passed isn't of the type Number, which I guess might be useful if you're going to use isNaN() on non-Number values? Before someone says that NaN means "not a number", technically yes it does, but it is really just a special value of the Number type. E…

note that isNaN() will remain as it is today, coercing to a number (and so isNaN('LOL') will continue to return true). Number.isNaN() will have the new behavior, testing for actual IEEE 754 NaN values (and so returning false for Number.isNaN('LOL')). Such is the unfortunate price of backwards compatibility.

Re: JavaScript at 20

#145

Post by cwyers »

TazeTSchnitzel wrote: post #120
ender7 wrote: post #95

Earlier quoted context omitted.

Chrome was trying to do this: https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.

...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)

I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.

Re: JavaScript at 20

#146

Post by TazeTSchnitzel »

TazeTSchnitzel wrote: post #120
ender7 wrote: post #95

Earlier quoted context omitted.

Chrome was trying to do this: https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.

...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)

14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond:

> asm.js doesn't support threading.

asm.js supports threading, actually, through Web Workers and SharedArrayBuffer.

> it can't run native code.

This is true, but asm.js is relatively close to the metal. It's not very far from assembly language.

> it doesn't support meaningful debugging.

This is a tooling issue. While the situation is bad at the moment, it'll surely improve.

> it doesn't have a post-DOM API surface like pepper.

Why do you need a "post-DOM API surface"? If you just want to blit stuff to the screen, the DOM is actually no less efficient than Pepper: you can directly pass it pixel buffers, or call OpenGL routines.

Re: JavaScript at 20

#147

Post by TazeTSchnitzel »

cwyers wrote: post #145
TazeTSchnitzel wrote: post #120

Earlier quoted context omitted.

...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)

I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.

Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me.

Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.

Re: JavaScript at 20

#148

Post by albemuth »

e12e wrote: post #124
svachalek wrote: post #80

Earlier quoted context omitted.

As I understand it, yes, 'var' is now obsolete. 'let' does the same thing with less confusing semantics.

So, 20+ years ago, javascript was a scheme(-like langauge) -- but was disguised as java for marketing -- now we can go back to a more scheme-like javascript? I wonder if we'd be better off with a proper scheme in the browser in the first place...

ClojureScript is pretty cool!

Re: JavaScript at 20

#149

Post by frik »

M2Ys4U wrote: post #142
frik wrote: post #122

Edit2: When do you switch off your transpiler and serve native ES6? In 2020? Original: What do you do in 2017? What if you already code in ES6 and transpile it to JS5 at the moment. Do you simply switch from serving JS5 to JS6? Older browsers (todays current browser) don't support "class", "let" and other new syntax constructs. The just fail with JS errors. Can one browse the web with IE11 and iOS 8 Safari in 2017? (…

You can transpile from ES2015/16 (ES6/7) to ES5 code today. Babel[0] (formerly 6to5) is one such tool that will do just that. [0] https://babeljs.io/

My question was: When do you switch off your transpiler and serve native ES6? In 2020?

Today we can use native JS5 and use polyfill for JS1-3 browser. In future (e.g. 2017) one will have to rely on a transpiler or stay with JS5 for many years - right?

Re: JavaScript at 20

#150

Post by magicalist »

frik wrote: post #122

Edit2: When do you switch off your transpiler and serve native ES6? In 2020? Original: What do you do in 2017? What if you already code in ES6 and transpile it to JS5 at the moment. Do you simply switch from serving JS5 to JS6? Older browsers (todays current browser) don't support "class", "let" and other new syntax constructs. The just fail with JS errors. Can one browse the web with IE11 and iOS 8 Safari in 2017? (…

The web is a lot more broken if you browse in IE6 than you appear to think. Some major sites work OK only because they had a financial interest (single digits of IE6 marketshare) until the last few years to maintain IE6 compatibility. This will degrade rapidly, but go off the very-well beaten path today and you'll find the web basically unusable.

Backwards compatibility on the web has long been backwards compatibility of source. Sites written in the IE6 era and not touched since should continue to work in browsers of today (which is why things like vendor-prefixed features proved to be a poor idea and are mostly no longer created). You'll get some rendering oddities, but this is still very much true.

Post reply on HN