@tomayac Maybe this will finally get rid of all the annoying consent screens? One can hope...

@tojiro I have grown ever more reliant on Deno (and I absolutely love it!) but I do often worry it might end up with the same fate.

@trislman Ha thanks! In the first map of the series it was mostly done using mob spawners which would spawn a dropped item on a pressure plate when you were nearby. But eventually commands got very powerful and you could achieve the same thing with just a single command on a loop. Which is probably why I stopped developing in Minecraft. It felt like the challenge of finding hacky approaches is kinda gone now. Anyway, each map took about three months to create iirc. Glad to hear you enjoyed them!

@jaffathecake I like it!

@jensimmons I have used it a couple of times in the past but the biggest reason I'm not using it these days is because it requires you to install web pages to the home screen. And it's pretty difficult to get our users to do so.

Happy Halloween!

@agektmr I just gave this a go but I'm running into NotAllowedErrors. Seems like this is because we only have a passwordless flow. I reckon this was done for privacy reasons, but are there plans to change this?

@agektmr Are there plans to expand this to other platforms as well? Most of our userbase is on desktop.

@agektmr This sounds awesome! Can't wait to add this to our site 😌

@jensimmons It would be helpful if we could get a standards position on the Web Install API https://github.com/WebKit/standards-positions/issues/463
That way we can inform our users about the existence of this functionality. A lot of our users seem to not be aware that this possible in the first place.

@tojiro For a sec I was like holy shit that is one realistic looking render. Still looks good though!

@tomayac I got the opposite problem. It often inserts the same emoji twice 😅😅

So in conclusion. The actual functional piece of code seems to be running roughly x2.8 times as fast! But with all the extra overhead it's more like x1.25 as fast sadly.

The (unminified) js file is 4.7kB, whereas the wasm + gluecode takes up 31.5kB. So I think the trade-off is probably not worth it for our case.

I decided to put more time into this for some reason. I rewrote the hot path (again) in js but this time closely mimicking the way it was implemented in rust.
The js version takes significantly longer, but if you ignore serialization (which you typically only need with wasm), it's starting to get a lot closer to what rust can achieve.
Also note the big gap at the start of the wasm runs, god knows what the cpu is doing there.

Note though that this was not really rust's fault and neither was it wasm's. Basically my algorithm creates a whole bunch of `new BoxCollider()` instances as it is running, so the hot path turned out to be a lot less 'hot' than I thought.

I just spent two days (🥲) rewriting a hot path in rust to see how much better it would perform using wasm. The answer: Not at all!

I'm kind of sad I'm not getting my magical performance boost, but otoh I don't have to maintain an extra piece of tooling in my codebase now, so that's gotta be worth something.

@rgadellaa I was today years old when I found out the <dialog> element has existed since chrome 37. Only reason why it feels like such a recent addition to the web platform is because other browsers didn't support it until 2022. That and Safari being tied to OS updates means we could only really start using it this year.

There's nothing quite like searching for existing issues while submitting a bug report, only to find out you yourself submitted that very bug a few years ago.

@tvanderlippe I think the default has already been changed? GitHub's docs say 'Only repository collaborators can edit a public repository's wiki by default'. I think maybe Mockito's repo is old enough to still have the old default. One of my repos I just checked also has this setting enabled already.

@nolan Ha I recognise this! Didn't expect this to end up in my feed 😅