Ouch ouch ouch ouch ouch. Flagged the submission for this reason, it’s going to cause severe problems for lots of people, and being GIFs and so enormous they don’t even load well (when I start loading even the first GIF by itself, it spends a lot of its time loading at below one frame per second). The GIFs should be removed urgently and replaced with static images and links to videos.
Interesting, via iOS safari the page was quick to load and scrolled smoothly, no noticeable performance issue (excepting the payload size is excessive).
Worked fine for me on AOSP8 with Iceweasel on Honor 9 too, albeit on ac wireless with 400Mbps connection (at least I didn't notice any slowdowns, and this is hardly top of the line hw or sw).
Meh. I am finding myself enjoying simpler calendars. It's a cute gimmick for like, playing with. But I prefer simpler for things I have to use all the time.
I'm always very careful whenever apple release new technologies for devs. They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
> They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
Large chunks of macOS 11 and iOS 14 are built with SwiftUI, and it's the only way you can build the newer style of widgets on both platforms. They're actually pretty aggressively dogfooding it.
They were slow to pick up Swift internally because they needed ABI stability, but no such barriers exist for internal adoption of SwiftUI.
I'm using it to port an auv3 plugin to a standalone app. The overall experience is amazing when compared to the constraint based method proposed in previous xcode versions. There are parts missing, but it's fairly easy to wrap uikit components and use them in swiftui
It's a neat technology but still quite infant. I've heard that it currently takes longer to implement a non-trivial UI due to the compiler errors, documentation gaps, and bugs with the framework. Patience is required.
The latest stuff in beta since WWDC makes a world of difference. It’s a joy to play with, and I haven’t encountered any of the impenetrable compiler errors that the last version had.
FYI you can use ffmpeg to encode gif as h264/h265 mp4 videos of varying quality or convert to webm which can be played from an img tag, all of which will be orders of magnitude smaller.
That’s still very unreasonably large and is going to cause real problems for some users, though not as many (and is still going to be uselessly slow to load for many—much of the world, including where large numbers of developers, even SwiftUI developers, are, doesn’t have multi-megabit-per-second speeds). Look, even 20MB is too large. Please, I beg you, just don’t put any GIFs on that page: just make it clear that it’s a video, e.g. by overlaying a circled play icon on the image and making it a link to the relevant video on YouTube.
I've flagged the title; it is incredibly poor etiquette to sneak half a gig in downloads on a user, especially when demonstrating something for mobile!
No, don’t put it in the title, just fix the page. A page being even 100MB would be wildly unacceptable, let alone 450MB.
The really quick fix is just to replace the images with links to the images. Anything fancier (like replacing them with static images and links to actual videos rather than GIFs) can come later.
Please. I’m not trying to be mean in any way, but words are failing me at just how bad this is. You just don’t do this sort of thing. Entirely genuinely, you have probably directly cost at least a dozen people a few dollars with these GIFs, and measurably (sometimes seriously) inconvenienced dozens more for up to a month due to limits reached or approached.
45 comments
[ 2.4 ms ] story [ 112 ms ] threadI know you want to show off the buttery smoothness of your animations, but do you really need to dump >200MBs of gifs on that single page?
Holy laptop fan smoke!
Maybe safari is more optimized for gifs?
SwifUI is a breath of fresh air compared to xcode builder, that giant unmergeable xml and the constraint madness where really clumsy to work with.
I'm always very careful whenever apple release new technologies for devs. They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
Large chunks of macOS 11 and iOS 14 are built with SwiftUI, and it's the only way you can build the newer style of widgets on both platforms. They're actually pretty aggressively dogfooding it.
They were slow to pick up Swift internally because they needed ABI stability, but no such barriers exist for internal adoption of SwiftUI.
Overall I think it's a great step forward
Simplest form: ffmpeg -i foo.gif -c:v libx264 -crf 22 foo.mp4
You can vary crf to change the size to quality trade-off.
(It's mentioned in the README, but thought it was worth calling out.)
Please put that in your title.
[1]: https://tools.pingdom.com/#5cd8c1fc83000000
The really quick fix is just to replace the images with links to the images. Anything fancier (like replacing them with static images and links to actual videos rather than GIFs) can come later.
Please. I’m not trying to be mean in any way, but words are failing me at just how bad this is. You just don’t do this sort of thing. Entirely genuinely, you have probably directly cost at least a dozen people a few dollars with these GIFs, and measurably (sometimes seriously) inconvenienced dozens more for up to a month due to limits reached or approached.