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

JSC loves ES6

webkit.org

Post reply on HN
Print view View original

91–100 of 191 posts

Re: JSC loves ES6

#91

Post by fenomas »

pizlonator wrote: post #60
jacobolus wrote: post #55

Earlier quoted context omitted.

Yes, but sticking to old-school Javascript features was dramatically faster than either.

Not necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation. We’ll keep working on more optimizations for ES-6 so there will be more counter examples.

To be clear, do you mean that Map/Set is faster than {} even for plain idiomatic hashes with string keys (as opposed to pathological cases)?

When I last tested in other JS engines I found plain {} hashes were still moderately faster. (Haven't tried Safari since it doesn't support what I've been working on)

Re: JSC loves ES6

#92

Post by reaperhulk »

alwillis wrote: post #80
zajd wrote: post #48

Earlier quoted context omitted.

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications.

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications. I’m pretty sure you'd be wrong. Apple announced that it's paid over $70 billion to app developers since the App Store became a thing in 2008 at today's WWDC keynote. This is the 30% Apple pays developers; so we're talking about $233 billion in gross transactions in less than 10 years. Apple is likely…

Apple pays devs 70% (and more on long-lived app subscriptions now). So that's $100B, not $233B.

Re: JSC loves ES6

#93

Post by untog »

threeseed wrote: post #54
pfooti wrote: post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

Service workers are an anathema to everything Apple is trying to achieve with Safari and I would be shocked if it ever gets included. Their focus is on improving battery life, having a great user experience and maintaining a high level of privacy and security. Service workers are awful for all three. For example look at what you have to do to see running service workers: Developer Tools > Application > Service Worker…

> If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ?

What exactly are you supposing a service worker would be doing? They can't do huge downloads (the worker is shut down when there are no pages using it and it can only be reactivated by another browsing session or push message), can't receive push messages without showing a notification... there really is very little a service worker can do nefariously.

It can, however, help improve battery life by allowing you to better control the offline experience, and not needlessly activate cell radios.

Re: JSC loves ES6

#94

Post by imron »

alwillis wrote: post #80
zajd wrote: post #48

Earlier quoted context omitted.

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications.

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications. I’m pretty sure you'd be wrong. Apple announced that it's paid over $70 billion to app developers since the App Store became a thing in 2008 at today's WWDC keynote. This is the 30% Apple pays developers; so we're talking about $233 billion in gross transactions in less than 10 years. Apple is likely…

Apple pays developers 70% (and keeps 30% for itself), which would be $100 billion in gross transactions.

Re: JSC loves ES6

#95

Post by CharlesW »

rictic wrote: post #90
CharlesW wrote: post #88

Earlier quoted context omitted.

Safari supports Web Notifications: http://caniuse.com/#feat=notifications Safari 11 supports WebRTC, Media Capture API, WebAssembly, WebCrypto API, drag-and-drop, and other interesting new features. If a crippled browser is their goal, they're doing quite an awful job of it.

http://caniuse.com/#feat=push-api is the interesting notifications API, which allows notifying a user (with their permission) even when the app isn't open. Neither API is supported on iOS Safari, and desktop Safari only supports notifications while the app is open.

> Neither API is supported on iOS Safari, and desktop Safari only supports notifications while the app is open.

Ah, thank you for explaining the difference.

Re: JSC loves ES6

#96

Post by reitanqild »

millstone wrote: post #87
pfooti wrote: post #68

Earlier quoted context omitted.

With service workers you can transparently intercept outgoing XHRs and replace their results with cached values. You can even do a cache race if you want (cancel the xhr if your cache returns first). This is a hugely important feature for making web apps work offline-first. I mean, it's also a big part of progressive web apps, which is the next thing I'm going to complain about. (I don't personally care much about we…

This seems like a very strange API. Why do you need a proxy to intercept network requests coming from your own app?

To serve that requests from local storage if your device or the server is offline.

Re: JSC loves ES6

#97

Post by rictic »

threeseed wrote: post #54
pfooti wrote: post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

Service workers are an anathema to everything Apple is trying to achieve with Safari and I would be shocked if it ever gets included. Their focus is on improving battery life, having a great user experience and maintaining a high level of privacy and security. Service workers are awful for all three. For example look at what you have to do to see running service workers: Developer Tools > Application > Service Worker…

This is a misconception. Service workers don't sit in the background consuming resources and performing arbitrary tasks. They respond to events, typically to intermediate requests while a user is using a site.

The service worker spec was carefully and deliberately designed to give the browser, not the site, control over resource consumption. The browser is allowed to stop any service worker at almost any time. See https://github.com/w3c/ServiceWorker/blob/master/implementat...

Re: JSC loves ES6

#98

Post by pizlonator »

fenomas wrote: post #91
pizlonator wrote: post #60

Earlier quoted context omitted.

Not necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation. We’ll keep working on more optimizations for ES-6 so there will be more counter examples.

To be clear, do you mean that Map/Set is faster than {} even for plain idiomatic hashes with string keys (as opposed to pathological cases)? When I last tested in other JS engines I found plain {} hashes were still moderately faster. (Haven't tried Safari since it doesn't support what I've been working on)

No, I don't mean that. If you're using string or integer keys, then I think that {} still have a perf advantage.

Re: JSC loves ES6

#99

Post by pizlonator »

netheril96 wrote: post #81
pizlonator wrote: post #60

Earlier quoted context omitted.

Not necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation. We’ll keep working on more optimizations for ES-6 so there will be more counter examples.

But ES6 Map/Set is almost useless as it has no custom hash nor equality function. The key is either numeric, string, or object identity, not anyway better than the builtin {}.

I've found them to be useful when I write ES6 code. I agree that custom hash and equality functions would make these classes a lot better.

Re: JSC loves ES6

#100

Post by millstone »

reitanqild wrote: post #96
millstone wrote: post #87

Earlier quoted context omitted.

This seems like a very strange API. Why do you need a proxy to intercept network requests coming from your own app?

To serve that requests from local storage if your device or the server is offline.

If the asset is already in local storage, why do you need to create a network request in the first place?
Post reply on HN