

The sound is so long and drawn out, it’s more of a whoopie cushion sound


The sound is so long and drawn out, it’s more of a whoopie cushion sound


I’m usually programming, but I’ve got a few bits and pieces that can be shared:
The rest are too experimental, or are released commercial projects.




Or if you need something smaller, simpler and more modular: purecss.io
(Yes it’s weird that they called a framework “pure” css, but it’s been a solid go to for a long time)


Yeah, I’m the lead on a bunch of websites that all have to be localised.
There’s a lot of weird footguns to watch out for, and a lot of retraining devs when they’re used to only working on a single language/locale.
Two biggest head scratchers I’ve had to deal with are computers treating “fr-FR” different from “fr-fr” (due to file system case-sensitivity differences between developers), and having to undo the coded assumption that languages and locales follow an [a-z]{2}-[a-z]{2} pattern (e.g. “en-gb”) once we stumbled upon Latino Americano: “es-419”.
EDIT: My left ear really loves the Erlang talk.
This fixes it:
const audioContext = new AudioContext();
const audioElement = audioContext.createMediaElementSource(document.querySelector("video"));
audioContext.destination.channelCount = 1;
audioElement.connect(audioContext.destination);


Ooh, I didn’t know about that site.


-4 votes?
Is someone sockpuppetting?
This was and still is a classic talk, right up there with wat, juice it or lose it, fuck you pay me, the art of code, and pwned by the owner: what happens when you steal a hackers computer


I’m a:
So I have a lot of machines
Machine 1
Machine 2
Machine 3:
Machine 4:
Also:
Future:


I’m literally slower with AI, because I have to waste my time review slop generated code that looks convincing rather than actually works.
If they tried at least to write the code themselves they would get better over time


Pretty sure Deno had that first though.
Deno launched with an all-tools-in-one approach and then you could use deno bundle to compile everything into a single binary that you could run on another machine.
Then they briefly broke deno bundle in their 2.0 release when they added node/npm compatibility then brought it back in 2.4.


Serious question for anyone who actually uses Bun:
Why are you using Bun instead of Deno or Node?
If you would have asked me 10 years ago, what were the biggest problems with JS as a whole, I would have stated:
Poor type safety
No standard library which leads people into dependency hell
Poor security (installing a project should not even allow the possibility of key stealing or ransomware)
No runtime ergonomic immutable data structures with fast equality checks (looked like it was going to be resolved with the Records and Tuples proposal, but it was withdrawn and discussions are continuing in the composites proposal)
Today I consider point 1 mostly resolved and point 4 a problem for TC39 and engine implementers, and not resolvable by runtimes themselves.
That leaves us with problems 2 and 3.
I see Node having poor solutions for 2 and 3.
I see Bun having poor solutions for 2 and 3.
I see Deno having great solutions for 2 and 3.
As far as I can tell, people have chosen Bun for either hype or speed reasons.
Hype doesn’t seem like an important reason to choose Bun since it’s always fleeting and there’s enough investment in the industry to keep each runtime going for a long time.
I do see speed being a moderate issue with JS, but that’s mainly due to:
dependency install times which should be a one time cost, and which can be reduced anyway by using a standard library
slow framework slop, which isn’t really a runtime issue.
So I’m not sure speed fits as a reason for choosing Bun.
I’m not sure what the other reasons are, but I’m genuinely curious.
If you’re using Bun in projects today, why have you chosen bun?


Bruh, deno’s great!


It’s mainly an issue with old drivers and not the latest software.
You can try turn it on in each browser’s settings to see if it works. But it’s not a major issue if it doesn’t.
I’m glad this is picking up more steam.
Next up the triptych proposals: https://alexanderpetros.com/triptych/


Why would you need to go to a store to download apps?


You can now jump to a CSS custom property’s definition from within the var() function in style rules.
Thank You!


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
CSS has been considered turing complete for a long time.
So this isn’t a shocking revelation, but it is cool.