_alastair

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.

https://github.com/alastaircoote/esperanto

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:

https://alastair.is/learning-about-what-happens-when-you-use...

"The Toupée Theory of In-App Webviews" is perfect. I might change it in the post.

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.

I was part of a team that used web notifications as an experiment in sending live election results to people's devices:

https://medium.com/the-guardian-mobile-innovation-lab/genera...

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.

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!

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.

I have a tiny insight into this, as I've been working on a Service Worker implementation for iOS webviews (i.e. in apps, not Safari):

https://github.com/gdnmobilelab/SWWebView

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.

Interesting, I'll have to take a look. Thanks!

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.

[1] https://www.chromestatus.com/feature/5424182347169792

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.

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:

https://stackoverflow.com/questions/32633486/why-are-png-def...

"Also just realized that you are that Mark Adler."

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.

I just checked my e-mail - it looks like we decided that we were definitely going to do it approximately two weeks before the first round went live. That's not typical but not necessarily unusual, if that's a sentence that even makes sense.

Glad you noticed that! It's proof of the difference a great designer (in this case, Rumsey Taylor of our News Design team) can make.

As a developer it can be quite humbling to realise how many seemingly tiny yet actually really important touches exist in a project you think you know inside out.

I hate to throw to Wikipedia but I won't be able to do a better description than they do: https://en.wikipedia.org/wiki/K-means_clustering

I think he enjoys a challenge. Case in point, the last photo in this set:

http://projects.nytimes.com/interactive/sports/worldcup/spot...

Thanks for the question, pervycreeper!

The concept is not new at all - Spot the Ball is a competition that ran in UK (and possible other) newspapers going back at least as far as the 70s. It was a cash prize competition and was pretty popular, though it's died out in recent years.

I wanted to bring it back to get people to interact a little more with a highlights photo gallery - it's a lot more fun that way. IMO, it's interesting because it's just the right level of infuriating.

I'm trying to come up with a good joke for this, Dan, and I'm failing. So I will tell you that last year Nicholas Kristof scored a respectable 54%:

https://www.facebook.com/nytimes/posts/10150426093994999

This isn't really my area of expertise - we have people at the company dedicated to studying this kind of thing in far more detail than I know how, who may end up reading this - hi! - so I don't want to speak out of turn.

But in my experience there's a lot of variation - things like this interactive aren't as tied to the news cycle as many articles are, so it won't peak as high but may make up for it in longer term traffic.

...sort of?

That's kind of the genius of puzzles like these (we can't take credit for inventing it - Spot the Ball has existed for a long time in the analog world) is that it's a mix of skill and luck, so you can fool yourself into thinking you're amazing at it, when in reality the next photo might trip you up completely.

The accuracy is calculated compared to other readers, so if you all clicked on the wrong corner you can still be better than 80% of them!

I mostly did it this way because there's no hard number that makes sense here - we don't know ft/metres, and pixels aren't a unit everyone is used to thinking about.

Oh, damn. I think you've found a bug, sorry about that. I think it's expecting a touch event when it shouldn't be. Let me take a look at that.

EDIT: should be fixed now. Apologies again, embarrassing bug caused by a last minute bug fix. The way these things always go...

Correct, it doesn't render all clicks (I dread to think how browsers would react if I tried) - all the results are put through a k-means cluster analysis at regular intervals to produce approximately 30 visible results. The percentages are calculated relative to all the clicks, though.

That's the work of Sam Manchester, deputy editor on the Sports desk and chief Photoshop wizard. I believe most of it is just cloning different parts of the photo to cover up the ball, though it can get more complex. For example, on the 4th photo of this previous round:

http://projects.nytimes.com/interactive/sports/worldcup/spot...

he actually cloned a players face from a different photo and pasted it in to cover up the ball. I have no idea how he does it so well.

I'm one of the people that made this interactive - funny to see it on Hacker News! If anyone has any questions about it, let me know.

With regard to languages, there's a real mix. PHP is still probably the most widely used language (including on the main desktop site, and our blogs are powered by Wordpress), but the mobile site runs on Node, and Go is definitely being used in the building.

mobile.nytimes.com is written in CoffeeScript (frontend and backend) and is maintained by a team of around 8 people. AFAIK all of the developers are fine with it.

At least it's given the world a new alternative to 'a to-do list' in demonstrating new technologies/languages/etc. There are ones for various different gaming frameworks:

https://github.com/uralozden/flappy-bird

https://github.com/ellisonleao/clumsy-bird

The ZX-81: http://bobs-stuff.co.uk/quack.html

and so on. To my shame, I made a version that you play by flapping your arms:

http://experimenting.alastair.is/flappyarms