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?
JavaScript at 20
121–130 of 327 posts
Re: JavaScript at 20
#122Edit2: 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? (e.g. "lifetime support" of the device)
Polyfills can be used for pre-JS5 browsers. But can you polyfill "let" and "class" syntax keyword? One can today still browse the web with IE6 and Phoenix 0.l (early Firefox), despite a few glitches and layout bugs. Many sites use polyfills like JQuery and still use JS3 functionality made popular by Crockford "JavaScript the Good Parts". JS5 added a few things that JQuery made popular.
The syntax changes between previous JS versions were smaller in comparison to ES4 and ES6 (ES4/E4X failed and was abandoned).
Edit1: I added "What if you already code in ES6 and transpile it to JS5 at the moment." as the second sentence to make it clearer. As several down voters misunderstood my serious question.
Re: JavaScript at 20
#123Earlier quoted context omitted.
There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript. The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles… > Or, they could take their own medicine,…
> You mean like Firefox?
Firefox is entirely written in JS? Or just the parts that fall within what JS can do?
The JIT isn't JS. The TLS stack isn't JS. Most of the heavy lifting (e.g. the DOM) isn't JS.
Re: JavaScript at 20
#124I wonder whether `let` should be used everywhere now making `var` effectively obsolete? Mixing both declaration styles looks bad.
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...
Re: JavaScript at 20
#125"Date hand-ported (h/t ksmith@netscape.com) from java.util.Date" I knew it!! The Date class is/was the worst thing about the Java library. It has confused a generation of programmers about dates and time zones. The main problem is that it's not a date, it's a time stamp.
[deleted]
Re: JavaScript at 20
#126"Date hand-ported (h/t ksmith@netscape.com) from java.util.Date" I knew it!! The Date class is/was the worst thing about the Java library. It has confused a generation of programmers about dates and time zones. The main problem is that it's not a date, it's a time stamp.
And while there are libraries which wrap Date in JS, there is no replacement that I've seen anyone propose. Why is a replacement needed you ask? Because Date still has exclusive access to a lot of underlying browser/OS DateTime information which isn't accessible any other way.
In Java you legitimately have alternatives, since the alternatives can make the same raw OS calls that the java.util.Date library does. Not so in JS. So instead we HAVE to work with Date and work around its many warts.
I've used quite a few DateTime libraries extensively, I'm yet to see someone "better" the DateTime .Net class. It "just works" and has few to no "gotchas."
Re: JavaScript at 20
#127Earlier 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.)
asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
Re: JavaScript at 20
#128So good to see String.prototype.startsWith and String.prototype.endsWith in ES6. I've ended up implementing these in too many projects. I look forward to using these in 2020 or 5 years after that, when IE 8 finally sunsets. (I joke of course, since you can use ES6 to 5 with IE 8 caveats with the modern taskrunners). EDIT: Blockscope... what? More than a few of these changes point to JS being a functional version of P…
It's just for "let" AFAICT.
Re: JavaScript at 20
#129Earlier quoted context omitted.
There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.
14paninta replied to this, but their comment's dead (shadowban?) - anyway, I'll repost it here and respond to it.
> What does that even mean? It's nonsensical.
What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain?
>Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined.
Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either.
>You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture.
>You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations.
You can also retarget stuff compiling to JS to compile to something else, like Lua.
>Microsoft can ship the CLR for ARM, x86, PowerPC.
> You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you.
Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you.
> Microsoft can't ship a fully functioning CLR for JS.
This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.
Re: JavaScript at 20
#130Earlier quoted context omitted.
Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not de…
It doesn't actually work on (GUI) OSes - there is a strong incentive to write your app in the language and framework that is native to the platform, because you're asking for a lot of pain and a substandard customer experience otherwise. You write your Windows apps in C# and .NET. You write your Android apps in Java. You write your iOS apps in Objective-C, and now Swift. You write your Gnome apps in C with Gtk+, and…
It does work. Incentive is different than requirement.
How else would MS ship the CLR for Mac OS X?