Safari works amazingly for small websites, but for websites with infinite scrolling like Tumblr and Twitter, it becomes unbearably slow after the first hundred or so posts. Historically, Safari is slow to adopt new web features, and it STILL doesn't have web push notifications (and more).
You can run these same websites on Android Chrome just fine, even on a lower-powered Android phone. I'm not sure if they're using APIs that need to be polyfilled on Safari, or if Safari is just trash.
At this time, I'm convinced that if Apple allowed other browser engines on the App Store, this would not be a problem at all, not that I can test it out anyways.
I can’t speak on Tumblr, but the issue is even worse than “unbearably slow” on Twitter.
Once I’m down about 50ish posts on my feed, hitting back from a post to get back to the feed seems to have around a 25% chance to quickly throw a “Safari has detected a problem” error and force a refresh - sending me back to the top of the feed. And this is on an iPhone 12 Pro Max so it’s not like the hardware is out of date.
I primarily blame Safari, but on some level I think Twitter is aware of the problem and has no intentions of fixing it. The mobile Twitter site is purposely designed to make it nearly impossible to open a tweet in a background tab if it doesn’t have an image (the browser tries to select text on a long press). That’s clearly something Twitter could fix if they wanted to.
Twitter's mobile problem isn't specific to Safari. The initial load of any tweet on my Android Firefox is ~20 seconds. Every subsequent action takes at least a full second. Couple that with the huge "it's better on the app" banners you get every time you try to do anything, and it's obvious that Twitter is intentionally neglecting mobile web.
(I've got an oldish phone, but it performs fine on every website I ever visit except Twitter.)
I think all the 'social media' platforms really want you to install their software onto your device anyway. I suspect they could make it work in the browser if that made sense for their business, but they would rather be on your home screen.
Good. These features need to be supported by browsers for an extremely long time and Google is trying to force garbage under the guise of "standards." I hope Apple continues to fight against the ridiculous power hungry feature creep.
I don't build websites with infinite scroll or enough data that would justify it nor attract enough visitors to punish a t2.micro, so I have no first hand experience with any of that.
However, curiosity requires that I ask what/how/why does any of that affect mobile-first web deployment in away that it is not addressed when a large chunk of that mobile use is broken? If you program yourself into a dead end, back up and take another turn.
Oh, it is easier in a mobile native where you get the benefit of hoovering up personal data on all of your users? Gee, let's not expend effort to make something work universally, let's instead take the easy route and make money on the side too. The fact that losing this large share of users because of one type of content is not enough of a decision to go the other route shows just how much money there is in the hoovering of data.
If I understand what you're trying to say correctly, I need to say that I'm speaking fully from a user experience standpoint as an end user. I am not a Tumblr engineer. Anecdotally, out of the few people I know that still use Tumblr, they use desktop and mobile Chrome to access the website. I don't have any statistics on how many people use the apps.
So, to me, Tumblr's website is already the main point of access, and these performance problems don't exist on Firefox or Chrome. I'm not talking about server-side response times, I'm talking about the time to render posts on the client. I find that a lot of times, after scrolling, you have to wait a few seconds before you see anything but the blue background that Tumblr has.
So, no, I'm going to pin it on Safari if (even) Firefox can deal with it.
This is the second time you've said it's about "hoovering up data".
Yahoo runs one of the biggest ad networks in the world, and you need to register to use Tumblr. They as already have everything they need to track you right there.
A mobile app in many circumstances reduces the data tracking (see this whole discussion about how effective Apple's do not track is because of their monopoly powers).
Just because Apple made it harder doesn't mean they made it impossible. There's a reason so many places work on making apps for multiple platforms (at least 2) rather than a unified web experience. There are benefits beyond serving a webpage in a native app, and they all want those benefits. Stick your head in the sand and deny it all you want, but it still happens.
> Safari works amazingly for small websites, but for websites with infinite scrolling like Tumblr and Twitter, it becomes unbearably slow after the first hundred or so posts.
That's absolutely not true, even if the web developer implements this in the Dumbest Possible Way. Please point me to an example page and prove me wrong.
On M1 Max with Safari 15.5, it took me about 40 seconds of fast scrolling to get it to start stuttering occasionally. Then, another 30 seconds to get it to start blanking out for a second at a time. And finally, another 30 seconds to get it to start taking seconds to render. I won't give the number of posts before it started lagging because I don't know the exact number.
On my phone (iPhone 13 Pro Max, albeit on the iOS 16 beta), it takes Safari about 15 seconds of scrolling before the scrolling drops to around 40fps from what looked close to 120fps. Then, another 20 seconds to start seeing things rendering halfway before jumping around and then rendering the correct post. This isn't necessarily a fair comparison due to the usage of beta software, but even on an M1 on production OS software it doesn't seem to be much better. Chrome 102 on macOS handles the exact thing that I did without any problem at all.
It's especially bad when you have a lot of videos on your dashboard. If you only have image posts, it might take a bit longer to start stuttering.
This has been the case for years, so it's nothing new. I remember this being a problem almost a decade ago, on an 4th generation iPad with the A6X SoC. Things have improved since then for sure, but those it's probably mostly hardware improvements that's helping.
I'll accept blaming Twitter's horrible performance on its use of React Native Web, but not Tumblr.
I have to give you credit for going this far into proving whatever we're trying to prove. However, who the hell in the real world infinite scroll this much? Some people do things that would make any QA team more valuable, and you're starting to sound like someone I'd love to have on any QA team I'd work along side.
This really sounds like one of those issues a dedicated person finds where the devs look at it and say no reasonable user would ever do this. The issue if not closed as "won't fix" gets deprioritized so low that it never gets looked at again. Even as a dev, I'd not have the patience to recreate the problem. It's just such an outside edge case from expected behavior/usage that I don't even know what to say in response.
You're correct. Any website that has so much worthless content that it all gets scrolled passed that quickly without catching my attention to read further is not going to a site I visit regularly after that initial visit.
I honestly worry for people that do. There's something sad to me about people that do.
> if Apple allowed other browser engines on the App Store
You mean Gecko or Blink? WebKit is really not the problem. Web Developers' strict compliance to only make sure their site works on Windows may be part of it.
Unfortunately Firefox on iPhone uses Safari under the hood. Apple doesn't allow any 3rd party browser engines on their mobile devices. It's 100% Safari. Chrome and Firefox can be thought of as UI reskins.
It's a bit like saying 'let them fly on private jets' and someone pointing out that only a few people in the population can afford it. Doesn't imply that private jets are useless, just that their use is limited.
Anyone with access to a computer (a prerequisite to use software in this context in the first place[0]), also has access to the tools to learn to perform these actions.
Pretty sure most people don't have the ability to teach themselves to fly a private jet and then walk up and take off.
[0] Setting aside phones/mobile. Yes they exist, yes they're important. No they're not relevant to this thread.
How so? NVIDIA GPUs have their own APIs, AMD does, Direct3D is its own. The Apple platform acceleration APIs are Metal. The MS acceleration APIs are all generally Direct3D, etc.
The fact the you want Apple to support other platforms doesn't mean that they're wrong for not doing so. They same arguments to require Apple to support your preferred API also applies to MS, NVIDIA, AMD, etc and the same arguments to not do that apply them all as well.
That other companies use shitty proprietary code to lock out competition doesn't make Apples attempt to do the same any better. It compounds the error and wasted effort. In fact Apple's is the worst of the lot you mention because at least you can use alternatives with the others.
Apple’s is the result of their experience promoting OpenGL and OpenCL. They found GL and CL both remained resolutely in the past, and people also seemed resolutely opposed to using them.
So GL and CL had to make a compelling argument for why apple should continue to invest in the technology, and even now they still aren’t able to show a single compelling argument for them being better than any alternative.
Personally I would have rather a single open API, but the open API did not appear to be super interested in competing with the other platforms. The end result is the open platforms turn into a pile of expense, licensing, and engineering for behind the curve technology and API.
They don't have to develop it. They just have to not prevent it from existing. If theirs is genuinely better, it will get used. But Apple is too scared to openly compete so they lock down and artificially limit competition.
Anyone can implement the opencl and OpenGL APIs on top of metal. Apple isn’t preventing that.
But native OpenGL requires apple writing OpenGL implementations for their hardware. It requires apple spending engineering time implementing misfeatures from OpenGL and opencl in order to support APIs that are only every considered the backup API.
What about Vulkan? They’d need to implement the same crummy APIs and semantics (that is a bunch of kernel and similar work) for an API that NVIDIA and AMD were both uninterested in.
And again, anyone could have made a Vulkan emulation layer on metal.
It's even worse than that. Right before that, the article claims that the Chinese language is "almost the same as the first inscriptions from nearly 3,200 years ago".
If low-level embedded coding "is not different from any other C development", that's not really a positive remark about C. No wonder that software defects are so common in C code.
What are you expecting to be so different? You call the right functions with the right arguments to get it to do what you want. What language do you use that you can program by calling the wrong function with the wrong arguments?
