171–180 of 191 posts
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.
Earlier quoted context omitted.
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"?
Earlier quoted context omitted.
"Registration requires an Apple developer license." 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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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).
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
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.
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.
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…
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.
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.
Earlier quoted context omitted.
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.
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.