I've been playing with Astro lately (hand coded) and it's pretty nice. Looks like the LLMs like it too

I agree with this article, indeed when one company has the full control over a piece of software, it's not good because either they abandon it or they use it to shape the market for their need.

Linux is one project but their is a lots of companies that work together, increasing the need of discussions and compromises.

If you were cloudflare how hard would it be to patch javascript libraries in transit across your network? Would the cryptographic hashes the end user does on the library before running catch any modifications?

Yeah, if no one continues development on it (or a fork)

But if something is open source, does that count as "abandoned"?

for a multiplayer browser game I ended up skipping websockets and using SSE for everything that goes server to client, and plain POST requests for the actions. it's just http so the reverse proxy, cookies and reconnects work without doing anything special, and EventSource reconnects by itself. one gotcha if you use express with compression middleware, exclude the SSE route or the events get buffered and arrive in chunks. websockets make more sense if the client sends a lot, mine mostly listens

Sad/funny they mention Deno, now that it's dead

So I wrote a client in C. Doing so by hand in 2023 was expensive, but in 2026, my AI friends can write anything in C.

bleh. nevermind. wont bother reading.

Wow, that's some wild tricks in there!

That's what Unix time is... kind of. It's what's usually referred to as an "instant", which is a moment in time that's independent of any timezone or calendar. It's just a plain number that increments by 1 every second.

A lot of systems already store dates and times as Unix timestamps, which means they're already timezone-independent and the timezone and formatting are only applied when rendering it.

In some cases, you do actually need to know the timezone. Calendar events are a good example - an event may end in a different timezone than it starts in (like if the event involves travelling), so both timestamps need their own timezone.

There's also cases where there's no 1:1 mapping between a date/time and a Unix time. Daylight saving is the best example. When the clock moves forward from 2am to 3am, the times between 2am and 3am don't have a Unix time, because they don't actually exist. Conversely, when the clock moves from 2am back to 1am, the times between 1am and 2am have two Unix times - one before the change and one after the change.

That's not to mention outliers like Antarctica where each research base chooses its own timezone.

Dates and times are very complicated :)

Not that it fixes everything but we'd have fewer ulcers in the world if we just stored every date in UTC and only converted when a human looks at it.

It's a pretty good API. I recently built an appointment booking form and used Temporal for it. Thankfully, all the date logic is server-side (in server-side actions on an Astro site) so I didn't have to worry about browser compatibility.

I just have a few small nitpicks, but they're pretty easily fixable by using my own classes that extend the standard Temporal ones, or just standalone functions. Some examples:

• I wish the classes like Date, DateTime, ZonedDateTime, etc had methods like isBefore and isAfter to compare to another instance. For some reason, I can never remember whether compare returning a negative number means the first argument is less than or greater than the second one. Maybe one day we'll get operator overloading.
• I wish there was a way to set the default calendar. I had to manually pass calendar: 'gregory' in a bunch of places because I ended up hitting issues without it (one example). My code isn't running outside of areas that use the Gregorian calendar, so setting it as a default in my code would be ideal.

Node support was a bit rough in June/July so I ended up using the polyfill, but I think they've fixed all the major issues now.

You can probably use getImageData, iterate over the data property, and check each pixel to see if it is close enough to white.

Pixel data is stored in groups of four: RGBA. So your loop will probably increment i += 4 to check each value of each pixel. You can adjust how much tolerance you want; 255 in RGB is white, so maybe you can check to see that data[i] >= 255 - tolerance where tolerance is some fairly small number, maybe 5. If data[i], data[i+1], and data[i+2] are all acceptably high, set the pixel in the new image to transparent. Otherwise, set it equal to the value of the original image.

This page has some examples of similar operations: https://pictureelement.github.io/html5tech/canvas-pixel-manipulation-and-animations.html

don't use JavaScript

That's not really avoidable if your use case is client side scripting in the browser lol.

I don't really understand how dumb it is to set a wide default type casting. Yet I understand the point of requesting declared casting for some language (when the language is designed to be used by a team of professional dev).

But for languages that aim to be accessible to simple users for personal home pages, with html and css, is it really dumb? May it let mistakes pass without crash the remaining of the script, but it seems acceptable to me in some amateur pages.

If the script is written by a single dev, or a small team, they may decide to only use explicit casting and strict rules for their code...

I think the main mistake is to take javascript for an "easy little language one may use without learn it" just because it is made to be usable by non-professionals. But I could be wrong, and I would gladly understand how wrong I am…

Then don't use JavaScript. This functionality is intentionally baked in to the design of the language. It was literally designed to do exactly this. I think it's dumb too, but my solution isn't to expect the language to act against its design, it's to use a strongly typed language.

I'm tired of seeing these kinds of titles and critiques about JS.

Stupid questions = stupid answers. That's all.

I expect a TypeError.

Return a value at any cost is a mistake

Because it makes more sense than NaN which would be the other possible solution.

Number + Text = Text, and the Number is interpreted as the character that compose it in a human reading rather than based on the char matching ASCI or some other table.

The attempt to convert text into numbers to make the operation would give NaN most of the time (Not a Number)... Or should we get the asci value of "1" and get 1+"1" = 50?

I think 1+"1"=11 is a good default, as you see clearly what happend and how to correct it if it is not the result expected…

Wat

The Ember project is excited to announce the release of Ember v7.1. […]

Would you improve the summary text, so that it says specifically what Ember is?

A good example is this post about FireDragon. The summary text says not only the news, but also what the heck FireDragon is, specifically.

I think my approach is yet different from others in the browser-based approach. In the open source version as described here, I don't add anything like a login. I'm able to avoid installation and registration entirely.

Simplex has nice ideas around routing messages. Im open to feedback about comparing the webrtc approach to simplex in the post here. it would be a stretch to call it onion-routing, but is 2 peers use different turn relay servers while on VPN, I think that's that most network hops you can do in my app. simplex has their own cool approach... but you'd be comparing apples and oranges.

as for contributing, I'm sure other projects have "got it" without my help. I'm just doing my own approach which I think is distinct from others.

It's cool, but couldn't private messaging devs work together on ONE app people could adopt, instead of making 100000 different secure messaging app nobody will use?

Exactly my reaction!

It wasn’t a conscious decision anymore, it was just what modern JavaScript looked like.

I almost stopped reading here. I don't agree that modern JavaScript looks like that. Why would it. Friends don't let friends lean too hard into a single code style pattern. These things are situational ffs.

Also,

Objects carry context

Yes but:

const { email: userEmail } = user;

Example seems contrived, sure, but the feature exists. Context added.

I don't know, to me this just reeks of someone who is still struggling with code style and more focused on the how instead of the why, even though they give the appearance of thinking about the why.

I always treat things like projectStatus and userEmail as a kind of code smell.
If a variable name carries too much context, then I figure out why and how to carry that context in a better way (project.status user.email)

Isn't always doable. But that's why it's a smell, not a rule