I wonder if the slowdown in non-ai features this release was influenced in some way by their migration away from AMD modules to ES modules.

Putting myself in their shoes and taking codemods into account, I wouldn’t want to make a big feature and have to worry about AMD/ES module concerns. Why do that when instead I could get a bunch of checking and smaller (but non headline) tasks out of the way and get back onto the larger features in 1-2 months after the ES modules are proven to work and I don’t have to worry about rolling back changes.

Either that, or sometimes by statistical eventuality we end up with changes (which all take a different time to be completed) just not being released within a small period of time.

See I think that’s not what the “anti-woke” people think it means.

That’s exactly what I pointed out. The people who provide them their information are actively trying to poison the word to the point that it means something else. But it doesn’t, because the poisoning only works in the echo chambers that spread that information.

Turning to urban dictionary, they’re using this definition: […]

That would be one of the attempts to poison the word. It’s worth pointing out that anyone can add a definition to urban dictionary and it’s quite often that trolls try to overwhelm existing definitions on there.

[…] (according to that definition).

That comes back to what I said before. People who self report as anti-woke are against anything that uses the label “woke”, until they look at what’s under the label and they realise they aren’t against any of the points the “woke” labelled thing is doing.

They’re not actually anti-woke, they’re anti-incorrect-label.

There’s no official announcement per se, but the windows version is built with .net which has been getting better linux support over the last two years.

There are unofficial instructions to run it through wine on their issue tracker.

It’s basically just a better sourcetree.

If you’re already used to sourcetree, it’s a really smooth transition.

The main reason to switch away from sourcetree is the bugs and papercuts.

• Bugs: Sure, bugs happen with everything but you’re stuck with them when they happen with sourcetree. There was an issue not too long ago where sourcetree couldn’t scroll. It was classed as a low priority bug and took about a year for it to be fixed. Imagine needing to use your keyboard to scroll up and down, but then git would refresh and take you back to the top where you’d need to start again. Now imagine trying to do that for a whole year. And that was just one bug.

• Papercuts: It’s so good at some things that you want to forgive the flaws in other things and find workarounds to bugs, but after a while they build up into poisoning you’re experience. For example: things going slow in larger repos, getting git errors when staging certain lines because a different line in the middle had to be staged/removed in a different order, the bi-yearly account issues, etc…

The thing is, you don’t need to put up with it since fork already does everything that sourcetree does (and a bit more), and they actually spend time sanding off the papercuts so you don’t need to worry about finding workarounds when something goes wrong.

Just losing the bugs without losing any features is already reason enough to switch.

But there’s also the improvements over sourcetree as well:

• Collapsible and sortable git graph (by date or topology)
• Better staging – Sourcetree supports staging changed content by file, hunk, and sometimes by line when it doesn’t bug out. – Fork supports staging changed content AND original content by file, hunk, and by line. That way if you changed a line, you can keep both the old version and new version in a commit. (e.g. You altered a comment in your code, but then upon self review when staging changes you realised you don’t want to change the comment, but instead you want the new comment to exist under the old comment. Instead of copying the change, undoing the change, then pasting the change into the code, you can simply stage the addition of the line, but discard the removal of the old line. Now both lines exist in your code)
• Better rebasing
• Supports new git features (e.g. worktrees, new diff algos, etc)
• Just how snappy the program is compared to sourcetree, it keeps you in that flow state

Because being woke is generally considered to be a bad thing?

No. Being woke is only considered bad in toxic echo chambers where they’ve tried to poison the word.

Most people who self report as “anti-woke” repeat infectious and carefully crafted but fallacious talking points whenever the term “woke” is said.

But if you bring up a situation where a minority is getting the bad end of the stick and they agree with you that it’s bad, they don’t realise that they themselves are being woke. They agree with being woke so long as the label “woke” isn’t used. It’s when you point that out that they start to realise that they’ve been poisoned against the term.

Being woke simply means that some people don’t often get the same affordances as others.

If you accept the general fact that women tend to get paid less for the same amount of work, then you’re woke.

If you accept the general fact that black people might not get hired if a person doing the hiring is racist, then you’re woke.

If you accept the general fact that some people have to hide the fact that they’re not heterosexual in some countries otherwise they’ll suffer the death penalty, then you’re woke.

English doesn’t really have a well defined way to write down the “zjush” from the “su” in pleasure.

The most accepted ways are “zh” or “x” in English, or ʒ in IPA.

Since most people call it twitter, and Elon want to call it x, so people push them together to make xitter, because it sounds like “shitter” (the crude term for toilet) and because the quality of twitter has declined dramatically to the point that it resembles an unclean toilet.

Looks quite good if you want to use git exclusively in vscode.

IMO, fork is the best git client for macOS/Windows but lacks native linux support (although they are experimenting with it).

Until fork gains linux support, this seems like a nice alternative if running on linux (and if it supports the remote development APIs: running on a linux docker image)

Watching web developers react to this change on mastodon has been… interesting to say the least

This doesn’t seem overly useful.

It’s a list taken out of a bunch of books with no regard for how something can be the best path in one language and a smell in another language.

Look at this page for example: https://luzkan.github.io/smells/imperative-loops

It suggests using functional loop methods (.map(), .reduce(), .filter()) instead of using imperative loops (for, for in, for each) but completely disregards the facts that imperative loops also have access to the break, continue, and return keywords to improve performance.

For example: If I have an unsorted list of 1000 cars which includes a whole bunch of information per car (e.g. color, year manufactured, etc…), and I want to know if there were any cars were manufactured before the year 1980, I can run an imperative loop through the list and early return true if I find one, and only returning false if I haven’t found one by the end of the list.

If the third car was made in 1977, then I have only iterated through 3 cars to find my answer.

But if I were to try this with only functional loops, I would have to iterate through all 1000 cars before I had my answer.

A website with blind rules like this is going to lead to worse code.

QOI is just a format that’s easy for a programmer to get their head around.

It’s not designed for everyday use and hardware optimization like jpeg-xl is.

You’re most likely to see QOI in homebrewed game engines.

Are you not made primarily of water?

The syntax is only difficult to read in their example.

I fixed their example here: https://programming.dev/comment/12087783

I fixed it for you (markdown tables support padding to make them easy to read):

|markdown|table|
|--------|-----|
|x       |y    |

Chromium had it behind a flag for a while, but if there were security or serious enough performance concerns then it would make sense to remove it and wait for the jpeg-xl encoder/decoder situation to change.

It baffles me that someone large enough hasn’t gone out of their way to make a decoder for chromium.

The video streaming services have done a lot of work to switch users to better formats to reduce their own costs.

If a CDN doesn’t add it to chromium within the next 3 years, I’ll be seriously questioning their judgement.

I’m under the impression that there’s two reasons we don’t have it in chromium yet:

1. Google initially ignored jpeg-xl but then everyone jumped on it and now they feel they have to create a post-hoc justification for not supporting it earlier which is tricky and now they have a sunk cost situation to keep ignoring it
2. Google today was burnt by the webp vulnerability which happened because there was only one decoder library and now they’re waiting for more jpeg-xl libraries which have optimizations (which rules out reference implementations), good support (which rules out libraries by single authors), have proven battle-hardening (which will only happen over time) and are written safely to avoid another webp style vulnerability.

Google already wrote the wuffs language which is specifically designed to handle formats in a fast and safe way but it looks like it only has one dedicated maintainer which means it’s still stuck on a bus factor of 1.

Honestly, Google or Microsoft should just make a team to work on a jpg-xl library in wuffs while adobe should make a team to work on a jpg-xl library in rust/zig.

That way everyone will be happy, we will have two solid implementations, and they’ll both be made focussing on their own features/extensions first so we’ll all have a choice among libraries for different needs (e.g. browser lib focusing on fast decode, creative suite lib for optimised encode).

That’s 41 degrees for everyone who doesn’t measure things in bird per gun.

You should put this in codepen so people don’t need to clone a repo to see it.

For example, here’s a 3d css-only thing I was fiddling with: https://codepen.io/spartanatreyu/pen/yPyNjw?editors=0100

You keep saying “relevance”, and now other things like “gimmick” and “marketing”.

Why are you so focused on “relevance”?

They’re completely unrelated to Deno.

Node had problems, ts-node had problems, Deno fixes those problems for developers.

Separately, Bun trades solving some problems for solving other problems.

Developers are free to choose between runtimes based on what problems they encounter.

Personally I use node for existing web projects and deno for data processing and to compile scripts into redistributable binaries.

No one’s asking nor wondering why you find looking at things in the sky beautiful.

They’re asking why you’re ascribing meaning to an arbitrary number of days. Months aren’t subjective, they’re arbitrary.

What to know about blue supermoons:

1. They literally mean nothing.
2. The change is imperceptible to everyone.
3. Expect useless clickbait slop about it until it passes.