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

151–160 of 176 posts

Re: Introducing Safari Technology Preview

#151

Post by om2 »

gsnedders wrote: post #140
coldtea wrote: post #139

Earlier quoted context omitted.

Only Safari (betas) have better ES6 support than Chrome ones according to a latest article on Ars. And Safari saves like 20% to 30% of your battery life over Chrome... http://bgr.com/2015/08/05/google-chrome-vs-safari-battery-li... http://www.theverge.com/2015/4/10/8381447/chrome-macbook-bat... And both are due to Apple's own JIT engine...

> 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 this on JSBench, which runs JS modeled on real page loads and interactions: http://plg.uwaterloo.ca/~dynjs/jsbench/

I applaud Chrome's recent work on battery life. But I think it would be fair to say that safari is still the best in this area. And also that our excellent results have inspired Chrome and others to do better, much as in an earlier era Chrome inspired other browsers to get more serious about JS performance.

Re: Introducing Safari Technology Preview

#152

Post by om2 »

blackkettle wrote: post #150
jaredcwhite wrote: post #6

Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously. This is another positive step in the right direction. While I never agreed with the nonsensical "Safari is the New IE" meme that was going around, I did fear that Apple's tendency to develop things in a vacuum would continue to harm WebKit relative to Blink, Gecko, etc. But all signs are pointing…

IMHO, until they decide to provide proper HTML5 support - particularly access to the getUserMedia and general WebRTC APIs - or at least allow 3rd party vendors like Google and Mozilla to do so by themselves, this is not a believable sentiment.

Media Capture and WebRTC are in development in the public WebKit repository.

These features aren't really part of HTML5 though. And while some web apps really need these features, most would not use them at all. So I'm curious why this in particular is your litmus test.

I think an even wider range of web apps will benefit from our IndexedDB revamp, Shadow DOM, ES6, fast tap, font-feature-settings, picture element, CSS Variables, and other cool stuff we shipped recently or have in the works.

Re: Introducing Safari Technology Preview

#153

Post by om2 »

crabasa wrote: post #134
jaredcwhite wrote: post #6

Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously. This is another positive step in the right direction. While I never agreed with the nonsensical "Safari is the New IE" meme that was going around, I did fear that Apple's tendency to develop things in a vacuum would continue to harm WebKit relative to Blink, Gecko, etc. But all signs are pointing…

Safari IS the new IE. Proof? IE executed a "developer preview" strategy leading up to IE9 6 years ago. I should know, I was a PM on that team. http://arstechnica.com/information-technology/2010/10/ie9-pr... This entire episode is just a rinse and repeat of what MSFT did years ago in response to negative developer sentiment.

Despite the similar name, Safari Technology Preview is a very different product concept from the old IE9 Developer Previews. It's not a series of one-shot early betas, but rather a live evergreen view onto coming developments.

In that respect, it's much more like Chrome's Dev Channel or Canary, or Firefox's Developer Edition, then like these old preview builds.

Re: Introducing Safari Technology Preview

#154

Post by om2 »

Alex3917 wrote: post #118
om2 wrote: post #116

Earlier quoted context omitted.

Can you file a bug with a specific example or two? http://bugs.webkit.org/

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.

Re: Introducing Safari Technology Preview

#155

Post by ttepasse »

ino wrote: post #126
kingnight wrote: post #110

I find Safari to be the nicest browser to use in general, but Chrome seems to have a leg up on performance in key areas like new tab creation especially when opening a link in a new tab. It's weird lapse for Safari to lag in certain situations. I hope they continue to iteratively improve the performance of the general UI and improve the general behavior of the developer tools in addition to adding these new techs.

If you change the new tab to a blank page in the preferences, it opens instantly. I just wish one thing: that it would remember the zoom level on a per website basis. It's incredible that it's still impossible to do so. Don't the devs use Safari? Or maybe they all have perfect vision and the most expensive displays.

An extension helps with per site zoom factors. I use ZoomBySite but while looking if it is also in the new extension gallery I found Zoom. Untested.

http://www.cerimorgan.com/products/zoombysite/ https://safari-extensions.apple.com/details/?id=com.stefanvd...

Re: Introducing Safari Technology Preview

#156

Post by matt4077 »

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…

What does "Primary target browser" even mean? Many (me included) prefer Chrome as a dev browser because the dev tools are better and many extensions are only available for chrome (react dev tools etc.). But at the end of the day, you need to support Safari (which usually isn't a problem).

Off topic tip: I've had success with the Safari dev tools on some issues that I couldn't debug on chrome. Sometimes it's worth trying both.

Re: Introducing Safari Technology Preview

#157

Post by matt4077 »

kingnight wrote: post #110

I find Safari to be the nicest browser to use in general, but Chrome seems to have a leg up on performance in key areas like new tab creation especially when opening a link in a new tab. It's weird lapse for Safari to lag in certain situations. I hope they continue to iteratively improve the performance of the general UI and improve the general behavior of the developer tools in addition to adding these new techs.

Indeed – Chrome is notably faster on my Macbook. On the desktop with a 6700K and Samsung 950 Pro SSD the difference becomes meaningless and I prefer Keychain/Reading list/iCloud to their chrome equivalents.

Also, chrome gives you a 5px^2 area of "chrome" to drag the window around which is seriously annoying.

Re: Introducing Safari Technology Preview

#158

Post by heelhook »

bartvk wrote: post #132
ino wrote: post #126

Earlier quoted context omitted.

If you change the new tab to a blank page in the preferences, it opens instantly. I just wish one thing: that it would remember the zoom level on a per website basis. It's incredible that it's still impossible to do so. Don't the devs use Safari? Or maybe they all have perfect vision and the most expensive displays.

In my case, it lags (up to two-three seconds) even if I set new tabs to about:blank. Haven't been able to find a workaround, and it occurs infrequently.

You might want to try doing a SCM reset. I was having the same issue and did an SMC and noticed that opening a new tab went back to being instantaneous (also using about:blank).

Re: Introducing Safari Technology Preview

#159

Post by chmaynard »

ino wrote: post #126
kingnight wrote: post #110

I find Safari to be the nicest browser to use in general, but Chrome seems to have a leg up on performance in key areas like new tab creation especially when opening a link in a new tab. It's weird lapse for Safari to lag in certain situations. I hope they continue to iteratively improve the performance of the general UI and improve the general behavior of the developer tools in addition to adding these new techs.

If you change the new tab to a blank page in the preferences, it opens instantly. I just wish one thing: that it would remember the zoom level on a per website basis. It's incredible that it's still impossible to do so. Don't the devs use Safari? Or maybe they all have perfect vision and the most expensive displays.

Like you, I’m constantly zooming in or out because there is so much variation in font sizes and layouts. I wonder if Safari could be programmed to automatically adjust the zoom level of every web page, based on my preferred viewing style. Safari would need to take into account things such as preferred font size, current window size, etc.

Re: Introducing Safari Technology Preview

#160

Post by justabystander »

alwillis wrote: post #141
wyqydsyq wrote: post #131

Earlier quoted context omitted.

The problem isn't necessarily Apple's laziness with updating Safari, I think it's more the fact that they insist on using their own JavaScript engine. They could very easily just use Blink and V8 which would significantly cut down the maintenance work in keeping Safari up to date as well as leveraging the work already done rather than trying to reinvent the wheel to nobody's benefit. For example most ES2015 features…

WebKit supports 98% of ES2015, more than any other major browser engine, so keeping pace isn’t a problem for Apple: https://kangax.github.io/compat-table/es6/ Now with Safari Technical Preview, if you want access to all of it in a more accessible package than the WebKit Nightlies, you can have it. BTW, Apple has been doing what appears to be a amazingly good work on JavaScript Core lately, extending their performance…

You realize that although WebKit supports 98%, Safari itself as of version 9 supports 53%. As is noted in your own link to the compatibility table. So, yes, keeping pace is a problem for Apple, since the other browsers are significantly ahead and the Safari 9 series was released half a year ago. Even Microsoft Edge has been doing better.

You might actually have a leg to stand on when Safari 9.1, released 10 days ago, gets its ES6 state tested and uploaded to the compatibility table. Or it might be more embarrassment about Apple's slow release cycle. It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state. Once again, tests will tell. What is certain for now is that six months of Safari have left it at 53%, which, among many other examples, has been Safari dragging everyone else down.

Just because they have untested, unsupported code in a development branch doesn't mean that their main browser with a completely different name and a glacial release cycle gets a pass for holding up the class. The Tech Preview is a good starting step, but until these things have a clear release cycle that shows current WebKit ES6 feature support making its way into a release build before the end of the year, we'll continue to be upset at them with cause.

Post reply on HN