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

121–130 of 191 posts

Re: JSC loves ES6

#121

Post by alwillis »

imron wrote: post #94
alwillis wrote: post #80

Earlier quoted context omitted.

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

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

That's correct; I got that reversed.

Re: JSC loves ES6

#122

Post by alwillis »

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

Earlier quoted context omitted.

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

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

I got my numbers mixed up--Apple pays developers 70%, so the total revenue is "only" $100 billion and not $233 billion.

Re: JSC loves ES6

#123

Post by lilbobbytables »

donjoe wrote: post #112
millstone wrote: post #100

Earlier quoted context omitted.

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

Re: JSC loves ES6

#124

Post by alwillis »

untog wrote: post #89
alwillis wrote: post #80

Earlier quoted context omitted.

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications. I’m pretty sure 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…

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

Re: JSC loves ES6

#125

Post by donjoe »

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

Well, service workers do run in a separate thread which finally brings multithreading (not multi-iframing ;)) to javascript.

Re: JSC loves ES6

#126

Post by jfbastien »

donjoe wrote: post #125
lilbobbytables wrote: post #123

Earlier quoted context omitted.

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

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

Re: JSC loves ES6

#127

Post by pjmlp »

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

Earlier quoted context omitted.

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

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

It is yet another hack web developers come up with, as workaround for offline apps.

Re: JSC loves ES6

#128

Post by djur »

jfbastien wrote: post #113
hoodoof wrote: post #82

Earlier quoted context omitted.

>> ES6 is what we've called it, Who is "we"?

The WebKit team. 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.

Re: JSC loves ES6

#130

Post by jfbastien »

djur wrote: post #128
jfbastien wrote: post #113

Earlier quoted context omitted.

The WebKit team. 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.
Post reply on HN