Echo JS 0.11.0

That's understandable... I actually kind of appreciated the use of HTTP(S) references for code with Deno.. though a repository is nice enough.  The x.deno.land worked, but JSR is definitely a better longer term solution, and really happy to see decent npm support.

Thinking about a minor rewrite of a couple modules this weekend to be JSR first, adding enough for an npm publish to remain working.

I like a lot of what JSR offers, I do hope that it sees a fair amount of uptick.  I've been using Deno a lot more than Node lately, mostly in that it's better for shell scripting with a shebang and direct imports compared to package.json and node_modules etc.

I'd like to see a few things get refactored to work better over time, but who knows.

As much as I dislike Windows, and even in Windows will prefer WSL... Windows development is still a thing and I try to be friendly to Windows developers as much as reasonable.

That's why Concurrently exists even if there's Bash on Mac, Linux, BSD, etc.

Feels a bit hyperbolic and don't strictly agree with the sentiment.

One could simply share the same userId for expanded 1:1 fields, the schema itself is 1 to many, even if usage is 1:1 lookup.

I stopped at the second question, which is just weird, and beyond that, the second question will never end the loop.

I'm not sure if this was AI generated, or what, but it's just incomplete or weird to say the least.

Updated the link to the english version.

Looks interested to say the least... Would be cool to get a similar interface for clients in ASP.Net (C#), Go, Python and Rust at the very least.

Definitely not a great article... as it is, the Unicode character and surrogate detection isn't great, and even then doesn't really work right with the regexp for non-unicode surrogates.  The notation of byte length should probably be a blurb and jump right into the Unicode detection, surrogates being another, related issue, and even then, it's problematic at best.

Not to mention the benchmark at the end is kind of useless and doesn't include the Unicode aware methods.  Also, no mention of UCS-16 vs UTF-8 or other Unicode demarkation with strings in JS.

Definitely click-bait.

No benchmarks for the Unicode methods, which I suspect would be the desired results...  The format of the article seems to spend too much effort on getting the byte length of a string, which is not the characters in a string.