• 0 Posts
  • 42 Comments
Joined 2 years ago
cake
Cake day: June 19th, 2023

help-circle
  • 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:


  • It’s worth it for the price.

    General:

    • Explosions / killing / respawning
    • Lots of Star Wars location and sound-design fan service

    Campaign;

    • Gameplay is fun, but simple. The most complicated part is just reading the controls in the settings menu since the game doesn’t tell you how to do one of the first things in the first mission (the button you need is 3)
    • Story is basic but it works well as a sequel to Episode 6 and a prequel to The Mandalorian.

    Multiplayer:

    • Take turns being on offence / defence
    • Keep playing the same class / hero character to unlock more abilities for that class / hero character
    • Servers are populated, even for niche locations

    Replayability:

    • Depends
    • If you like regular FPS games, you might get bored of it in 10-20 hours
    • If you like playing the same game over and over again to slowly grind up new things, you’ll probably play it for 100+ hours

    Other stuff:

    • Purchase through steam
    • Running the game downloads and installs the EA launcher (but you can log in using your steam account, no need to create new ones)
    • As far as launchers go, the EA launcher is tiny, surprisingly fast, isn’t annoying and doesn’t get in the way of anything (only setting you’ll change is turning off the autolaunch when you start your pc)
    • Achievements work through steam
    • Invite friends through in-game party system. This can only see your friends on the EA launcher, but you can import all your steam friends in the EA launcher in a second and you only have to do it once.







  • 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.




  • You can be right wing in FOSS networks.

    There’s two things you can’t do (at least if you want to keep a community healthy):

    1. Break the rules of the network (which are usually things like: don’t spam, don’t scam, “Wheaton’s Law”, etc…).
    2. Be so unpleasant to be around that others don’t want to be around you.

    There are cases of those who dehumanise others (e.g. racists, anti-trans, literal nazis, etc…) who get banned because they’re doing the two things you can’t do. But in those cases they’re not banned because they’re right wing, they’re banned because those actions break communities, so the community has to ban them to continue existing.