It’s fascinating to see so many implementations targeting the same thing, along with the crazy variation in runtime size. I’d love to see memory usage comparisons too but I suppose you’d need to establish what you’re actually measuring first.
A few years ago I started work on a kind of abstraction layer that would let you plug Rust code into multiple different engines. Got as far as a proof of concept for JavascriptCore and QuickJS (at the time I had iOS and Android in mind as targets). I still think there’s some value in the idea, to avoid making too heavy a bet on one single JS engine.
I actually captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.
Thanks! I'm hoping to continue down this path and write up some thoughts on how you might actually achieve seamless in-app webviews at some point but, y'know... time.
In the meantime (hey, it's already a thread of self-promotion) my last writeup was about the native views WKWebView generates when you use hardware accelerated CSS transforms:
This is interesting! If anyone from WebKit is in the comments, can you provide link(s) to the bugs discussing the bytecode caching API? I'd love to take a look but my Bugzilla search skills are evidently weak.
It's a pretty fascinating feature set. You can attach images, update the content of an existing notification, attach buttons to perform custom actions, choose to make it silent or not... I think there is more utility than most implementations in the wild would suggest. One fascinating aspect of it for me is that you can do very time limited things (e.g. send election results) - users might be reluctant to download an entire app just for one evening of updates, but being able to send notification through the browser sidesteps that entirely (and more broadly, it puts a useful tool in the hands of people who can't afford native development).
That said, I agree that it's total madness that the default UI allows you to ask for permission on page load. We always had the prompt behind a button on the page and it worked great, so I think Mozilla have the right idea here.
This is a really interesting development. I've been poking around with making a cross-platform library lately, and had settled on Go because it does such a great job of building for iOS and Android simply (though the go bind tool), but the implementation feels a little messy because the nature of Go (e.g., no classes, property accessors, etc) doesn't translate easily to Objective-C or Java. So Kotlin might be a really interesting alternative here.
How about Flutter with Dart? It uses AOT so plays well with IOs. But granted, their approaches are very different as Flutter renders most things by itself.
The project I'm working on doesn't use any UI (that's still native), so I'd disregarded Flutter - but perhaps that's not fair. Looking at it, it seems to have straightforward ways to use native functionality, but I'm not 100% sure how I might go about exposing Dart classes/methods/etc to existing native code. Worth looking into, though - thanks!
I'd disagree with your assertion that it's not that much work :) Service Workers are their own self-contained JavaScript environments with complicated lifecycles after all.
That said, I've been surprised by now much is possible just using public APIs, but I'm not sure you could pull request a full OS implementation. For example, adding an app to home screen. That's going to need to wire into non-WebKit iOS and macOS code, which AFAIK is not open source. Workers also sometimes run when the browser is not active, and that wouldn't be a trivial thing to add.
Also, Apple started working on the Service Worker APIs recently. It's not clear exactly how much they'll implement, but it's a very positive step.
The main reason is that the phone will download the image each time you post a notification, and with 650 alerts throughout the night (for 650 constituencies) the user would end up downloading a lot of data with very little to show for it (since newer notifications replace the older ones).
But to add to that, it needed to be customised for different screen sizes. So we'd have to have generated a lot of versions server side.
You can't use an SVG as an image in a notification. A real shame as it would have solved all the device pixel ratio problems, but the SVG spec is absolutely huge (and includes stuff like animation) so I'm not overly surprised that Android doesn't support it.
Hmm, I'm wondering if there's a way now to render an SVG (not the full spec) within a service worker e.g. using PngPong with https://github.com/canvg/canvg
Huh! That's a really fascinating library. My gut instinct is still that it would be a heavy lift, though. Without the Canvas API in the middle you'd need to reimplement pixel by pixel drawing of different shape/curves (PngPong literally only draws squares and copies sections of other images) anti-aliasing, etc. etc.
It would be a fascinating thing to work on, but the OffscreenCanvas API is coming to Chrome[1], so I suspect it would end up being a lot of work that would be obselete after not all that much time.
> especially since the block sizes are undocumentedly little-endian, while everything else is big-endian.
Yes! That stumped me for a long time. Along the way to solving it I found this great Stack Overflow answer where the creator of ADLER32 popped in to give some advice:
Author here. The post is a combination of two separate things: creating a PNG file via JavaScript typed arrays, then using that PNG in an (Android-specific) web notification.
I added a subtitle to the Medium post, but should have considered the fact that it won't show up anywhere else. Not sure it would fit if it was appended to the end of the title here.
A few years ago I started work on a kind of abstraction layer that would let you plug Rust code into multiple different engines. Got as far as a proof of concept for JavascriptCore and QuickJS (at the time I had iOS and Android in mind as targets). I still think there’s some value in the idea, to avoid making too heavy a bet on one single JS engine.
https://github.com/alastaircoote/esperanto