JSC loves ES6(webkit.org)
webkit.org
JSC loves ES6
https://webkit.org/blog/7536/jsc-loves-es6/
190 comments
I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications.
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.
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.
Ah, thank you for explaining the difference.
“push notifications can reach your users regardless of whether your website or Safari is open“
https://developer.apple.com/library/content/documentation/Ne...
https://developer.apple.com/library/content/documentation/Ne...
Not on iOS, and not the web standard everyone else uses.
If the only possible market is desktop Safari users then it's usually a rounding error not worth the development time.
If the only possible market is desktop Safari users then it's usually a rounding error not worth the development time.
"Registration requires an Apple developer license."
Hmm, not the open web I'm familiar with.
Hmm, not the open web I'm familiar with.
That's a way for Apple to avoid abuse. Same thing like google requiring you to put an extension in the chrome store to enable screen capture.
One does not have to pay to publish a chrome extension.
Yes, you do have to pay to publish chrome web store. Only $5 though: https://developer.chrome.com/webstore/publish
Not having to pay does not make it 'open' either, but I see your point.
Safari ON MAC supports it.
I emailed the guy in charge of Safari on iOS and he said they have no plans to implement web push notifications on iOS!
I emailed the guy in charge of Safari on iOS and he said they have no plans to implement web push notifications on iOS!
The irony is that the only apps I could install on my iPhone 1 were javascript-powered html fragments. They launched with no app store or 3rd party binaries at all, and everything was to be done via js.
Now when we are super close to really supporting progressive web apps, apple is holding back (potentially to protect that golden calf of an app store).
Now when we are super close to really supporting progressive web apps, apple is holding back (potentially to protect that golden calf of an app store).
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 to be the first trillion dollar valuation company; I seriously doubt it's worried about web apps encroaching upon a fairly small part of it's revenue: http://fortune.com/2017/03/31/apple-trillion-dollar-company/
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 to be the first trillion dollar valuation company; I seriously doubt it's worried about web apps encroaching upon a fairly small part of it's revenue: http://fortune.com/2017/03/31/apple-trillion-dollar-company/
I think that's a shortsighted way to look at it. The iPhone is as successful as it is because of the perception of exclusivity - the best, newest apps will always be on iPhone first. Whether they are free or cost $100 each doesn't really matter that much - it still means Apple is the premier mobile device bar none.
If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps. That would not be in Apple's interest.
If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps. That would not be in Apple's interest.
Apple sure is putting in a lot of effort into ES5 performance for a platform that they’re supposedly crippling, not to mention smoking Chrome and Firefox in the process: https://webkit.org/blog/7536/jsc-loves-es6/
More proof that Apple isn’t crippling Safari--they announced full Web Assembly support today: https://webkit.org/blog/7691/webassembly/
The iPhone is as successful as it is because of the perception of exclusivity - the best, newest apps will always be on iPhone first.
That argument might have worked in back in the day when the iPhone was only available on AT&T but not in a world where the iPhone is available to more people than it ever has been before.
The iPhone is perhaps the single most successful product ever, with over 1 billion sold: http://www.asymco.com/2016/07/28/most-popular-product-of-all...
The total marketshare of Android is around 2 billion, but that's the total of Samsung, Motorola, HTC, LG, etc. None of them have individually sold a billion Android phones themselves.
If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps. That would not be in Apple's interest.
Do you think Apple cares more about selling a $700 iPhone or a 99¢ app? They have over a million native apps for iOS; what keeps that ecosystem strong is how Apple is able to innovate each year on new features for the iPhone, iPad and iOS, not by restricting what web apps can do.
The most compelling features are things web apps aren't very good at anyway. I seriously doubt Tim Cook is losing sleep worrying about Service Workers and the like.
People said the same thing about WebRTC and how it would compete with FaceTime. And now we have WebRTC in the new versions of macOS and iOS, so it's time to create reasons why other web features aren't there.
Web apps have made a lot of progress but for the average user in a developed country, the user experience pales in comparison to native apps.
That argument might have worked in back in the day when the iPhone was only available on AT&T but not in a world where the iPhone is available to more people than it ever has been before.
The iPhone is perhaps the single most successful product ever, with over 1 billion sold: http://www.asymco.com/2016/07/28/most-popular-product-of-all...
The total marketshare of Android is around 2 billion, but that's the total of Samsung, Motorola, HTC, LG, etc. None of them have individually sold a billion Android phones themselves.
If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps. That would not be in Apple's interest.
Do you think Apple cares more about selling a $700 iPhone or a 99¢ app? They have over a million native apps for iOS; what keeps that ecosystem strong is how Apple is able to innovate each year on new features for the iPhone, iPad and iOS, not by restricting what web apps can do.
The most compelling features are things web apps aren't very good at anyway. I seriously doubt Tim Cook is losing sleep worrying about Service Workers and the like.
People said the same thing about WebRTC and how it would compete with FaceTime. And now we have WebRTC in the new versions of macOS and iOS, so it's time to create reasons why other web features aren't there.
Web apps have made a lot of progress but for the average user in a developed country, the user experience pales in comparison to native apps.
They dont want to deal with potentional problems (like battery drain) of the web platform.
They can ignore it exactly because of their appstore and aura of exellence.
But in real world i know so many people who dont have single app on iphone. They cant even imagine what simple link could give them. This could go very wrong way for apple. Imagine their excelent app devs start to make webap version of their apps. Many of the beatifuly designed ones could work very easily on web platform. Suddenly it becomes trend and iphone app exclusivity is gone. Plus apple looses control over the market.
I for one would like to be able to opt in for notifs for events of certain clubs, galleries etc. It feels like sms for your fans. Much faster than newsletter much less busy than social networks.
They can ignore it exactly because of their appstore and aura of exellence.
But in real world i know so many people who dont have single app on iphone. They cant even imagine what simple link could give them. This could go very wrong way for apple. Imagine their excelent app devs start to make webap version of their apps. Many of the beatifuly designed ones could work very easily on web platform. Suddenly it becomes trend and iphone app exclusivity is gone. Plus apple looses control over the market.
I for one would like to be able to opt in for notifs for events of certain clubs, galleries etc. It feels like sms for your fans. Much faster than newsletter much less busy than social networks.
I'm one of those people. I don't like mucking around in the app-store, but I'd save a shortcut.
I got my numbers mixed up--Apple pays developers 70%, so the total revenue is "only" $100 billion and not $233 billion.
Here's a link to a comment from a WebKit engineer responding to the notion that Apple deliberately omits features from Safari. Short answer--they don't: https://news.ycombinator.com/item?id=14509746
Apple pays devs 70% (and more on long-lived app subscriptions now). So that's $100B, not $233B.
> I mean, where are service workers?
Every discussion about anything in Safari on HN, even if not at all related, for the last year or two has included multiple people complaining about the lack of WebRTC.
Now it's here and there is a new complaint /s
I agree with threeseed that it probwont come and frankly I don't see why I'd want it (or web notification, or even WebRTC). They only seem to support the use case of replacing real apps with webpages which I don't want to do and makes no sense to me as an end user (I understand the freedom motivations).
Every discussion about anything in Safari on HN, even if not at all related, for the last year or two has included multiple people complaining about the lack of WebRTC.
Now it's here and there is a new complaint /s
I agree with threeseed that it probwont come and frankly I don't see why I'd want it (or web notification, or even WebRTC). They only seem to support the use case of replacing real apps with webpages which I don't want to do and makes no sense to me as an end user (I understand the freedom motivations).
> Every discussion about anything in Safari on HN, even if not at all related, for the last year or two has included multiple people complaining about the lack of WebRTC.
> Now it's here and there is a new complaint /s
WebRTC is 6 years old and it's been implemented in Firefox and Chrome for 5 years now ! Since then there's plenty of other DOM API that where introduced and are not supported in webkit, for instance :
- service workers
- push API
- Fetch API
- User Timing API
- Subresource Integrity
On the JavaScript side, the JSC team has been doing a great job for the past two years, leading the way in term of performance and ES2015+ support, but on the DOM side, Safari is really lagging far behind (which is, I guess, probably because they don't want the compete with there native mobile apps).
> Now it's here and there is a new complaint /s
WebRTC is 6 years old and it's been implemented in Firefox and Chrome for 5 years now ! Since then there's plenty of other DOM API that where introduced and are not supported in webkit, for instance :
- service workers
- push API
- Fetch API
- User Timing API
- Subresource Integrity
On the JavaScript side, the JSC team has been doing a great job for the past two years, leading the way in term of performance and ES2015+ support, but on the DOM side, Safari is really lagging far behind (which is, I guess, probably because they don't want the compete with there native mobile apps).
Fetch is supported in 10.1 (only 2 years after Firefox and Chromium!)
They also already have Custom Elements v1 support, which is still in progress in Firefox.
Timing and SRI they announced in this release (11).
Service Workers is THE big gap, at this point it feels like they're actually very afraid of progressive web apps.
They also already have Custom Elements v1 support, which is still in progress in Firefox.
Timing and SRI they announced in this release (11).
Service Workers is THE big gap, at this point it feels like they're actually very afraid of progressive web apps.
Wasn't the original idea for the iPhone to just use web apps in place of native?
That was the only way to add apps on iPhone OS 1.0, yes. Maybe they already had the App Store in mind and intended that as a stopgap, maybe the App Store was a reaction to jailbreaks and unofficial app development…
A complaint you haven't seen, however, is lack of ES6 support - which means it's still baffling that there's so much focus on that.
(That said, the complaint was always lack of WebRTC and ServiceWorker support.)
(That said, the complaint was always lack of WebRTC and ServiceWorker support.)
> the complaint was always lack of WebRTC and ServiceWorker support
You have a source for that? To me nobody really started caring about ServiceWorker until the big push recently for PWAs w/ launch of Lighthouse etc. Whereas devs have always wanted browsers to keep up with JS/ES/CSS language standards.
Also "development doesn't really work like that". Who's to say the same devs implementing ES6 features could take on ServiceWorker. Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
I feel like the internet getting angry that 'feature 1' is released whilst the 'feature 2' they want isn't, and being all 'why are they spending all their time on feature 1 instead of working on my thing' is such an old trope there should be a term for it.
(But yeah I'd like to see ServiceWorker in Safari too, though please let's not bite the hand that feeds)!
You have a source for that? To me nobody really started caring about ServiceWorker until the big push recently for PWAs w/ launch of Lighthouse etc. Whereas devs have always wanted browsers to keep up with JS/ES/CSS language standards.
Also "development doesn't really work like that". Who's to say the same devs implementing ES6 features could take on ServiceWorker. Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
I feel like the internet getting angry that 'feature 1' is released whilst the 'feature 2' they want isn't, and being all 'why are they spending all their time on feature 1 instead of working on my thing' is such an old trope there should be a term for it.
(But yeah I'd like to see ServiceWorker in Safari too, though please let's not bite the hand that feeds)!
> You have a source for that?
Well, same as yours: I've seen people ask for that on Hacker News in the past. Of course, there will also have been people asking about WebRTC :) My beef has mostly been with SW though.
Of course, with many developers, there will always be some that have asked for one, and some for the other. I highly doubt that someone will chime in saying that they've seen people complaining about lack of ES6 support in Safari, though :)
> Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
Yes, this is true. That's why it's mostly "baffling", i.e. I wonder if something like you described is actually the case, or whether it's a case of different priorities or something.
Well, same as yours: I've seen people ask for that on Hacker News in the past. Of course, there will also have been people asking about WebRTC :) My beef has mostly been with SW though.
Of course, with many developers, there will always be some that have asked for one, and some for the other. I highly doubt that someone will chime in saying that they've seen people complaining about lack of ES6 support in Safari, though :)
> Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
Yes, this is true. That's why it's mostly "baffling", i.e. I wonder if something like you described is actually the case, or whether it's a case of different priorities or something.
Well, lack of ServiceWorker support by itself was a complaint, that's for sure: https://www.google.com/search?q=site%3Anews.ycombinator.com+...
But it's like saying people complain about Internet Explorer not having a feature that other browsers have. When it takes many years longer than the other browsers to implement a feature, you are effectively holding the market back. IE and Safari are the only two browsers that didn't have support until now (with only IE not having support while Edge does).
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 webrtc, but I can see why people do care about it).
The general point isn't about any one feature in particular. It is about a history safari has with not implementing (or half-heartedly implementing, as with indexeddb for so long) APIs that are important to making the web a useful platform.
Reasonable people can disagree whether or not those features are good, but it seems basically true that my mobile web work is constrained by what iOS safari outright refuses to do, more than anything else.
The general point isn't about any one feature in particular. It is about a history safari has with not implementing (or half-heartedly implementing, as with indexeddb for so long) APIs that are important to making the web a useful platform.
Reasonable people can disagree whether or not those features are good, but it seems basically true that my mobile web work is constrained by what iOS safari outright refuses to do, more than anything else.
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.
Can't this be solved by a library? It seems like you could easily build a facade in front of requests that queried local storage...you would just need to figure out whether the device/server is online or not.
It's not just XHRs, it's all requests by your app. The HTML, the CSS, images, everything. The entire site can be served offline by this API.
You need to be able to bootstrap the page to start with. If I request news.ycombinator.com and I'm offline, then Service Workers are the only way to avoid an error page.
For web apps running in normal browsers, Service Workers ARE that facade.
If the asset is already in local storage, why do you need to create a network request in the first place?
...since you don't know whether there is a new version available on the server or not. To not make the user wait, you show him/her the - potentially - outdated version of your data until a new version is available. It's especially useful in situations where users lack internet connection.
I'm interested in this as well, as I haven't dove into service workers.
But I'm still failing to see why you can't pull the local data from local storage and show it, then render the data from the server (should you get new data)?
But I'm still failing to see why you can't pull the local data from local storage and show it, then render the data from the server (should you get new data)?
That works fine for your xhr data (and is what I do now), but is idiosyncratic to your library (note that detecting online state, responding to online state changes, etc all add complexity to this seemingly simple module, as does managing cache expiry).
You can't do anything about your top level index.html file (or the main js and css assets) though. If the user starts offline the second time they use your app, there's no guarantees about those bootup assets being loaded into cache, you'll just get the "you're offline" screen instead.
Since we are talking about hooking the lifecycle of a page, there's no good way to polyfill this with a library. That initial request needs to be serviced, offline, before you can load your polyfill library.
You can't do anything about your top level index.html file (or the main js and css assets) though. If the user starts offline the second time they use your app, there's no guarantees about those bootup assets being loaded into cache, you'll just get the "you're offline" screen instead.
Since we are talking about hooking the lifecycle of a page, there's no good way to polyfill this with a library. That initial request needs to be serviced, offline, before you can load your polyfill library.
Maybe I'm confused, but provided I bootstrap the app every time by downloading a script that then downloads the big-ass app (that includes styling and whatnot) if necessary, I should be fine right? Or am I missing something?
That said I do understand that avoiding this could be desirable.
That said I do understand that avoiding this could be desirable.
What happens if your user is offline (airplane mode, no data, etc), and can't download the initial bootstrap script? There's no way to avoid an error page at this time, unless you use a browser-specific plugin (the drive offline addon is one of these, but they now use service workers for the same functionality on chrome IIRC).
This is especially useful in non-us, non-eu countries, where people pay a lot for data, relative to their income. Being able to successfully launch and run without any data usage is pretty rad.
This is especially useful in non-us, non-eu countries, where people pay a lot for data, relative to their income. Being able to successfully launch and run without any data usage is pretty rad.
Ah, of course. That is indeed a significant issue...
Service workers are in a separate layer to your app code. They're in another thread, they're subject to different memory/storage rules, they have access to a few extra apis IIRC.
Service workers are designed to be run independently of your web page. I.e. Your service worker can run in the background and update your apps resource files (or even cached xhr data) when your website isn't open, so that it's ready when the user accesses your site.
This means your site goes from remotely delivered to locally served. Which reduces the load times to super low.
IMO it's also nice and clean because it lets you completely separate your app and network logic. Your web app itself can be built as if it is always online, and all the offline logic is in the separate code package in a separate thread.
Service workers are designed to be run independently of your web page. I.e. Your service worker can run in the background and update your apps resource files (or even cached xhr data) when your website isn't open, so that it's ready when the user accesses your site.
This means your site goes from remotely delivered to locally served. Which reduces the load times to super low.
IMO it's also nice and clean because it lets you completely separate your app and network logic. Your web app itself can be built as if it is always online, and all the offline logic is in the separate code package in a separate thread.
Well, service workers do run in a separate thread which finally brings multithreading (not multi-iframing ;)) to javascript.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
and
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
?
"finally" seems wrong here :)
I'll also note that Safari 10.1 was first with SharedArrayBuffer ;)
and
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
?
"finally" seems wrong here :)
I'll also note that Safari 10.1 was first with SharedArrayBuffer ;)
Then you have to build that in your application. In typical use-cases, your application does not have to know about Service Workers, but usually not the vice versa. For example, you can decide to intercept /article/show/{id}, just get the content for the article from your API, compile it with a template you have cached, and serve that instead. From the perspective of your app, nothing has changed. It is the holy grail of progressive enhancement.
[deleted]
Or why can't this problem be solved with HTTP caching headers and a browser that Does the Right Thing?
I'm pretty sure HTTP caching headers don't provide a guarantee that they will be stored for any length of time at all, the browser is free to empty it at will. They also don't guarantee that all your cached assets will be valid with respect to each other (ie your browser might cache an HTML file but not the content it refers to).
Most importantly, though, you can't simply disable HTTP caching when you notice that you're back online. Those cache entries are there now, and they're hard to get out. Service Workers, on the other hand, will just transparently stop intercepting stuff.
With respect to localStorage, I think the idea is that you absolutely can do almost an entire offline mode with it, with the caveat that your content (html, js, css, images) won't get stored there, so you can't load the page at all!
Also I think there are considerations about how difficult it is for many front end architectures to implement this transparent fallback themselves. If you're a Redux or ClojureScript type of programmer it might be utterly obvious and even trivial to implement (just add a simple middleware), but sadly not everyone is, and a lot of the offline logic would have to be implemented everywhere in your codebase. A service worker lets you do it all in one place.
It's a toss-up whether to use localStorage or a service worker if you could viably do either. Blanket logic over all your HTTP calls would be easier in a service worker, and more customized logic would be easier in localStorage, I'm guessing.
Most importantly, though, you can't simply disable HTTP caching when you notice that you're back online. Those cache entries are there now, and they're hard to get out. Service Workers, on the other hand, will just transparently stop intercepting stuff.
With respect to localStorage, I think the idea is that you absolutely can do almost an entire offline mode with it, with the caveat that your content (html, js, css, images) won't get stored there, so you can't load the page at all!
Also I think there are considerations about how difficult it is for many front end architectures to implement this transparent fallback themselves. If you're a Redux or ClojureScript type of programmer it might be utterly obvious and even trivial to implement (just add a simple middleware), but sadly not everyone is, and a lot of the offline logic would have to be implemented everywhere in your codebase. A service worker lets you do it all in one place.
It's a toss-up whether to use localStorage or a service worker if you could viably do either. Blanket logic over all your HTTP calls would be easier in a service worker, and more customized logic would be easier in localStorage, I'm guessing.
Just to articulate the difference on HTTP caching again:
Using HTTP caching for saying how long online clients should keep a value becomes impossible if you want to tell browsers to store things forever in offline mode. HTTP caching makes no distinction between whether you're online or offline.
Using HTTP caching for saying how long online clients should keep a value becomes impossible if you want to tell browsers to store things forever in offline mode. HTTP caching makes no distinction between whether you're online or offline.
So HN commenters who don't use Service Workers can have some invective to throw at WebKit.
It is yet another hack web developers come up with, as workaround for offline apps.
> my mobile web work is constrained by what iOS safari outright refuses to do
You are privileged to be able to work with Safari.
Imagine if you had to work with its bastard deformed brothers WKWebView and UIWebView.
You are privileged to be able to work with Safari.
Imagine if you had to work with its bastard deformed brothers WKWebView and UIWebView.
ES6 features are faster when natively supported and natively optimized like in JSC.
Yay. Now let me build a progressive web app for iOS and I will care about javascript perf on that platform.
Speed is great and all, really great for some people. I just wish they had different priorities.
Speed is great and all, really great for some people. I just wish they had different priorities.
That's cool, but it feels a bit like making sure your room is tidied up while your house is on fire -- it's not clear it's the most pressing priority.
But webrtc support is cool.
But webrtc support is cool.
My house is definitely not on fire. That much I can tell you.
My room, on the other hand, is definitely not tidy. Haven't cleaned that shit in ages.
My room, on the other hand, is definitely not tidy. Haven't cleaned that shit in ages.
Your office is pretty tidy though.
But seriously, we have a bunch of developers asking for JavaScript improvements. Maybe OP doesn't want them, fine that's useful feedback... but it would be more easily received if it came in a nicer package :)
But seriously, we have a bunch of developers asking for JavaScript improvements. Maybe OP doesn't want them, fine that's useful feedback... but it would be more easily received if it came in a nicer package :)
There never was a browser monopoly on Windows just a bunch of tech illiterates who don't seem bothered by MS's "monopoly" with notepad.exe or anti-competitive moves like taking away the ability to use an alternate graphical shell.
Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
> Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
iOS doesn't prevent the installation of alternate browsers. It prevents alternate browsers from running their own HTML renderer. Preventing alternate browsers might be legally actionable if Apple had a monopoly; preventing alternate HTML renderers is decidedly not.
iOS doesn't prevent the installation of alternate browsers. It prevents alternate browsers from running their own HTML renderer. Preventing alternate browsers might be legally actionable if Apple had a monopoly; preventing alternate HTML renderers is decidedly not.
I'm not entirely interested in relitigating a past I literally lived through.
On the other hand, it is objectively true that there is only one browser platform for iOS. WebKit or nothing. If they actually supported chrome or Firefox instead of requiring them to be wrappers on webkit renderers, I would not have this complaint.
Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
On the other hand, it is objectively true that there is only one browser platform for iOS. WebKit or nothing. If they actually supported chrome or Firefox instead of requiring them to be wrappers on webkit renderers, I would not have this complaint.
Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
I am so glad people can use another browser on ChromeOS, oh wait...
The difference is that it was technically infeasible to run another browser on ChromeOS,
not policy infeasible. The technical infeasibility was recently removed. https://www.google.com/amp/www.techrepublic.com/google-amp/a...
No difference at all, in regards to the end user experience, but Google tends to have a green card from HN crowd.
If I really wanted to, I could have built another browser using PNaCl and run it and distributed it on ChromeOS even before it supported Android apps where users trivially have access to other browsers. That remains impossible on iDevices to this day.
If you can't see the difference, you are only deceiving yourself.
If you can't see the difference, you are only deceiving yourself.
Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
No. Monopolies themselves aren't illegal, especially when they're natural monopolies.
It is illegal for a company to use its monopoly to stifle competition in other, unrelated markets.
The classic case is Microsoft using its monopoly in operating systems when Windows had 95% marketshare in the emerging browser market. Remember that Microsoft threatened to cancel HP and Compaq’s Windows licenses if they continued to ship Netscape Navigator instead of IE. That's illegal.
It's not illegal to have a rules and guidelines for a platform a particular company owns. Game consoles are way more restrictive than the iOS App Store and nobody is suing them.
No. Monopolies themselves aren't illegal, especially when they're natural monopolies.
It is illegal for a company to use its monopoly to stifle competition in other, unrelated markets.
The classic case is Microsoft using its monopoly in operating systems when Windows had 95% marketshare in the emerging browser market. Remember that Microsoft threatened to cancel HP and Compaq’s Windows licenses if they continued to ship Netscape Navigator instead of IE. That's illegal.
It's not illegal to have a rules and guidelines for a platform a particular company owns. Game consoles are way more restrictive than the iOS App Store and nobody is suing them.
How do you feel about ChromeOS?
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 Workers
chrome://inspect/#service-workers
If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ? How would my grandmother ? Where is the transparency the web is supposed to provide ?
Developer Tools > Application > Service Workers
chrome://inspect/#service-workers
If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ? How would my grandmother ? Where is the transparency the web is supposed to provide ?
> If there was a rogue web site launching service workers to do something nefarious how would I know diagnose what's happening ? How would my grandmother ? Where is the transparency the web is supposed to provide ?
How does your grandmother check if the website she visits isn't doing something nefarious without service workers? Does she run the CPU profiler to see all the JS being executed? That's pretty badass, I wish my grandmother was this cool.
How does your grandmother check if the website she visits isn't doing something nefarious without service workers? Does she run the CPU profiler to see all the JS being executed? That's pretty badass, I wish my grandmother was this cool.
Something here about babies and bathwater. Service workers are pretty limited in what they can do.
Is there UX work to be done? Sure. But the fundamental problem is that they fill a need that is not met at all by Apple, and not even in a silly "use metal instead of vulkan because reasons" kind of NIH but we'll support some other similar standard fashion, but in a "nope" way.
So, kudos for the speedy es6. I'm still not going to tell people to use safari on macos, and I'm still going to build crazy DIY caches for safari on iOS because I can't do stuff with service workers in a standardized way.
Is there UX work to be done? Sure. But the fundamental problem is that they fill a need that is not met at all by Apple, and not even in a silly "use metal instead of vulkan because reasons" kind of NIH but we'll support some other similar standard fashion, but in a "nope" way.
So, kudos for the speedy es6. I'm still not going to tell people to use safari on macos, and I'm still going to build crazy DIY caches for safari on iOS because I can't do stuff with service workers in a standardized way.
> 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.
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.
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...
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...
The benchmark at the bottom showing how far behind Firefox has fallen on JS performance is pretty telling. It confirms my own recent observation that Firefox is at least 3-6 times slower in practice for the particular app I'm working on.
A vendor is always the fastest when they roll out a new benchmark. It's disingenuous to suggest a browser is '3-6x slower' based on a score on one benchmark, when all the vendors actively compete on and optimize against a large set of benchmarks, and compare each others' performance numbers on individual tests to understand engine weaknesses/strengths.
fwiw, Chrome, Firefox and Safari have all been fairly competitive on the major performance benchmark (Octane) for a while, with jsc taking a bit to catch up to the others. Sunspider and Kraken are now relatively outdated because everyone is fast on them:
https://arewefastyet.com/
Octane is on the way out, so I have no doubt that the vendors will all pull close together on this new Apple benchmark set once they have time to optimize for it, since most of these benchmarks are cynical gaming anyway more than they are real applications. (Octane, which is culled from real webapps, had a glaring bug in one of its test cases for a while that happened to make v8 much faster at the cost of the test not actually doing real work.)
It's also silly to judge a browser's performance based on how fast bleeding-edge features are. Bleeding-edge features can't be fully/effectively optimized until there are real-world examples of how they are used.
P.S. it may be interesting to look at https://arewefastyet.com/#machine=36 and note that the JS runtime in MS's Edge is shockingly competitive on these benchmarks as well. You can't count anyone out of the race.
fwiw, Chrome, Firefox and Safari have all been fairly competitive on the major performance benchmark (Octane) for a while, with jsc taking a bit to catch up to the others. Sunspider and Kraken are now relatively outdated because everyone is fast on them:
https://arewefastyet.com/
Octane is on the way out, so I have no doubt that the vendors will all pull close together on this new Apple benchmark set once they have time to optimize for it, since most of these benchmarks are cynical gaming anyway more than they are real applications. (Octane, which is culled from real webapps, had a glaring bug in one of its test cases for a while that happened to make v8 much faster at the cost of the test not actually doing real work.)
It's also silly to judge a browser's performance based on how fast bleeding-edge features are. Bleeding-edge features can't be fully/effectively optimized until there are real-world examples of how they are used.
P.S. it may be interesting to look at https://arewefastyet.com/#machine=36 and note that the JS runtime in MS's Edge is shockingly competitive on these benchmarks as well. You can't count anyone out of the race.
The performance difference I see with my own app with Firefox is exactly the benchmark's 3-6x, that's not a benchmark but real world usage.
It's enough to make the startup feel slow (3-4 seconds of being unresponsive) and things like animations and drag and drop features to feel janky. Running a non-minified build (about 20MB of JS, minifies to about 1MB) also completely murders Firefox reducing it to a slideshow, making Firefox unusable for development, while Chrome works just fine.
It's enough to make the startup feel slow (3-4 seconds of being unresponsive) and things like animations and drag and drop features to feel janky. Running a non-minified build (about 20MB of JS, minifies to about 1MB) also completely murders Firefox reducing it to a slideshow, making Firefox unusable for development, while Chrome works just fine.
If your app is 3-6x slower overall in Firefox to the point of animations & dragging being slower, and to the point that non-minification makes it slower... something is wrong with your app. Animations are generally the work of the layout engine and compositor, which is absolutely not going to be impacted by jsc's latest JS optimizations, or by ES6 features.
For one thing, minification's impact is largely on parsing, so it shouldn't have any noticeable impact on anything other than startup time and memory usage (the compressed JS source for Function.toString will be a bit smaller if minified). If your app is really slower at runtime when not minified, again, something is wrong.
Is your application written in raw (non-transpiled) ES6 and heavily using generators, async, tail call opts etc in tight perf-sensitive loops that run on the main thread without yielding to the event loop? It's hard for me to come up with a scenario where you could see such a huge performance gap in a well-constructed application.
If computational performance is really important to you, then you're writing asm.js (or webassembly) and shipping that. All of the modern JS engines perform great on that sort of code and you simply cannot see a 3-6x gap there. So something weird is going on with your app that any vendor would be happy to fix if you sent them a repro (or just let them try out your app).
For one thing, minification's impact is largely on parsing, so it shouldn't have any noticeable impact on anything other than startup time and memory usage (the compressed JS source for Function.toString will be a bit smaller if minified). If your app is really slower at runtime when not minified, again, something is wrong.
Is your application written in raw (non-transpiled) ES6 and heavily using generators, async, tail call opts etc in tight perf-sensitive loops that run on the main thread without yielding to the event loop? It's hard for me to come up with a scenario where you could see such a huge performance gap in a well-constructed application.
If computational performance is really important to you, then you're writing asm.js (or webassembly) and shipping that. All of the modern JS engines perform great on that sort of code and you simply cannot see a 3-6x gap there. So something weird is going on with your app that any vendor would be happy to fix if you sent them a repro (or just let them try out your app).
Maybe you're hitting the same slow path in Firefox than this benchmark (see [1]).
I used to work on an app that was 5 to 10 times slower in v8 than in SpiderMonkey, was it a proof that v8 was slower than SpiderMonkey ? No, we were actually falling in a v8 slow path (using exceptions in a hot section of the code because babel was transpilling `for of` loops to something that used exceptions), after some profiling we found the culprit and fixed it.
When you hit a 5x differences in JavaScript speed, it's almost never a browser performance difference, it's a bug in this specific browser : you're probably hitting a slow paths in this engine and you can probably work around it (or report a bug and wait until they fix it).
[1]: https://news.ycombinator.com/item?id=14495275
I used to work on an app that was 5 to 10 times slower in v8 than in SpiderMonkey, was it a proof that v8 was slower than SpiderMonkey ? No, we were actually falling in a v8 slow path (using exceptions in a hot section of the code because babel was transpilling `for of` loops to something that used exceptions), after some profiling we found the culprit and fixed it.
When you hit a 5x differences in JavaScript speed, it's almost never a browser performance difference, it's a bug in this specific browser : you're probably hitting a slow paths in this engine and you can probably work around it (or report a bug and wait until they fix it).
[1]: https://news.ycombinator.com/item?id=14495275
Can you share a link to your web app? Mozilla developers are very interested in profiling performance problems on real sites. You might want to check in Firefox's about:support page to see if there are any warnings about your GPU being blocked for driver issues.
Feel free to email me if you'd prefer not to share a link in a public HN comment. See my HN profile for my Mozilla email address.
Feel free to email me if you'd prefer not to share a link in a public HN comment. See my HN profile for my Mozilla email address.
Mostly what the benchmark shows is that the benchmark in question measures one specific thing which doesn't have a JIT fast path in Firefox yet, but measures it multiple times in different ways...
[Edit: Actually two things: hot loops in the same function as a class definition, and derived classes that use "super".]
Chances are whatever you see on your app is a different issue. I'd be happy to profile and file bugs as needed if you can get me a link that shows the problem on your app.
[Edit: Actually two things: hot loops in the same function as a class definition, and derived classes that use "super".]
Chances are whatever you see on your app is a different issue. I'd be happy to profile and file bugs as needed if you can get me a link that shows the problem on your app.
Interesting. What is that thing exactly? Is there a bug we can follow?
Actually, I guess there are two things:
1) If you have a class definition inside a function, that function doesn't get jitted. The functions in the class definition itself can still get jitted. 2) Class methods that use super don't get jitted at the moment.
So if your class definitions are not in the same function as your hot code and don't use super, you get fast paths. Otherwise some things will run in the interpreter.
The tracking bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 and https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 is what the above summary is based on.
1) If you have a class definition inside a function, that function doesn't get jitted. The functions in the class definition itself can still get jitted. 2) Class methods that use super don't get jitted at the moment.
So if your class definitions are not in the same function as your hot code and don't use super, you get fast paths. Otherwise some things will run in the interpreter.
The tracking bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 and https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 is what the above summary is based on.
Well, that should be pretty non-surprising. There are 4 mayor Javascript engines and 3 of them belong to some of the largest companies in the world (Apple, Alphabet and Microsoft). It was just a matter of time before they caught up through throwing money at the problem. I use Firefox (except for Hangouts) but I understand Chrome's advantaged situation will probably allow them to be the sole competitor in the near-middle future.
On the other hand, it's not like Firefox is the side project of a few of people in their spare time -- the Mozilla Foundation has annual revenue of over $400 million!
[1] https://en.wikipedia.org/wiki/Mozilla_Foundation
[1] https://en.wikipedia.org/wiki/Mozilla_Foundation
$400 million looks like a lot until you remember that Apple have $267 billion in cash reserves. The Mozilla Foundation's entire annual revenue isn't even a fifth of a percent of what Apple have just sitting around because they can't find a better use for it. The fact that Mozilla are able to punch even this far above their weight is kind of impressive.
But Mozilla really only has one big thing they make, which is Firefox. Apple's software portfolio on just one of their multiple hardware platforms (let's not forget that they make that hardware, too, including designing their own processors) completely dwarfs Mozilla.
I agree with jonas21 - for $400m a year you ought to be able to build an amazing browser.
I agree with jonas21 - for $400m a year you ought to be able to build an amazing browser.
And they do build a good browser. Firefox is mostly as usable as Safari, Chrome and IE.
1) Apple's cash assets aren't actually cash or just a bank account. It's accounting speak for liquid assets. Any investments that they could divest fairly quickly and easily and repurpose to finance other capital expenditures. The money isn't sitting around doing nothing; in the meantime it's invested in a safe portfolio which attempts to grow it. Imagine a hedge fund for just one LP.
2) Apple is a mega-company which has a bajillion lines of business and produces hardware. The WebKit team is a tiny tiny tiny sliver of what Apple does and cares about; so its budget is probably a lot closer to Mozilla's.
2) Apple is a mega-company which has a bajillion lines of business and produces hardware. The WebKit team is a tiny tiny tiny sliver of what Apple does and cares about; so its budget is probably a lot closer to Mozilla's.
> The money isn't sitting around doing nothing; in the meantime it's invested in a safe portfolio which attempts to grow it. Imagine a hedge fund for just one LP.
Right... how does that make it any different?
Apple's not a finance company, or at least they weren't until they wound up with so much cash they had no actual present business needs for. If you're a hardware/software company that has so much extra money (billions) that you become your own 'hedge fund' to have something to do with it... yeah, you've got a lot of extra money. How much extra money? More than 500x the annual budget of Mozilla, yup.
Right... how does that make it any different?
Apple's not a finance company, or at least they weren't until they wound up with so much cash they had no actual present business needs for. If you're a hardware/software company that has so much extra money (billions) that you become your own 'hedge fund' to have something to do with it... yeah, you've got a lot of extra money. How much extra money? More than 500x the annual budget of Mozilla, yup.
I do not have an inside look, but if I remember correctly there were few calls about Mozilla losing focus on Firefox through making Firefox OS for a few years, which is exactly when the other vendors were reinventing their engines. They made some great work with Rust though (;
Firefox OS led Mozilla to push a lot on the performance front in Gecko, mostly in gfx land. The JS perf is mostly SpiderMonkey and there was very little FxOS specific work done (as far as I remember, we mostly got help to tune the GC heuristics) because the JS team was already streched pretty thin.
These days Moco doesn't even try on mobile anymore (hint, there is no performance testing at all on arm in https://arewefastyet.com/#).
The desktop Firefox front-end didn't evolve so much during the FxOS days but these was not the same team either... and you would notice that key people leading Fx front end have changed since.
These days Moco doesn't even try on mobile anymore (hint, there is no performance testing at all on arm in https://arewefastyet.com/#).
The desktop Firefox front-end didn't evolve so much during the FxOS days but these was not the same team either... and you would notice that key people leading Fx front end have changed since.
This benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).
It's important to note, yes. Maybe Firefox is just a bit lagging in its optimization schedule.
Also, all deployed sites and apps today are actually running ES5 transpiled from ES6.
Also, all deployed sites and apps today are actually running ES5 transpiled from ES6.
And that's all fine...in a lab. In the real world, all I have to do to experience Firefox's performance is click "Home" on my Twitter account. More often than not I'll get an alert that "A script has stopped responding [...] Continue / Stop Script," and it will still take 60+ secs to finish refreshing the page. Meanwhile, all Firefox tabs and window instances are frozen.
That's weird. Firefox is my first-choice browser, and it only takes a couple seconds to load Twitter. You might want to see if you have any badly behaving plugins.
re "all Firefox tabs and window instances are frozen" — looks like you don't have multiprocess enabled. Check about:support for Multiprocess windows and Asynchronous Pan/Zoom.
Oh wow, that's pretty terrible.
That's more of an indication that Chrome monoculture encourages crap developer practices. There's no reason a messaging site should be so bloated that it brings a modern browser to it's knees.
Are you sure that's mere slowness?
I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
It strange i dont know in which world i am living but i always have opposite feeling.
I use lot of tabs and well chrome might start faster but if you have 30 tabs open it slows my whole computer. With firefox it seems all fine.
I use lot of tabs and well chrome might start faster but if you have 30 tabs open it slows my whole computer. With firefox it seems all fine.
I really wish we would stop calling it ES6. Browser vendors should be especially careful to call ES2015 by its correct name and help stop perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this quickly gets confusing).
ES6 is 3 syllables. ES2015 is 6 or 7 (depending if you say "twenty fifteen" or "two thousand fifteen").
I'm a dev. I'm lazy. I have no particular objection to the idea of moving away from ES6 as a name, but if the new name isn't more useful, it's not going to gain any ground.
I'm a dev. I'm lazy. I have no particular objection to the idea of moving away from ES6 as a name, but if the new name isn't more useful, it's not going to gain any ground.
I don't care what the name is, but if everyone would just use the SAME name, it'd be a hell of a lot less confusing.
But hey, this is Apple which often insists on giving their OS releases both a number and a name and referring to them by each in different places (but hardly ever using both name and number at once), so. I feel like if I were able to tally up all the minutes I've spent cross-referencing "Wait, so 10.6, which one is that? Wait, so 'Leopard', which one is that?", it'd be depressing.
But hey, this is Apple which often insists on giving their OS releases both a number and a name and referring to them by each in different places (but hardly ever using both name and number at once), so. I feel like if I were able to tally up all the minutes I've spent cross-referencing "Wait, so 10.6, which one is that? Wait, so 'Leopard', which one is that?", it'd be depressing.
Unfortunately it's the name we're stuck with though, and it makes a lot more sense because ECMA releases are yearly.
Not judging, but if high profile articles and browser vendors started addressing it correctly we wouldnt have any issues migrating, more syllables or not.
Not judging, but if high profile articles and browser vendors started addressing it correctly we wouldnt have any issues migrating, more syllables or not.
I'm a touch confused...are you saying that if everyone used the year-based nomenclature, the inconsistent support would go away? Today in 2017 I have some ES6/ES2015 features I can use as well as some ES7/ES2016 features, but there are also other ES6/ES2015 that I can't count on being supported, and quite a few ES7/ES2016 features I can't count on.
How are these problems alleviated if we change the name we use? Or have I totally misunderstood your point?
Side Note: I'm not a fan of using a year for the same reason we (i.e. most everyone) stopped using it for versioning - That previous iterations have been done on a yearly cycle does not mean that future iterations will follow that schedule. That, however, is a side argument that neither of us touched on.
How are these problems alleviated if we change the name we use? Or have I totally misunderstood your point?
Side Note: I'm not a fan of using a year for the same reason we (i.e. most everyone) stopped using it for versioning - That previous iterations have been done on a yearly cycle does not mean that future iterations will follow that schedule. That, however, is a side argument that neither of us touched on.
Just talking about the name.
You can see how this is confusing, here's a recent one just from today by Craig Federighi https://twitter.com/feross/status/871839072590979076
You can see how this is confusing, here's a recent one just from today by Craig Federighi https://twitter.com/feross/status/871839072590979076
I'm pretty sure this ship has sailed for ES6. It's been referred as such while it was in development for so long, it's here to stay.
The next one might be different. But they really need to come up with a better than than "2017" or whatever. There's no similar problem with C or C++, and that's likely because they use 2 digit years, not 4 digit - C++17 isn't super short, but it's not a mouthful.
The next one might be different. But they really need to come up with a better than than "2017" or whatever. There's no similar problem with C or C++, and that's likely because they use 2 digit years, not 4 digit - C++17 isn't super short, but it's not a mouthful.
But the new name is more useful. It tells you how many years you're behind.
Only sort of - it says how far behind the standard I might be, but since we're limited (on the Web at least) to what the browsers have implemented, it's not really measuring the important parts. (And in the backend, we're limited to what Node or other server-side engines support, and generally that goes back to the browser support).
ES2015/ES6 might be 2 years ago, but feature complete support isn't yet available on all major browsers. I expect, however, that ES2016 will hit complete-or-basically-complete support relatively soon after full ES2015 support. If true (or any other irregularity over time), I might be 2 years behind on ES2015 and 1 year behind on ES2016 according to their names, but I might have, say 3 months until ES2015 is an option and 8 months for ES2016.
And of course, unlike, say, Java, it's not really a yes/no choice. I tend to use const/let, native promises, fetch(), and arrow functions, but haven't yet had/found/realized a need for generators...am I behind ES2015? If 30% of ES2016 is implemented by most browsers, and I use one feature included in that 30% in 2017, am I 1 year behind?
The ES6, ES7, etc labels do an equal job (that is, not a great one) of saying how behind you are, in a more compact package.
ES2015/ES6 might be 2 years ago, but feature complete support isn't yet available on all major browsers. I expect, however, that ES2016 will hit complete-or-basically-complete support relatively soon after full ES2015 support. If true (or any other irregularity over time), I might be 2 years behind on ES2015 and 1 year behind on ES2016 according to their names, but I might have, say 3 months until ES2015 is an option and 8 months for ES2016.
And of course, unlike, say, Java, it's not really a yes/no choice. I tend to use const/let, native promises, fetch(), and arrow functions, but haven't yet had/found/realized a need for generators...am I behind ES2015? If 30% of ES2016 is implemented by most browsers, and I use one feature included in that 30% in 2017, am I 1 year behind?
The ES6, ES7, etc labels do an equal job (that is, not a great one) of saying how behind you are, in a more compact package.
Why not just call it ES'15 when spoken, and write as ES2015? Just like we do with years.
"Fifteen" isn't much worse than "seven" and this won't be an issue until for another 80 years.
"Fifteen" isn't much worse than "seven" and this won't be an issue until for another 80 years.
Because that's yet a third set of numbers referring to the versions, adding to the confusion, especially because it sounds kind of like the series of numbers it definitely isn't.
When you speak it, nobody can hear the apostrophe.
When you speak it, nobody can hear the apostrophe.
we should compromise and call it ES15, it's the "twenty" in the middle that makes it so awkward
If only we could scrap the whole ecmascript thing and force everyone to implement a language that wasn't fundamentally broken for anything more complicated than slapping event handlers on buttons.
Worth noting that Safari Technology Preview was the first browser to support all of ECMAScript 2016+ features.
* http://kangax.github.io/compat-table/es2016plus/
* http://kangax.github.io/compat-table/es2016plus/
Although IIRC Chrome and/or Firefox had all but guaranteed tail-call optimization (not a source code-level feature, obviously) first.
I don’t think that’s right. Source?
Just Chrome, but yes: http://web.archive.org/web/20160303192336/http://kangax.gith...
That shows WebKit supporting tailcalls. It doesn’t a show Chrome supporting tail calls.
I vividly remember us implementing tail calls and v8 not having them yet at that time. This was almost 2 years ago.
I vividly remember us implementing tail calls and v8 not having them yet at that time. This was almost 2 years ago.
Chrome has had them for a while. Supposedly they just hid them behind a flag because they weren't satisfied with some perceived deficiencies in the spec. (Check out https://v8project.blogspot.com/2016/04/es6-es7-and-beyond.ht...) WebKit did have it somewhere between mid-October to early December of 2015. (http://web.archive.org/web/20151207203829/http://kangax.gith...) Chrome didn't get it until late April of the next year (http://web.archive.org/web/20160526102037/http://kangax.gith...), though there's no snapshot until late May. People worked on the spec in a different order.
Chrome also had a failing array prototype under some non-standard syntax for a while. Despite claiming 100%, Kangax didn't show them passing. Test results have fluctuated as the tests themselves were refined. I've seen some passing results later turn into fails. That's why none of the browsers are at 100% for ES6 currently.
I'm still grudging at Apple for the year's delay between Safari 9 and 10, which left all the clueless Apple customers on ~53% ES6. Yes, WebKit had regular updates, but they didn't do a gradual release and few people thought to install WebKit instead of Safari (or even the TP). Other browsers had much better beta channels than Apple. And didn't pointlessly delay on things like WebRTC. Or block other browser engines like iOS to protect their app store.
Chrome did a good job of releasing updates gradually, but there are still some ES6 performance issues to be ironed out.
Chrome also had a failing array prototype under some non-standard syntax for a while. Despite claiming 100%, Kangax didn't show them passing. Test results have fluctuated as the tests themselves were refined. I've seen some passing results later turn into fails. That's why none of the browsers are at 100% for ES6 currently.
I'm still grudging at Apple for the year's delay between Safari 9 and 10, which left all the clueless Apple customers on ~53% ES6. Yes, WebKit had regular updates, but they didn't do a gradual release and few people thought to install WebKit instead of Safari (or even the TP). Other browsers had much better beta channels than Apple. And didn't pointlessly delay on things like WebRTC. Or block other browser engines like iOS to protect their app store.
Chrome did a good job of releasing updates gradually, but there are still some ES6 performance issues to be ironed out.
I'm still grudging at Apple for the year's delay between Safari 9 and 10, which left all the clueless Apple customers on ~53% ES6.
But Apple got to 100% ES6 support before anyone else: https://twitter.com/webkit/status/728643624464883712?lang=en
But Apple got to 100% ES6 support before anyone else: https://twitter.com/webkit/status/728643624464883712?lang=en
We still need to target things like IE 9 or older FF ESR releases, so Safari current status is already pretty advanced.
That's what I said.
Chrome and WebKit are two different things. So, no, you didn’t just say that.
He said that chrome and Firefox had everything except for tail call optimisation earlier.
Ha! I read your comment as: Chrome had tail calls first, but they were all but guaranteed. I was confused, but once I parsed your sentence that way there was no going back.
I am now in agreement with everything you said. Thanks for clarifying.
I am now in agreement with everything you said. Thanks for clarifying.
FWIW, I don’t think this is accurate (not that it really matters much anymore). All the browsers were in the 90+% support around the same time.
[deleted]
Another great reason to migrate Electron to WebKit. With WebKit and JSC Electron will be faster and will use a zero amount of RAM and battery!
We shouldn't be migrating Electron to anything… we should be getting rid of it. Electron is a cop-out for mediocre dev teams to make mediocre desktop apps. The result is a world where we run apps like Spotify and Slack are the main battery-killers because their engineering teams were too lazy to make a real native app.
You assume that if there wasn't Electron that those apps would exist at all.
Depends how skillful those developers are, beyond web stack tech.
Maybe if they can't invest in proper native apps, they shouldn't exist. Electron is a scourge - clock speeds are not getting any faster, and tying a user application to a single-threaded execution model would have been recognized as suicidal a decade ago.
Can't you just not use them if you don't want to, rather than wishing all other people wouldn't be able to use them either?
I can wish for something better. It's frustrating when I look at what desktop applications looked like and ran like ten or fifteen years ago, and how little has appreciably changed now, beside ballooning resource requirements.
I think what fooey meant (and what I agree with) is that what has changed now is that those apps exist at all: compared to ten or fifteen years ago, more apps are written now, they work better and on more platforms, and they are updated more frequently. Tools like Electron play a part in that.
Sure, we could wish that more effort would be spent while producing just as much. Realistically, though, that's not going to happen, and that's not due to people being lazy.
Sure, we could wish that more effort would be spent while producing just as much. Realistically, though, that's not going to happen, and that's not due to people being lazy.
Dunno about zero. Sounds hard.
Doesn't Electrino basically try this?
Currently it looks like Electrino only supports macOS. Doesn't it sort of defeat one of the purposes of using a web-based framework for desktop apps if it's not even cross-platform?
It's still web based. You can just use one wrapper for one platform and one for another. A little extra effort, but if the engine makes it worth it then why not?
I mean, the difference between rewriting an app and tweaking to compile on a different toolkit is not trivial, but I see your point
Sure thing, but I thought the idea was to use Edge on Windows?
Updated numbers with Dev versions of other browsers - https://twitter.com/bmeurer/status/871962560324657153
The difference in speed is much lesser. Wonder how this will all change by the time their technical preview actually makes it to stable.
The difference in speed is much lesser. Wonder how this will all change by the time their technical preview actually makes it to stable.
I’ve been staying away from most new ES6 features because when I tested them a year ago (either transpiled or with native support) they were slow as molasses in every browser I tried. Hopefully having some better benchmarks gets Firefox and Chrome developers to also get to work on this.
Yeah a good idea. I was thinking we could make a similar table to compat-table (maybe using six-speed or this) that we could use as data to https://github.com/babel/babel-preset-env so that Babel could compile based on the compiled speed relative to native support. Haven't really looked into in much yet (if anyone is interested, let me know)
Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.
Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.
TypeScript is a good solution for this. I use ES2015+ features this way regularly and they perform great. I target ES5 so they are transpiled at build time, and as an added bonus I get async/await which is seriously a life saver in certain situations.
Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.
Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.
Do you mean that you saw actual differences when using Javascript in a normal website? Or that they were slower than the alternatives in a synthetic benchmark? It would be really surprising that those were the performance bottlenecks.
[deleted]
Native ES6 is faster in WebKit than polyfill/transpiled.
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.
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)
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.
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.
I agree too. I wonder if this has been discussed at TC39.
Pretty much the only thing I've had problems with is generators. Regenerator runtime is so slow. Especially when making a bunch of calls with async/await
Firefox on Sierra is extremely slow. Not just javascript but everything else. Can't understand how it differs so much compared to being run on Ubuntu.
I have the exact same experience. Firefox on macOS is sluggish but on the same machine on Linux it's very responsive.
Will this translate to better performance for languages that compile to Javascript and have so far used pre-ES6 constructs?
A bit odd that they don't call it ES2015.
We were calling it ES6 since before it was called ES2015.
It will look bad they are two years behind.
How so?
Go to:
http://kangax.github.io/compat-table/es2016plus/
In STP or WebKit nightly
I think OP meant 2015 is two years ago, claiming it makes it look behind.
Truth is, ES6 is what we've called it, ES2015 is to confusing cool new name!
Truth is, ES6 is what we've called it, ES2015 is to confusing cool new name!
>> ES6 is what we've called it,
Who is "we"?
Who is "we"?
The WebKit team.
You like that question! Third time in this thread already
You like that question! Third time in this thread already
It seems reasonable for people speaking on behalf of a project to identify themselves as speaking on its behalf. The question has turned up three different people not divulging that information so far, so I think it's done the job.
We're not speaking on behalf of WebKit, merely as members of the team explaining the team's approach. Neither are we trying to hide as "not divulging" implies.
I wasn't implying deception, but if "we" means "the WebKit team" that would seem to be speaking on behalf of the WebKit team. The clarification was useful, that's all.
Our plot to express opinions about ES6 vs ES2105 as names without explicitly disclosing our affiliation in every post has been unmasked!
In before: who is "our"?
In before: who is "our"?
We like using the element of surprise:
https://www.youtube.com/watch?v=fG1TK6PdeVM
> ES6 requires completely new compiler and runtime features in order to get the same level of performance that we have with ES5.
Given that other languages mandate that additional features have zero overhead if unused, this seems like a particularly bad way of evolving a language.
Given that other languages mandate that additional features have zero overhead if unused, this seems like a particularly bad way of evolving a language.
This is huge. Jeff Atwood was right all along...
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 windows.