Live data from Hacker News

JSC loves ES6

webkit.org

131–140 of 191 posts

Re: JSC loves ES6

#131

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.

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.

Re: JSC loves ES6

#132
post #59
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…

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

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.)

Re: JSC loves ES6

#133
post #22

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.

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.

Re: JSC loves ES6

#134

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.

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

Interesting. What is that thing exactly? Is there a bug we can follow?

Re: JSC loves ES6

#135
post #89

Earlier quoted context omitted.

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

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://ww…

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.

Re: JSC loves ES6

#136
post #112

Earlier quoted context omitted.

...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)?

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.

Re: JSC loves ES6

#137
post #128

Earlier quoted context omitted.

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.

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"?

Re: JSC loves ES6

#138

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.

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.

Re: JSC loves ES6

#139

Earlier quoted context omitted.

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

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.

Post reply on HN