I’ll repost my comment yesterday about this very thing (link: https://news.ycombinator.com/item?id=45279384#45283636)

It’s also too early to worry about DOM apis over wasm instead of js.

The whole problem with the DOM is that it has too many methods which can’t be phased out without losing backwards compatibility.

A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.

The problem is that the DOM is still improving (even today), it’s not stabilized so we don’t have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.

New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:

• being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.

• the improved attr() api which can move a lot of an app’s complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.

And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.

Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn’t we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.

TL;DR: It’s still too early to work on a DOM api for wasm. It’s better to wait for the DOM to stabalize first.

I paid for it too!

It’s the first piece of shareware I actually went out of my way to pay for because it was so good that I’d be genuinely pissed off if it died. I’d probably end up switching to pijul or something else for my projects if it ever did.

I’ve seen a bunch of people messing the windows version running in linux in the fork forums, so it may be coming in an unsupported capacity.

Yeah, I use it when ssh’d into a server, but it’s just so awkward to use.

Sometimes it just really doesn’t want to separate a hunk. Other times you want to stage all lines except one, and you have to do a million splits just to target the lines you want to keep.

It’d be far easier if you could just select the lines you want to affect. It’s literally the first feature shown in lazygit’s readme. I think half the reason that people use lazygit is that partial commits are so awkward to perform in most other clients.

Luckily Fork does it as well as lazygit

Fork !!!

It’s hands down the best git client.

It’s free as in: sublime text or winzip where they ask you once a month if you want to pay for it but you can just select: I’m still trying it out, and it gets out of your way.

• It’s got a well designed tree graph like in GitKraken except it doesn’t lag
• It’s interactive rebasing is as smooth as JJ / LazyGit, so you can edit/rename/reorder your commits except you don’t have to have to remember CLI flags since it has its own UI
• It’s lets you commit individual lines by selecting them instead of adding/removing whole hunks like Sourcetree except it isn’t filled with paper cuts where a feature breaks in an annoying way for 2 years and you have to do extra steps to keep using it how you want.

And one killer feature that I haven’t seen any other git clients handle: allowing me to stage only one side of the diff. As in: if I change a line (so it shows up as one removed line and one new line in git), I can decide to add the new line change while still keeping the old line.

So changing this:

doThing(1);

into this:

doThing(2);

Shows up in git as:

- doThing(1);
+ doThing(2);

But if I still want to keep doThing(1);, I don’t have to go back into my code to retype doThing(1);, or do any manual copy-pasting. I can just highlight and add only doThing(2); to the staging area and discard the change to doThing(1);.

So now the code exists as:

doThing(1);
doThing(2);

Now with a one-liner example like this, we could always re-enter the code again. But for larger code changes? It’s far easier to just highlight the code in the diff and say: yes to this and no to the other stuff.

And when you get used to it, it makes it really easy to split what would be large git commits into smaller related changes keeping your git history clean and easy to understand.

The first problem is they’re letting AI touch their code.

The second problem is they’re relying on a human to pick up changes in moved code while using git’s built-in diff tools. There’s a whole bunch of studies that show how git’s diff algorithms are terrible, and how swapping to newer diff algos improves things considerably.

TL;DR on the studies:

• Only supporting add/remove/move operations is really bad.
• Adding syntax awareness to understand if differences in indentation should be brought to a reviewer’s attention, improves code and makes code reviews more accurate. (But this is hard because it’s language dependent)
• Adding extra operations (indent/deindent/move/rename-symbol/comment/un-comment/etc…) makes code review easier, faster and more accurate. (But again, most of this requires syntax awareness.

There’s also a bunch of alternative diff algos you can use, but the best ones are paid, and the free ones have fewer features. See:

• https://www.gitclear.com/rich_diff_checker
• https://semanticdiff.com/
• https://difftastic.wilfred.me.uk/

I was worried at first when I read they were “reducing” all the documentation comments from new tsconfig files and making users rely on editor autocomplete to somehow find and get the right settings.

But after looking at their new tsconfig example, it still has all the settings that users care about and looks like what everyone eventually turns their tsconfigs into anyway

It’s not about caring, it’s about the lawyers making the argument javascript’s genericness easier

Imagine if god showed up one day and said: “It’s actually Jod” then left

Try this link on an iPhone: https://jpegxl.info/resources/jpeg-xl-test-page.html

The future is webp JPEG XL…

And telling software patents to burn in hell.

They told you to use “ed”

You missed the joke

I really want to switch from VSCode to Helix but not having a file tree is a deal breaker.

Luckily there’s been a lot of work on adding a plugin runtime with one of the proof-of-concept plugins being a file tree. Assuming the plugin runtime comes out this year in a helix release, and adding on a year for the community to settle on the first wave of plugins while giving them time to mature, I can see myself using helix fulltime in 2027 (before Microsoft has enshitified vscode enough to be unpleasant to use).

For a complicated project I get it, github’s PR system is kind of bad (horrible branch based workflow and no stacked diff support resulting in increased churn) compared to the alternatives.

That’s why we have tools like Graphite to add stacked diff support on top of github, and other devs creating new VCSs because git still hasn’t made it’s interactive rebase and merge conflicts easy enough to handle for juniors and it should be simpler.

I’m conflicted by this release.

On one hand it has a common sense feature where the editor shows what changes in a file are already staged which will be good because it’ll help people separate their code changes into different commits for unrelated changes (as opposed to just shoving everything into a single unmanageable tangled commit), but then it’s adding all this ai slop which pushes users to just put all the slop into a single commit anyway.

I really want to switch to helix, but its plugin system is still being developed.

Plugins mean we get a file system tree, LSPs, and integrated version control, the three things that turn an editor into an IDE.

Polonius

“Well it’s about damn time” smokes cigar

Yes, I know it’s not out out yet, but we’re nearly there

^ this

Using AI leads to code churn and code churn is bad for the health of the project.

If you can’t keep the code comprehensible and maintainable then you end up with a worse off product where either everything breaks all the time, or the time it takes to release each new feature becomes exponentially longer, or all of your programmers become burnt out and no one wants to touch the thing.

You just get to the point where you have to stop and start the project all over again, while the whole time people are screaming for the thing that was promised to them back at the start.

It’s exactly the same thing that happens when western managers try to outsource to “cheap” programming labor overseas, it always ends up costing more, taking longer, and ending in disaster

Well… Assuming that it’s not using bits of typescript that will be deprecated in TS 6 and removed in TS 7 (the native go implementation)

This is why you’re meant to comment your code.

Your code tells you “what”, your comments tell you “why”.

Here’s a good review of comments in the redis codebase: https://antirez.com/news/124

I would advise against using pixels for margin/padding since it’ll have issues for users who have different zoom/text sizes than you do.

Stick to rem for margin and padding.

If you’re still early days with css, it’s worth pointing out that you should use a “css reset” file. It will solve problems for you that you don’t even know exist yet.