I feel like as soon as a particular type of student learns that this is used, they'll have an excellent way to get that test that they didn't study for postponed, and even have plausible deniability that they didn't intend to lock the school down. At least for the first one or two times, after that it's back to triggering the fire alarm.

At my high school it was bomb threats. At least two or three a year

That happened at my mom's school (back in the 1960s) until the school put all the kids on a bus and brought them to the local armory gym and made all student sit quietly (no talking) on the floor until the end of the school day. Once the bomb threat wasn't a way to get out of school on a nice day there was never another one.

I'm not sure how to apply that to this situation, but it is one every school should think about when students try things.

That depends on who you think needs to learn a lesson about buying an AI from Temu.

> Once the bomb threat wasn't a way to get out of school on a nice day there was never another one.

If I think of my school time, I would believe even the fact that a bomb threat would be an annoyance to teachers would a be sufficient reason (of course, in the schools of the country where I live there were other methods than bomb threats to be an annoyance to teachers).

An annoyance you can’t brag about to anyone, however.

Tangential question: what's an "armory gym"? Google gives me a specific gym (in Australia) called "The Armoury".

As I understand it, it's a US thing. In areas with snow the local military branch had a drill hall as part of the armory, to carry out drills in winter. These were large open interior spaces.

The military moved away from using urban armories. These became repurposed as sports halls, places for events, and so on. For examples, https://fightingillini.com/facilities/ui-armory/5 and https://www.wakefieldma.gov/Facilities/Facility/Details/Dril...

Not making kids go to school is child abuse. Sure they won't like it - learning new things is hard. However society cannot function without well educated adults. (maybe in the future some post scarcity society will emerge, but we are not there and there is high risk it won't come before they become adults)

> Solution is to make school non mandatory!

The obvious unintended consequence of this is that then nobody learns how to read (because who wants to go to school?) and then our economy crumbles and everyone is stupid and then everyone dies.

Or maybe some kids do go to school, so they become the global elite while the other 98% are illiterate and they flee the country because obviously and so the economy still crumbles and everyone dies.

See, these are the things we need to be thinking about.

That's also why a number of cities here have started banning the use of newly-purchased non-electric commercial vehicles. The feasibility-impact ratio makes it an easy first step.

I guess that also means the first stable release of Cosmic - congrats to the team! Honestly I expected it to be delayed more, so good on them for pulling that off. Hopefully it's actually stable.

It's been pretty stable for me since the later alphas when I switched. The only real hiccups I've noticed have been with keyboard only navigation in a few areas, mouse has always worked well. I'd guess that A11y is also less than ideal as well, so if you're reliant on a screen reader or the like, best to wait quite a while longer until iced etc. catch up.

I kinda needed to see a video to get an idea of what this does. There's one linked at the bottom of the page: https://www.youtube.com/watch?v=WA5nHk-6UJc

Nice work!

> the ability to reliably center things. Assuming one agrees that we even did regain it.

Is there anyone who does not agree that we can reliably center things in CSS nowadays?

At least one person. https://tonsky.me/blog/centering/

Haha fair, we do still suck at properly centering text, I'll give you that.

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

source: i worked on an ambulance

Heh well, that's a good source. Any idea if all your colleagues thought the same?

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.

> And the only reason to make that step optional, is to not run it, which is a worse experience.

Yeah, but it's an optional "worse" experience.

IOW, for those people who think it's a better experience (because there is no build step), they can opt into it. For those who think it's a worse experience, they can continue using a build-step.

Nothing changes for those who want a build-step.

(I agree about the standards process thing)

> 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.

If TS is compiled in the browser, then it can be compiled to WASM, not to JS.

It's only when TS is compiled on the server that it has to be compiled to JS.

If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.

> a better experience (because there is no build step)

I feel like the way to make both of us happy is to just strip type annotations, rather than doing full type checking in the browser. Which, luckily, is already making its way through the standards track: https://tc39.es/proposal-type-annotations/

> If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.

I was not talking about compiling it to JS; I seem to recall that native support wouldn't necessarily result in big performance improvements. (Consider that JS is also not being compiled to JS.)