sheept

It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.

Any page can silently trigger an additional multi-gigabyte download for Chrome users by just calling this API:

    await LanguageModel.create()

Since the model is installed once per browser, LanguageModel.availability() could probably also be used for fingerprinting.

It's relatively easy to write many words, but it takes more skill to express the same message with fewer words, like how video compression needs more time for fewer bytes and same quality. As Pascal once wrote, "If I had had more time, I would have written a shorter letter."

In Elm 0.19, they removed the ability for third party packages to provide native bindings for JavaScript APIs that the language or its official packages didn't yet support.[0] The only alternative proposed by Evan is to use ports, which are about as ergonomic as calling a function in a web worker.

[0]: https://discourse.elm-lang.org/t/native-code-in-0-19/826

When I worked on an Elm app in 2020, my users reported compatibility issues with various browser extensions (e.g. Grammarly, 1Password). I personally would prioritize making my apps usable for my users over making the DX usable for myself, so I stopped using Elm for future projects.

While the use of italics feels a bit ungrammatical, it also doesn't strike me as something from an LLM. An LLM would've tried bolding it if it could, and it wouldn't have written a comment this concise.

Another reason why this is problematic is that their proposed standards follow Google's priorities for its own products, particularly Google Meet.[0][1]

[0]: https://developer.chrome.com/docs/web-platform/element-captu...

[1]: https://developer.chrome.com/docs/web-platform/document-pict...

At the very least, Firefox's position on the similar <geolocation> element is positive.[0] I would assume their position for other permissions elements would be the same.

[0]: https://github.com/mozilla/standards-positions/issues/1288

The similar <geolocation> element has clickjacking prevention enforced by the browser[0], and even if the website finds a way around it, it still shows the normal permission prompt.[1]

[0]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLGeoloca...

[1]: https://mdn.github.io/dom-examples/geolocation-element/basic... (requires Chromium)

It replaces the YouTube embed, so they're just doing you a favor

Yes, and they can do that if they wanted to. The Supreme Court has the power to interpret the Constitution.

I believe OP is referring to how immigration is the only known working solution to a decreasing population.

The US fertility rate is already 1.6 births per woman[0], and the population is only not decreasing because it still receives far more immigration than, say, Japan or South Korea.

[0]: https://www.cdc.gov/nchs/data/vsrr/vsrr038.pdf

What you're doing is essentially what Zod is designed to avoid. If you tolerate needing a separate build step more than having to define types with Zod's syntax, then it makes sense not to use Zod since it's not made for you.

On Windows and Mac you can input an em dash anywhere with shift+windows+hyphen / shift+option+hyphen, respectively

It might be related to the liquid glass imitation in the color scheme picker

It highlights the Gemini models blue since that's what the article is about. The bar heights seem consistent with the values.

It would be nice if there was a swipe typing keyboard that was similar to Chinese/Japanese IMEs where you can swipe out a full phrase and the keyboard can use it to fix short/ambiguous words based on context. Today, when I'm swipe typing sloppily, it can be hard to distinguish between pairs like on/in, of/if/I'd, it's/its, etc

I can't speak for this keyboard, but at least on Gboard, if you type out a word a few times, it'll be stored in its suggestions dictionary and you'll be able to swipe type it.

That is true. I wonder if it could be possible to let the user supply and wrap the app around their own, trusted installation of Deno (rather than the one bundled in the app) to specify permissions.

I was wondering how this integrates with Deno's permission system, which is one of its biggest strengths especially for letting agents run amok on your device.

The CLI reference page[0] notes,

> The permissions you grant at compile time are baked into the compiled binary:

I think it would be nice if this could be surfaced to the user somehow, like letting the user know and decide which permissions they want to give access to.

[0]: https://docs.deno.com/runtime/reference/cli/desktop/#runtime...

You can use the favicon cache as storage too, by redirecting users across domains. It's been proposed as a potential fingerprinting risk[0], and if a browser naively reuses the cache for incognito mode, it could be used to track users across browser profiles.

[0]: https://www.schneier.com/blog/archives/2021/02/browser-track...

Plus, with forks anyone can publish a commit accessible from the main repo, so one could disguise a malicious version of stdx by forking the repo, pushing their charges, then setting the rev:

    base64 = { git = "https://github.com/rust-stdx/stdx", rev = "<sha1 of malicious commit in fork>" }

At least browsers wouldn't have to warn users that they'd be resubmitting data if they reload the page after submitting a query form, since query requests are intended to be idempotent

As you alluded to, many Chromium forks (notable exception is Ungoogled) are backed by tech companies. There's already plenty of intentional changes they maintain in their forks, like Privacy Sandbox,[0] so I don't think preserving support for v2 is a large hurdle for them.

[0]: https://support.brave.app/hc/en-us/articles/10742158329613-W...

Google Meet is definitely not going to perform better outside Chrome since based on recent web APIs proposed by Chrome (e.g. document PIP[0], element capture[1]), the Chrome team has shown they'll change the browser specifically to improve the UX of Google Meet.

[0]: https://developer.chrome.com/docs/web-platform/document-pict...

[1]: https://developer.chrome.com/docs/web-platform/element-captu...

People will not adopt a safer version if it broke their workflows. Adoption is part of preventing supply chain attacks.

Is it possible to fix it in a backwards compatible way? Removing lifecycle scripts is at least a semver major change, and would complicate existing projects relying on packages with lifecycle scripts from upgrading.

You probably meant [object Object] :) Since arrays have their own default toString implementation (its own can of worms that is the basis for JSFuck[0]), you'd have to go out of your way with Object.prototype.toString.call to get [object Array]

[0]: https://jsfuck.com/ relies on Array#toString for casting values to strings

In general the language uses `null` if it would otherwise return an object (similar to Java; this is also why null is an object but not really in both languages), while `undefined` is used if it could otherwise return any value.

Could the language have done without both null and undefined? Definitely. But it's here and here to stay.

Though, it's not the only language with two nulls. Julia has nothing and missing, though their semantics are more well defined and with different behaviors than in JavaScript.

You can just use --first-parent to skip past commits in merged branches. Squash merges complicate stacked PRs.

But I agree on not rebasing PRs. Another benefit to avoiding force merges is that it's easier for reviewers to compare changes since their last review.