tim1994

With signals you can avoid the prop drilling. I think signals can help a lot with this approach

Well, someone has to start. It's ok if you use the alternative with a subset of your contacts.

True, but considering that the extension was bought in 2022 by Avast, maybe it has its own tracking built in by now or will have something concerning done to it in the future. So even if the user does not care about cookies that much I would still recommend this new extension over "I don't care about cookies"

For panning you don't need a 3D view/reconstruction. This also allows translational camera movements, but only for nearby views. Maybe I am overly pedantic here, but for HN I guess thats appropriate :D

Should you optimize for resize performance? I guess that depends on the app. Use the tool that fits the requirements.

The problem is content exclusivity. It would be great if all the content or at least most would be available on all platforms. At least eventually. That would be great for consumers. Mergers like this typically not.

Another reason I can think of is the requirement not to introduce a breaking change. It is very frustrating if the codebase has a lot of hacky/bad code in it but a lot of it can't be changed...

Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.

The government is.

Companies too.

I think the problem is that they cannot communicate that they don't know something and instead make up some BS that sounds somewhat reasonable. Probably due to how they are built. I notice this regularly when asking questions about new web platform features and there is not enough information in the training data.

Ain't gonna happen (unfortunately). Somehow people (outside of HN) seem to like to use apps for everything. EVERYTHING.

I also get this. Firefox on Android in Germany.

A couple of years ago I played PUBG which crashed occasionally. I rarely submitted bugs, even if it was as simple as pressing a button in the crash reporter. This is because sending the bug report took a while and blocked you from restarting and rejoining the ongoing game. This applies mostly to multiplayer games but if your app has a crash reporter, give the user a chance to restart the app and report the bug later.

Interesting read for sure! This is about ChromeOS though, Chrome on other platforms was not affected.

It's always impressive how far people can take TypeScript and even build parsers with it. But this is limited to inlined string literals and cannot read files (a TS limitation).

I wonder if the author has a use case in mind for this that I don't see. Like if you are only using TS, what's the point of protobuf? If you are exchanging data with programs written in other languages why avoid the protobuf tooling that you need anyway?

Maybe this is just a fun toy project to write a parser in TS?

In Germany LRAD systems have been used to deliver Covid 19 information, not against protesters. Used by the fire brigade. I haven't checked uses in other countries.

https://en.m.wikipedia.org/wiki/Long-range_acoustic_device#G...

Why do we need tracking for advertising though? I wouldn't mind ads based on the page content (as much). Social media websites know their users anyways, no need IMO to track users across other websites.

I don't think this is sufficient. Scripts could still do bad things, for example mining crypto.

You can use Google Play services on Lineage os. IIRC they are installed by default though there are ways to use it without them (doing that right now). About banking apps idk.

The Android App as well. I have a slightly older phone (Fairphone 3+) and it takes 10-15s for a song to start playing after tapping on it. Even if it's offline available. Didn't use to be that way. Also the app is basically the opposite of offline-first. Terrible UX.

Sounds like an interesting project, but I think it's important to find a good way to interact with browser APIs. They all work differently, like rAF, geolocation, pointer lock, camera access and so on. I think relying on the unsafe mode for all that could lead to a frustrating experience but also implementing those APIs in a different way would be weird and you have to keep up with new APIs and changes browsers introduce. I suggest having an idea on how to solve this before spending a lot of time developing the actual language. If it limits what I can do with JS I would not use this and just stick with Typescript.

IIRC extensions cannot access any URL that hasn't been specified in the manifests permission section. I think Firefox shows those URLs in the permission prompt. Those URLs can contain wildcards though and I even think there is a special value for all URLs but only few extensions should require that permission.

I don't know how Chrome handles this but Firefox won't install the update without the user confirming it.

It's not quite that simple. For example the button doesn't necessarily have to have an aria label. Could be the (nested!) content. There could be multiple candidates (buttons). The speech recognition thing is also not trivial. Yes there are WebAssembly based solutions but those have to be properly integrated and tested (not sure how good they actually are)

Perhaps a caching or timing issue? I updated my profile shortly after posting this (and noticing it myself).

Assuming this does not yet exist: If anyone is interested in building something like this (that works offline) please let me know, I'd like to join. I have some experience building web extensions but unfortunately not the time to develop & maintain this on my own right now.

I assume you are referring to the SpeechRecognition interface of the Web Speech API. Unfortunately this is not supported by Firefox and even for Chrome it doesn't work offline.

Source: https://developer.mozilla.org/en-US/docs/Web/API/SpeechRecog...

I'd also be interested in details on this but I assume the gl.enable() API changes fundamental things about the rendering pipeline. It allows enabling things like depth testing and stencil (both involve an extra buffer) and face culling (additional tests after vertex shader). For blending in particular I think it requires the fragment shader to first read the previous value from the frame buffer. Changes this stuff is probably not a trivial operation and requires a lot of communication with the GPU which is slow (just a guess).

If you want to change blending for each draw call you can change the blending function or just return suitable alpha values from the fragment shader.

I am a bit surprised that no one has mentioned https://squoosh.app/ yet

Have you considered running "untrusted" code in a worker? That way the code can not interfere with the global scope.