Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Safari Technology Preview

webkit.org

Post reply on HN
Print view View original

161–170 of 176 posts

Re: Introducing Safari Technology Preview

#161

Post by coldtea »

crabasa wrote: post #142
coldtea wrote: post #137

Earlier quoted context omitted.

> IE executed a "developer preview" strategy leading up to IE9 6 years ago. I should know, I was a PM on that team. That (Safari adopting "developer previews" now) doesn't mean much regarding whether Safari is the new IE. When people say that phrase they don't mean their both trying (or having tried) developer previews. They mean whether Safari is as backwards and holding the web back as IE6 was for ages. Which is no…

> They mean whether Safari is as backwards and holding the web back as IE6 was for ages. Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps. > while Safari was... at the top of the heap Lol? I know very few (none?) web developers who uses Safari as their primary target browser. ES6 support or not. > cherry picked pro-Safari blog post https://jo…

>Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps.

That's a classic tinfoil theory, but with absolutely no substance.

First, Apple sells hardware, first and foremost, not apps (it's the inverse with Microsoft). Their app store profits are negligible compared to all else.

Second, Apple has consistently made the best mobile web browser for many years -- Android had the horrible crippled Android Browser which was not even competing, before Chrome became competitive there.

That's not what you do when you want to cripple mobile apps -- which few users care about anyway, the money (for developers) and the convenience (for users) are at native apps.

Do you see "mobile apps" thriving in Android or MS Phone compared to native apps? Because I do not.

>Lol? I know very few (none?) web developers who uses Safari as their primary target browser. ES6 support or not.

What Lol? Safari's engine is what Chrome has been based on, and for most of its life it has been one and the same codebase.

Developers just don't prefer Safari's developer tools compared to Chrome's -- and of course Chrome is more popular (and cross platform), so it makes sense to use what most users use. Back in the day all developers used FF and its dev tools too, for similar reasons.

Re: Introducing Safari Technology Preview

#162

Post by Natanael_L »

coldtea wrote: post #161
crabasa wrote: post #142

Earlier quoted context omitted.

> They mean whether Safari is as backwards and holding the web back as IE6 was for ages. Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps. > while Safari was... at the top of the heap Lol? I know very few (none?) web developers who uses Safari as their primary target browser. ES6 support or not. > cherry picked pro-Safari blog post https://jo…

> Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps. That's a classic tinfoil theory, but with absolutely no substance. First, Apple sells hardware, first and foremost, not apps (it's the inverse with Microsoft). Their app store profits are negligible compared to all else. Second, Apple has consistently made the best mobile web browser for man…

Fennec / Firefox Mobile

Re: Introducing Safari Technology Preview

#163

Post by agopaul »

Alex3917 wrote: post #56
sergiotapia wrote: post #35

Programmatic cut and copy to the clipboard It’s now possible to programmatically copy and cut text in response to a user gesture with document.execCommand('copy') and document.execCommand('cut'). Having this ability may eliminate some websites’ last need for the Flash plug-in. --- :'( - So much pain erased in a single stroke!

Unfortunately as far as I know the text selection API is still broken on mobile Safari. At least as of a few weeks ago the JS events associated with force touch seem to randomly wipe out the text selection, so even if you can now theoretically copy stuff to the clipboard it's largely irrelevant if users can't actually select text in the first place.

That sucks. But (Desktop) Chrome/webkit selection has been partly broken too for a few years now.

https://bugs.webkit.org/show_bug.cgi?id=66630

https://bugs.chromium.org/p/chromium/issues/detail?id=346613

I've been dealing with this stuff for the last week.

Edit: added webkit reference

Re: Introducing Safari Technology Preview

#164

Post by hughw »

coldtea wrote: post #138
chris_wot wrote: post #17

Earlier quoted context omitted.

Their time to fix bugs and regressions in iOS is 3 months! Edit: Again, I write a very unpopular opinion. Yet there are hundreds of regressions that have bit developers. Some of those bugs require workarounds that would be otherwise unnecessary on any normal environment with rapid updates - like Chrome or Firefox. That increases developer effort, and there have been cases that Apple have entirely missed their update…

> Their time to fix bugs and regressions in iOS is 3 months! So? There are open bugs, including VERY annoying/visible ones, for Chrome that languish for half a decade on its bug page, despite tons of votes...

Three month bug fixes is distinctly un-IE-like. IE preserved broken behavior for years, as a matter of policy.

Re: Introducing Safari Technology Preview

#165

Post by ksherlock » 

    fetch("...");
    Promise {status: "rejected", result: "Fetch is not yet implemented"} = $1
If you use a fetch polyfill, it won't install itself because there's a native fetch. But the native fetch is only there to tell you that it's not really there.

Re: Introducing Safari Technology Preview

#166

Post by chris_wot »

dang wrote: post #144
chris_wot wrote: post #129

Earlier quoted context omitted.

I don't care how much I've been downvoted, especially by someone who contributes their own comments so infrequently to HN, but it's funny how you only now decided to make a comment. I personally feel that Apple are still not as good as not only I want them to be, but pretty much anyone who uses or develops for iOS. But yes, you categorize my comments and opinions well - Apple are indeed not very responsive, and yes A…

Please don't go on about getting downvoted in HN comments. The guidelines explicitly ask everyone not to do that, because it's tedious. https://news.ycombinator.com/newsguidelines.html

OK, and what about those who tell me that I'm off topic when I'm not? Or those who don't look at my wider point and accuse me of bad faith comments?

My only comment was that my score was going up and down like a yo-yo, and only because I was being accused of making off-topic comments. That's pretty tedious, no? Surely that's against HN guidelines?

Re: Introducing Safari Technology Preview

#167

Post by Alex3917 »

om2 wrote: post #154
Alex3917 wrote: post #118

Earlier quoted context omitted.

I think my cofounder already did, I'll check. The basic issue we were encountering is that when selecting text via force touching and then dragging the selection, the text selection object was empty. (Though you can still hit Copy in the Safari UI.) There wasn't any issue when selecting text via regular press or long press.

If you throw me a bug number (here or privately) I'll take a look.

OK the bug number is 25465034. Thanks!

Re: Introducing Safari Technology Preview

#168

Post by gsnedders »

om2 wrote: post #151
gsnedders wrote: post #140

Earlier quoted context omitted.

> And Safari saves like 20% to 30% of your battery life over Chrome... > And both are due to Apple's own JIT engine... I feel like that claim needs a source. I'd be amazed if the JS engine had anywhere near such a substantial effect on battery life.

The JS engine is not the only reason for Safari/WebKit's superior battery life but it's definitely one contributing factor. When loading webpages, one of the most important factors to saving power is reaching an idle state as quickly as possible. For many pages, that requires being fast at executing JS that runs only once or only a few times. Safari dominates on this, thanks to WebKit and JavaScriptCore. You can see…

But given most JS code in the real-world is mostly dominated by DOM performance, and not JS engine performance. Certainly JSC's llint gives it a substantial benefit over V8 on cold code, but I'd be surprised if it accounted for even the majority of the battery life gain. I'm not questioning Safari's lead here, just how it's so much better. (I think the lead is clear, with perhaps only Edge getting close, but that's hard to compare.)

Re: Introducing Safari Technology Preview

#169

Post by om2 »

gsnedders wrote: post #168
om2 wrote: post #151

Earlier quoted context omitted.

The JS engine is not the only reason for Safari/WebKit's superior battery life but it's definitely one contributing factor. When loading webpages, one of the most important factors to saving power is reaching an idle state as quickly as possible. For many pages, that requires being fast at executing JS that runs only once or only a few times. Safari dominates on this, thanks to WebKit and JavaScriptCore. You can see…

But given most JS code in the real-world is mostly dominated by DOM performance, and not JS engine performance. Certainly JSC's llint gives it a substantial benefit over V8 on cold code, but I'd be surprised if it accounted for even the majority of the battery life gain. I'm not questioning Safari's lead here, just how it's so much better. (I think the lead is clear, with perhaps only Edge getting close, but that's h…

Like I said, the JS engine is likely not the main factor. But it does make a difference. I don't have a detailed breakdown to share but we do measure these things. :-) The prior poster was wrong to imply it's all down to the JS engine, but swapping WebKit for Blink would very likely hurt our battery life.

Windows itself has worse battery life than OS X on identical hardware, so it's hard to compare Mac browsers to Windows browsers. Safari on OS X is the best laptop browsing power efficiency you can get, and likely the best battery life barring laptops with super huge batteries.

Re: Introducing Safari Technology Preview

#170

Post by dang »

chris_wot wrote: post #166
dang wrote: post #144

Earlier quoted context omitted.

Please don't go on about getting downvoted in HN comments. The guidelines explicitly ask everyone not to do that, because it's tedious. https://news.ycombinator.com/newsguidelines.html

OK, and what about those who tell me that I'm off topic when I'm not? Or those who don't look at my wider point and accuse me of bad faith comments? My only comment was that my score was going up and down like a yo-yo, and only because I was being accused of making off-topic comments. That's pretty tedious, no? Surely that's against HN guidelines?

There certainly are other tedious things besides that tedious thing, but still, please don't do it, even if provoked.

Being a good HN commenter in the long run means learning to eat provocation, which admittedly sucks, but is true community service.

Post reply on HN