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

151–160 of 191 posts

Re: JSC loves ES6

#151

Post by mrout »

pjmlp wrote: post #145
kevingadd wrote: post #79

Earlier quoted context omitted.

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

I guess you missed the part where the OP wrote "while Chrome works just fine.", yet his/her coding is to blame. No wonder people move to other browsers instead.

I guess you missed the part where it was explained several times in this thread that Chrome promotes things that are slow everywhere else.

Re: JSC loves ES6

#152

Post by Sacho »

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.

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.

Re: JSC loves ES6

#153

Post by positivecomment »

allover wrote: post #143
Vinnl wrote: post #132

Earlier quoted context omitted.

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

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

Well, lack of ServiceWorker support by itself was a complaint, that's for sure: https://www.google.com/search?q=site%3Anews.ycombinator.com+...

Re: JSC loves ES6

#154

Post by 1k2ka »

projectorlochsa wrote: post #129

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.

Re: JSC loves ES6

#155

Post by Sacho »

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

Re: JSC loves ES6

#156

Post by Vinnl »

allover wrote: post #143
Vinnl wrote: post #132

Earlier quoted context omitted.

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

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

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

Re: JSC loves ES6

#157

Post by Vinnl »

douche wrote: post #74
fooey wrote: post #64

Earlier quoted context omitted.

You assume that if there wasn't Electron that those apps would exist at all.

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?

Re: JSC loves ES6

#158

Post by floatboth »

Sacho wrote: post #152
reitanqild wrote: post #96

Earlier quoted context omitted.

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.

For web apps running in normal browsers, Service Workers ARE that facade.

Re: JSC loves ES6

#159

Post by floatboth »

littlestymaar wrote: post #148
MBCook wrote: post #59

Earlier quoted context omitted.

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

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

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.

Re: JSC loves ES6

#160

Post by pfooti »

lilbobbytables wrote: post #123
donjoe wrote: 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)?

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.

Post reply on HN