I wonder if, if you'd talk to a rescuer, they'd agree...

I'm waiting for that first point to. The good news is that they just started work on workflows, which should allow for that.

Immich was my gateway into NixOS. It did a really good job of showing how well it can work. I'm only a couple of months in, so we'll see if it sticks, but I'm also running it on my laptop now.

I think it's mostly a marketing play by Deno.

Yea, Thats what I have also accepted the reason to be.

An important feature of TypeScript is identifying problems in your code before the user runs it, i.e. before a browser even comes into play.

No runtime type safety bites people often and in unexpected ways. It should just be standardized.

Sure, but that's an orthogonal concern. That sounds more like a call to standardise Zod.

So? If supported natively by the browser the browser could compile it on download.

You'll still get all the strong typing without have to wait for it to run.

For example an error in a little used branch would cause an error before the branch even runs.

So then the user gets a type error in their face instead of the page loading? That doesn't really sound better than the developer getting that error while writing the code, which is what TypeScript currently does.

Not to mention the penalty of the browser having to re-execute the type checking every time the files aren't loaded from cache.

> So then the user gets a type error in their face instead of the page loading?

The alternative is not "User sees no error", it's "user sees the error at runtime".

In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.

In my mind, the alternative is running TypeScript while writing and at build time. Type checking at runtime is at best redundant, and at worst an excuse to skip type checking and have it blow up in the users' face.

> In my mind, the alternative is running TypeScript while writing and at build time.

Right now, sure.

But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.

To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:

1. Does the full compilation to JS, and that's what gets deployed.

or

2. Just lints the file, and has the original TS file deployed.

Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.

There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.

Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.

I'm not seeing any downside here.

Yeah that's kinda the point; you get all that, unless you don't run the build-step/in-editor dev process. And the only reason to make that step optional, is to not run it, which is a worse experience.

So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likely involve breaking changes and making it harder to update, I don't see it happening. (Edit: I should add that I do think the "types as comments" proposal makes sense. I do see the advantage of being able to run TS code without a build step. It's just the part where we'd throw an error in the user's face that I don't see providing value to anyone.)

I do think TC39 is progressive enough to be OK with changes to JS if those would allow TS to have more effective type checking (as long as they're backwards compatible, of course, which would also be the case if TS got incorporated into JS), so I don't think it's necessary for that.

Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.

What's an example of a thing you usually need to fiddle with? I feel like 1 and 3 are already true for my existing native terminal emulators, which I also never configure. So presumably there are things Ghostty does that aren't enabled by default on my other ones that I could take advantage of?

And Git :)

And with that, kudos to Mozilla, EFF and the University of Michigan for founding Let's Encrypt for just that purpose.

(I do work at Mozilla now, but this predates me. Still think it's one of its most significant (and sadly often overlooked) contributions though.)

Yeah, massive massive contribution to the world. I can't think of many other nonprofits that had such an impact for the betterment if humanity.

I have seen a number of attempts at exploiting this on our deployment already. Luckily I saw and was able to apply the patch last night, but as a European, it wasn't great to only get the announcement after dinner time.

Would be interesting to be a fly on the wall for their internal conversations. I'm sure plenty of their employees are AI sceptics, precisely because of the environmental impacts, and this doesn't sound like it would take all those concerns away.