Of course, complete lack of non-local non-GMT time zones is a huge downside.
https://nodejs.org/en/blog/release/v26.2.0
What I would expect with the inclusion of temporal, is having a section on nodejs docs about Rust addons, alongside the C and C++ sections.
Absolutely great idea to expose such "features" to the web dev world!
All the JS devs that are already struggling with mildly complicated language features will love the giant new field of bugs they only dreamed of.
The arrival of the first very hyped tool that will make activating FFI support a requirement will be a great moment in JS history. Happily an army of mildly educated web devs will activate a feature which potential risks they do not even understand.
Luckily nowadays supply chain attacks are a thing of the past in the JS world, oh, wait...
I doubt we'll see this go into mainstream dependencies likely to be used by such developers – it hasn't in Ruby which has had easily accessible FFI mechanisms for years.
Though, there is already a fun experiment using it: https://blog.platformatic.dev/destino-doom-terminal-nodejs-f...
Even the complicated NextJS runs with Bun: https://nextjs.org/conf/session/nextjs-bun
Do you have a source for your claim?
https://blog.platformatic.dev/bun-is-fast-until-latency-matt...
Release notes: https://nodejs.org/en/blog/release/v25.7.0
(No affiliation, just a fan of VoidZero's consistently excellent tools.)
Evan You won't break the cycle, tale as old as time.
I moved some projects over to those from ESLint + Prettier and while the compatibility isn't 100% (I didn't need that), and the time to process a codebase went from like way over a minute with the old tools to a few seconds with theirs.
(I’m not disagreeing to remove it. It just took me a while to find out what happened to it)
There's the "types as comments" proposal[1] which could even land on browsers one day.
I started using the erasableSyntaxOnly setting in my tsconfig to get ready for this.
Adding websocket would simplify stuff tremendously, as well as make deployments much, much more secure.
I see that Deno has WebSockets, but I've never used them: https://docs.deno.com/api/web/~/WebSocket
I (also) basically use only one package: ws.
if (!globalThis.Temporal) {
// await import('temporal-polyfill/global');
await import('https://cdn.jsdelivr.net/npm/temporal-polyfill@0.3.0/global.min.js');
}Their usage of upsert appears different than I was used to:
Me: Upsert = Update or Insert
Them: Upsert = Get or Insert
If you use that operator and the value doesn't exist, it'll default create one and return a reference to that.
And as I'm writing this I realize why... references cannot be `null`.
`getOrInsert` here seems to be the Python "set_default" method on dicts, which is very useful at avoiding tedium in some basic data munging
It gives a caller the option of alternate logic based on the existence, or lack thereof, of a value.
> is that not just set?
No. The semantics of a "set" operation would overwrite an existing entry (if one exists).
Example:
update(store, (draft) => {
if (!draft.alertConfigurations.has(req.params.clusterId))
draft.alertConfigurations.set(req.params.clusterId, new Map());
const clusterAlerts = draft.alertConfigurations.get(req.params.clusterId);
req.body.forEach((alert) => clusterAlerts.set(alert.id, { ...alert, predefined: false }));
});I agree that their choice of labeling the proposal as "upsert" is less than ideal. However, this functionality is reminiscent of a very useful Perl capability known as autovivification[0] as described in the motivation section:
A common problem when using a Map or WeakMap is how to
handle doing an update when you're not sure if the key
already exists in the map.