zebracanevra

One thing you do all the time on computers is moving your mouse. And 240hz doubles how smooth that is.

Sounds boring, I know, but honestly the thing I love most out of my 280 monitor is how nice and snappy the mouse moves around. It's neat.

After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah.

Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabbed size: 27.3MB. 2MB more of indentation saved! Not significant after compression, but parsing time over billions of starts? Definitely worth it.

[1] https://github.com/evanw/esbuild/issues/1126

May be worth reading this update from September, where more facial features/clothes were added to the sausages: https://sbox.facepunch.com/news/september2022#ClothingandHai... https://sbox.facepunch.com/news/september2022#CitizenSkin

Makes them have a little more character.

Here's some of the features I am looking forward to in JXL.

Better lossy compression than JPG, similar compression to AVIF. AVIF ekes out a little more quality at the very low end, and JXL excels at the very high end.

Better lossless compression than PNG.

Supports alpha channels.

Supports parallel decoding.

Significantly faster encoding than other formats like AVIF.

Supports multiple colour spaces and formats, allowing for HDR images.

The colour in JXL is stored in the XYB colour space. A dev states that this colour space gives more bits to darker colours, leading to better encoded dark skin at similar filesizes to other codecs [1].

Supports up to 4096 channels. A practical use of this is in 3D workflows with Physically Based Rendering textures, where a texture has channels for albedo, normal map, reflection, roughness, metalness, and others. They could be compressed into one JXL, much smaller than an EXR with the same channels.

Supports losslessly recompressing existing JPGs into JXL to save space. Those files can also be losslessly (ie byte exact) converted back to JPGs.

Supports progressive decoding. AVIF crucially does _not_ have this.

Progressive decoding also allows for Responsive Images. No longer would you have to encode two images, like 1x or 2x. Encode the 2x image once – you can serve the 1x image _from the 2x image_. Huge feature if browsers were on board.

Supports rudimentary animation (similar to MJPEG, ie only i-frames). Use AVIF for animations.

Has frames/layers. This is a pretty cool feature for an image format. I can see two main uses of this:

1. Non-destructive editing. If you want to add an overlay to a JPG, you have to re-encode the image. JXL allows you to add another frame on-top of the other image, without touching the original.

2. Hybrid lossless/lossy images. For example, a screenshot of a UI that contains a photograph. The UI could be losslessly compressed, and the photo could be lossy-ly compressed. There is already an experimental program within the JXL source that does this.

[1] https://mobile.twitter.com/jonsneyers/status/155021585930558...

Hmm, on Windows 10 Chrome/Firefox the demos with the movable ears don't work very well when the position changes. Both browsers output horrible audio in those sections.

edit: If I limit Firefox to 60fps (down from my display's 280hz) then it seems to work fine.

If you're at all interested in how for loops and scope work in Javascript, Jake Archibald and Surma have a great video on the topic: https://www.youtube.com/watch?v=Nzokr6Boeaw

Similar changes were made in newer versions of ES so that the for loop in this article works out of the box, like C#.

Slightly off-topic to this article: I wish "do while" loops had the "while" condition in the inner scope, not the outer scope. So many times I have wished that I could access the inner scope... I end up using a while(true) with an if { break; } at the end instead in 99% of cases where a do while could've been the perfect thing...

From a discord staff: "We currently don't intentionally block or disable third party clients or action the accounts of people who use them. We do monitor the traffic of spammers and we build heuristics around how to identify them -- and sometimes third party clients get caught up in that. [...] it's not us trying to block/come after well-behaved third party clients."

https://news.ycombinator.com/item?id=32475188

type module in the package.json, and import every and all .ts file with a .js extension. zero problems for a year or two.

Dayjs is 2kb. That library is 70kb+.

Dayjs has the familiar momentjs API.

Both libraries have the greatest differentiating feature from moment: immutable objects. Being able to compose dayjs objects together without fear of modifying them afterwards makes everything a breeze.

Even though there's no consensus, there are a bunch of great metrics that are in use such as Butteraugli. I believe JPEG-XL uses it.

In JXL the quality setting has been tuned especially well to give predictable speed/visual quality output. See Jon Sneyers's posts on twitter showing how quality variance is kept minimal: https://twitter.com/jonsneyers/status/1542560897306185729

That sounds like the entire internet is unlawful. How would a German access any content outside of Germany without going through the tens-hundreds of intermediate routers? There's nothing stopping those routers from logging IPs going through them.

mouse 4/5?

Perhaps a better URL is this blogpost: https://preactjs.com/blog/introducing-signals/

Amazon/Netflix/Disney all provide 30+ subtitle tracks for every show, by the way. I don't think you should make any conclusions from the amount of subtitles. And besides, for all we know, they could be very bad.

For me, the explore page ALWAYS says I'm interested in the topic "vorbis audio" because of the 'topics that i follow' (I follow no topics), so that's a nice bug. 75% of the repos there never change for me.

The trending page otoh is nice and fresh, though I wish they'd change it to prevent already popular repos like typescript from "trending" (why are people starring this? ridiculous.)

fwiw, I use github stars also as simple bookmark list, with about 100 stars.

When one of my (quite obscure) repos get stars, I feel joy. I like to think starring someone else's repo has that same reaction for them, too.

I think there are a bunch of decent uses for that, like rich text editors (eg select text, hit ctrl-b, and the text is bolded).

There are also some sites that popup a small box above your selection with a share box. Straight to hell with those. Compulsive selectors go mad on those sites. That's you, medium.com.

I feel like if you've selected some text, then pressing copy should always copy that text and nothing else.

But then: what's to stop websites from detecting you've selected text, unselecting it, and copying the bad text in, and then reselecting it...

There are so many loopholes I can imagine to get around these restrictions :(

From the chrome bug[0] it seems like this was changed to work without a gesture because the new tab page needs to copy text for a Google Doodle...

So instead of changing their new tab page to require a gesture like all other sites... they decided to allow any website to copy text into the clipboard. Nice.

I think copying into the clipboard needs an overhaul—even with a gesture. Don't you hate when news sites add a "- from XYZ" to your clipboard? That shouldn't be possible. I'm not sure how you'd fix this, but it should be fixed.

[0] crbug.com/1334203

Easy way around that is to use a CI service like GH Actions. Build it there, push it to dockerhub, and you're done.

Have it run on a schedule to keep it updated, if necessary. Alternatively, GH Actions allows you to set a manual trigger so you can rebuild whenever.

Oh yes, there are many of those. Here's another example: https://www.youtube.com/watch?v=219t6qwOWYk

Interesting to see the responses here are mainly negative.

I think email (and by extension, mail) is traditionally static because the medium never allowed for dynamic updates. I don't see the harm in trying to improve upon that. If a solution is found that allows for full transparency of those updates with sufficient privacy, why not?

Should email stay the same as it has been for another 50 years? I don't think it will.

You can use CF Pages with your own build infrastructure, it has "direct uploads" now. It's currently unlimited in the amount of deploys you can do a month. I don't think CF knows how to price it yet, so I wouldn't rely on this being free forever.

I made one for youtube that moves the seek bar below the video, instead of on top of the video. In addition it removes the gradient etc. I've always hated how it covered up the content. (pure css, but still)

Show HN guidelines[0] states that blog posts are off topic for Show HN.

[0] https://news.ycombinator.com/showhn.html

See also https://youtu.be/fu3ETgAvQrw which I believe is the official video to go with the song

Nice visualisation. The pedant in me hates that "zooming in" doesn't keep the point around your mouse stable, and there's no way to "drag" the background to move left and right.

> If you add this to your .gitattributes:

Not applicable to GitHub etc though.

I'm also not seeing any speed differences when using -y/yarn lockfile. Why not make it the default?

It seems like bun caches the manifest responses. PNPM, for example, resolves all package versions when installing (without a lockfile), which is slower. The registry does have a 300 second cache time, so not faulting you there, but it means your benchmark is on the fully cached path, which you'd only hit when installing something for the first time. Subsequent installs would use the lockfile and bun and PNPM seem fast* in that case.

If I install a simple nextjs app, then remove node_modules, the lockfile, and the ~/.bun/install/cache/*.npm files (i.e. keep the contents, remove the manifests) and then install, bun takes around ~3-4s. PNPM is consistently faster for me at around ~2-3s.

I'm not familiar with bun's internals so I may be doing something wrong.

One piece of feedback, having the lockfile be binary is a HUGE turn off for me. Impossible to diff. Is there another format?

* I will mention that even in the best case scenario with PNPM (i.e. lockfile and node_modules) it still takes 400ms to start up, which, yes, is quite slow. So every action APART from the initial install is much MUCH faster with bun. I still feel 400ms is good enough for a package manager which is invoked sporadically. Compare that to esbuild which is something you invoke constantly, and having that be fast is such a godsend.

You're doing something wrong. I just tested now. Preact 8.5.0 is 3.2kb minified+brotlied. Preact 10.8.2 (latest) is 3.7kb. That's a very small increase.