no_way

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.

[0] https://github.com/minht11/local-music-pwa

In our projects we use Moon https://moonrepo.dev/moon extensively, it supports multiple languages and quite a few features.

For me personally I like that it updates Typescript references automatically and makes docker image setup far easier.

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.

There quite a few in javascript/browser world: - Browser Houdini effort https://ishoudinireadyyet.com/ - Service workers https://jakearchibald.github.io/isserviceworkerready/ - Svelte 5 new version https://svelte-5-preview.vercel.app/status - Turbo bundler rust rewrite https://areweturboyet.com/

And prob much more

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.

https://motion.dev/guides/waapi-improvements#webkit-bugfixes

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.

They are first but it's not like other browsers are far behind, Chrome is already shipping :has, being first for one feature doesn't mean much while you are years behind implementing non controversial features already in other browsers, not even talking about Safari bugs..

Ironically that's kinda similar what Google FLoC was supposed to be.

I am still insanely upset that there are a lot of years spanning bugs which aren't fixed in Safari or even acknowledged in their bug tracker, but the situation is getting a lot better with the release frequency and new features so at least there is hope for things to get better from here.

Yeah, zoom changes page scale factor you can see it's computed value window.devicePixelRatio and that in return changes everything. Font-size can be also be changed independently of zoom inside browser settings.

https://developer.mozilla.org/en-US/docs/Web/API/Window/devi...

The text drawing code isn't using WinUI tho, they embed terminal canvas into something called "islands", so in this case it's not an UI frameworks fault. Besides I have used it on relatively old laptop and it was fine for me, but others experiences might differ.

If you are building cross platform app, there isn't much reasons to lock yourself in into platform specific framework, but just look at new Windows Terminal, it's great and it is using WinUI 3.

I would pick Vue 3 over React just for performance alone. With React you do not have much breathing room and without specific optimizations like memo specific components, being aware what rerenders what: don't even try to use context api in large app for often changing data. Vue is much more forgiving and new composition api is nice. Both frameworks ecosystem and developer experience are pretty similar at this point.

People are working on customizable select 1 https://open-ui.org/components/select.research 2 https://bugs.chromium.org/p/chromium/issues/detail?id=112184...

To render content based on device screen scaling. window.devicePixelRatio provides page zoom level combined with OS DPI setting. Things like canvas do not use scaling by default, so to render content appropriately you need to know by how much you have to scale it. Other use cases exit too.

I have done manual configs from scratch in Rollup, even wrote bunch of plugins for stuff like custom css class minifying and web worker support, so no I don't need handholding :) Setting it all up was even fun, everything was well documented and clear, with Webpack on the other hand, you only have fun if you like pain.