I am using this api for music player[0] in the browser. Biggest share of my users are using Chromebooks, where besides Android apps are not much alternatives. If this API was not available closest thing would be to make an Electron app, which has much more broad system access to users device than a website using showDirectoryPicker.
Regarding security I think Chrome got right balance on this: you always need to select folder, sensitive ones are excluded, on repeat visits if you try to access a file, it asks you permission again, you can't get full filename paths and so on.
I agree somewhat, but what about poorer regions of the world like parts of Africa or Asia, what is the solution for them? Most of the people there would not or could not pay for every website to use. It would be unfortunate if the web is inaccessible for most people.
Maximising profits and being sustainable are 2 different things. Museums do not need to make money because they are funded externally.
It is like saying artists do not need to make money. You seem to go to the very extremes.
Web needs to make money. Giving tools to advertisers while making sure user privacy is preserved is better than free reign of tracking we have before, no?
I myself do not like ads or tracking, but we need to be realistic and there needs a way to make web sustainable.
How to do that and making sure that monopolies like Google are in check is a valid concern though, but in these conversations is the only point I hear. Ironically Google does not even need these apis because it already has so much data on users, it is primarily for smaller companies.
Every one of my phones before was rooted with custom os flashed, but now I feel exactly the same a as you, it's just not worth it. Kinda sad how stuff is being more and mored locked down.
Just go to home page https://wpt.fyi/ see chart "Browser-specific failures are the number of WPT tests which fail in exactly one browser." Safari leads by a longshot with over 3800 tests failing only in Safari. Firefox has 1700 and Chrome less which kinda correlates to my own personal development experience.
> The "web standard" part is meaningless considering that most production websites will bundle the files together as part of their build/optimization process for size and loading speed, leaving only a giant chunk(s) that resembles nothing like the original ES modules.
I mean code itself will be non readable, but in modern build ouput chunks are using regular esm modules, at least for Vite, Rollup, Parcel and so on. Webpack might be different story, but still.
Semi related, I was suprised just how many bugs Safari has with animation timing while using Web Animation API. You can't possibly feature detect that, Motion one lib even disables GPU acceleration for them in Safari. In that case parsing user agent is the only option.
From my experience, if things work in Chrome, they will likely work with Firefox too, excluding very new apis, it isn't much of maitenance burden. With Safari every project I work o I discover new Safari quirk or bug. If you can make it work in Safari you can make it Firefox too.
WhatsApp always comes up in comparison to Twitter, but they are fundamentally different. WhatsApp is mostly one on one interaction, while Twitter potentially allows every user to interact with every other user, it's unbelievably more complex to do that at scale compared to WhatsApp, not even talking about all the extra features Twitter has. Search probably being best example of complexity differences.
Chat apps are mostly one on one interaction, it is much harder run an open platform where every user can potentially interact with every other user, not even talking about search and how complex it gets. If Twitter is bloated or not is a valid discussion, but comparison it to WhatsApp is not.
You clearly never looked into how much tracking mobile apps have. There are a lot of tracking SDKs which literally track every click. At least on the web you can block things where mobile is black box.
I like JSX too, it allows multiple composable components in the same file, but Sveltekit support for typescript has been amazing so far, the whole framework has been written with typescript in mind and it shows.
It was very slow before, but browsers improved performance a lot, multiple frameworks use proxies for their reactive primitives under the hood, Vue, Mobx and so on. SolidJS is one of the fastests frameworks out there and is built mainly on proxies, so proxies themselves can't be that slow.
Granted in very very tight loop regular object get/set will be faster, but performance is more than good enough today. If you have an use case for it, use it.
You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
I had exact same experience with it "it just worked", I started playing with few days ago and compared with other frameworks where I had to fight my to do what I wanted to do, from libraries to non oblivious behaviours. In SvelteKit it just works and it's refreshing. Especially love the builtin animation stuff.
It is a fork, but that was really long time ago, most parts of both engines were completely rewritten so for all intents and purposes these are completely different engines.
Writing new library and expecting people to actually use it without providing types is not realistic. You can write library in JS, but you will still need to provide types, since that's what ecosystem is right now.
Regarding security I think Chrome got right balance on this: you always need to select folder, sensitive ones are excluded, on repeat visits if you try to access a file, it asks you permission again, you can't get full filename paths and so on.
[0] https://github.com/minht11/local-music-pwa