TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Progress Delayed is Progress Denied (Safari feature lag)

55 点作者 tomduncalf大约 4 年前

10 条评论

ShinyNewFeature大约 4 年前
As a user, I think what&#x27;s holding back web is not the lack of APIs but how much web and browsers have repeatedly ignored user preferences, and optimized for tracking and ads. Go to any news website and it contains tons of trackers trying to fingerprint you. Then, of course, they also have to show you tons of ads leaving at most 30% of the viewport to read any content. The web is user-hostile.<p>And the leading browser (i.e., Chrome) has not really done anything to solve this problem. While Safari had cache partitioning enabled for 5+ years, Chrome has still to deliver it to users even though it&#x27;s a clear privacy and security win. Not just that, Chrome repeatedly keeps making decisions that hurt user&#x27;s privacy and expectations [1][2][3][4].<p>One simple rule of thumb that I use to compare Safari and Chrome is that Safari cares about users (privacy, gating out APIs that have risk of being misued for fingerprinting), while Chrome cares about web developers (trackers, ads, More powerful APIs). As a user, my expectations align better with the former model. I would be happy if Chrome took a step back, acknowledge user&#x27;s expectations and focus on progressing the privacy on the web instead of engaging in twitter wars.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22236106" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22236106</a> [2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24817304" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24817304</a> [3] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25337995" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25337995</a> [4] <a href="https:&#x2F;&#x2F;web.dev&#x2F;floc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.dev&#x2F;floc&#x2F;</a>
评论 #27031565 未加载
musicale大约 4 年前
I think the article conveys a fairly narrow understanding of why Apple would want to move slowly with some features in Safari on iOS. It&#x27;s a bit reminiscent of complaints about iOS Safari not supporting Flash and Java, and Apple&#x27;s reasons are likely similar: partly for business reasons, but also for reasons of user experience, security&#x2F;privacy, and battery life.<p>As an example, I like game controllers and vastly prefer them to touchscreen interfaces for most games. But Apple specifically delayed game controller support in iOS (and in Safari) to encourage developers to make games that used touchscreen controls and worked out of the box without an external game controller. The rationale was: it&#x27;s a better user experience to not have to use an external game controller, and it&#x27;s clunky to have to carry a controller around with your phone.<p>As another example, multithreaded&#x2F;parallel webasm is a great feature for developers, and it could also burn a lot of power and degrade the overall performance of the system. A rationale for delaying it could be: battery life and overall system performance are more important than performance of a single web app.<p>At the end of the day, Apple is certainly trying to make even more money, but they are also trying to figure out what the overall best user experience will be across their entire user base. This is not the same as the best developer experience, and sometimes they are in opposition.<p>Developers, for their part, can vote with their feet. If they truly believe web technology is the best way to deliver apps, then they can develop for Chrome, Electron, and platforms that support the latest bleeding-edge web tech, and ignore Safari.
评论 #27023040 未加载
alpacaillama大约 4 年前
Also interesting to note, that some of those APIs are still in W3C drafts. So Chrome just went ahead and wrote its own implementation without the literal standards body agreeing or disagreeing on them. Again, this author is extremely biased and I don&#x27;t think this article is an informative take for anyone.
评论 #27020655 未加载
评论 #27031594 未加载
coldtea大约 4 年前
&gt;<i>Apple&#x27;s iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.</i><p>Some counter points:<p>1) What&#x27;s an &quot;important feature&quot;? Whatever Chrome&#x2F;Blink rushes to implement on Google&#x27;s whim, and if often only a &quot;standard&quot; because Google designed it and pushed for it on W3C and co?<p>2) There are more than enough features to make most kinds of apps already. The more advanced features mentioned (like webcamera support) are all available in the native SDKs, and are more about full blown applications than about webpages. Where does it end? Do we have to replicate or at best wrap the whole native functionality and run it with several layers of indirection (DOM, JS, the browser backend, over html, etc)?<p>3) Android allows for web-based apps and alternative browser engines. How do those fare? Overtaking regular Android apps any time soon by any margin? If not, why would they on iOS?<p>I, for one, don&#x27;t want to use web apps on my mobile phone. If I had the choice, I&#x27;d probably prefer not to use Electron based apps on the desktop either...
alpacaillama大约 4 年前
Interesting to note that the author never mentions one of the biggest criticisms of the Chromium project. That they keep adding so many APIs that other browser vendors are forced to follow them instead of what they want to work on. This has been less apparent on mobile because Safari has a large share but not on desktop. The chromium team is known to build things that the standards body doesn&#x27;t agree on, ship it, and every other vendor is forced to support it because of Chrome&#x27;s huge marketshare on desktop otherwise their browser will appear &quot;broken&quot;. They&#x27;re angry that they can&#x27;t do this on mobile.
评论 #27026016 未加载
评论 #27024869 未加载
alpacaillama大约 4 年前
Also the author never really addresses if the API is needed or not, or if it provides a good experience. If Chrome has it, it is seen as a positive. Personally, i&#x27;m very happy that PWAs can&#x27;t spam me with &quot;You left something in your cart&quot; notifications on iOS.
评论 #27020555 未加载
montroser大约 4 年前
It is quite a racket. I don&#x27;t believe they set out to actively harm the web and open standards, but when they make _such_ a killing on app store profits, it must limit the incentives and motivation to invest in Safari&#x2F;WebKit
评论 #27020077 未加载
meisel大约 4 年前
Surprising that this isn’t getting more upvotes. It’s a very interesting read.
darkhorse13大约 4 年前
I know the author will get flak for this because this is HN, and Google Chrome has really bad reputation here (and understandably so). However, just try to develop a modern web app and you will quickly wish that all of your customers used Chrome exclusively.<p>And &quot;just make mobile apps&quot; is not the answer here. There are many situations where a web application is by far the better choice for a company or a product. It&#x27;s really a shame too, because Chrome could really use some competition.
评论 #27021488 未加载
kaliszad大约 4 年前
Yes, Safari is a pain. There are other and much bigger pains in the browser ecosystem in general, let me give some examples:<p>- The DOM is very slow&#x2F; inefficient and has a terrible API, basically owing to the mutable, object oriented way of thinking about stuff<p>- Splitting up work into a WebWorker is a hassle and so it is much less useful than it could be<p>- There are no spring&#x2F; physical animations in CSS, so if you want pretty animations, you have to hack it together using JavaScript, CSS transform or SVG animate etc. There is basically no simple framework or library that does this in a simple and efficient way, so most of the web has the basic &quot;curve&quot; animations and not the accelerate&#x2F; decelerate animations modelled after a physical (dampened) spring...<p>- It is very hard to query the progress of CSS animations and mostly you have to just guess<p>- many things in the browser have a terrible API that obscures the problem and feels almost like a very special language most of the time e.g. the &quot;History&quot; API that actually manipulates the present and maybe creates new history as a side effect of that but has nothing to do with the history of navigation on the website&#x2F; you cannot e.g. just list the entries (not even just limited to the same origin or something like that for privacy).<p>- spell check is totally broken, if you want to prevent blinking, if you want to somehow manage the suggestions in the app and much, much more. E.g. it is very hard to write a Rich Text editor and basically this leads to duplication of effort everywhere, where you want to provide a good user experience without graphical glitches<p>- there is no int64 in JavaScript leading to all sorts of hacks a correctness problems because of these hacks, there are other similarly bad language features leading to all sorts of problems (e.g. == and === comparisons and much more)<p>- E.g. in Chromium, it is not clear, how search is detected on a website (without going through the massive codebase obviously). There are known bugs sitting in the bug tracker for like 7 years without progress and that is just stuff I have seen.<p>In general, the web seems to be missing quite a bit of rigor and feels like a hodgepodge of technologies mostly lacking in any kind of overall design and discussion about usefulness. It definitely is rather a very busy and dirty bazaar after a fire instead of even the building site of a cathedral.<p>There are thousands of other things that are a problem with the way web &quot;standards&quot; are written and implemented by browsers. Safari is a problem, but the whole discussion should a lot more focused on the origins of the problems and solving the issues methodically instead of focusing on just a broad and problematic, but single manifestation of it.