phil294

Tangentially, I built something similar a few years back, at link-archive.org: https://web.archive.org/web/20220127233707/https://link-arch...

3B existing URLs extracted from CommonCrawl, with instant search results. It was a fun project but didn't serve much real-world purpose besides curiosity and discovery. So I eventually ditched it, primarily because the link DB was a whopping 500 GiB in size, too much to just keep hosting.

I just used SQLite FTS5 as the backend search engine. Just a few lines of code, but immediate response from a 0.5 TiB DB. SQLite is amazing.

...performance-wise. Not in general. It obviously does more than just opening a file.

Also, you don't get to choose your competitors. SQLite is single-writer focused and an embedded library, but it's a sophisticated database engine after all, so comparisons with other "real databases" are more than appropriate. This meme really needs to die. Even more so when all you're comparing is query plan debugging output where there is no justification for unreadable output.

I would say it mirrors common behavior in the Web, which in turn was largely influenced by old desktop software: Enter in a `<textarea>` inserts a line break, while enter in an `<input>` submits the surrounding form (or does nothing). It is an established idiom after all, many apps just get it wrong.

Things that definitely need interactive prompts before running or fail out of ambiguity otherwise. Let's not pretend these are impossible problems to overcome design-wise.

I like it and would like to see an entire Linux OS being done in a similar manner. Or shell / wrapper / whatever.

A sane homogeneous cli for once, that treats its user as a human instead of forcing them to remember the incompatible invocation options of `tar` and `dd` for absolutely no reason.

    zip my-folder into my-zip.tar with compression level 9
    write my-iso ./zip.zip onto external hard drive
    git delete commit 1a4db4c
    convert ./video.mp4 and ./audio.mp3 into ./out.mp4
    merge ./video.mp4 and ./audio.mp3 to ./out.mp4 without re-encoding

And add amazing autocomplete, while allowing as many wordings as possible. No need for LLMs.

One can dream.

Depends on your definition of "using" JavaScript. The main difference between common TypeScript and TS-based JSDoc is the need for an additional build step. Being able to ftp-upload your `.js` files and then be done with it is a remarkable advantage over Vite/Webpack/whatever in small to medium-sized projects. If editor based type support is sufficient to you (i.e. no headless checks), you won't need to install any TS packages at all, either. tsserver is still used in the background, but so are thousands of other binaries that keep your editor, OS and computer running, so I don't see that as an argument.

> So (TS)JSDoc support is a relic from when Microsoft was trying to get market share from Google.

> Today in 2025, TS offers so much more than the (TS)JSDoc implementation. Generics, Enums, Utility types, Type Testing in Vitest, typeguards, plus other stuff.

None of that is true! Please don't share misinformation without looking it up first.

I see where you're coming from, but "on a phone" hasn't been a valid qualifier for performance benchmarks for a long time. Phones and their GPUs are ridiculously powerful nowadays. We've been smoothly running 3D apps on GPUs with orders of magnitude less MFLOPS 20 years ago already. Apps and games with far more going on than blurry glassy alarm clock, albeit somewhat less beautiful. When I run Fluid Glass on a 10 year old laptop with an integrated GPU and move my cursor, I'm seeing less than 10 FPS. When will we finally start readjusting our expectations for "fast" software and stop blindly following Wirths law?

Neither are humans, so this argument doesn't really stand.

This is a nice idea, but looking back at how not only documentation, but also UX in general has not improved the slightest over the last decades, it's fair to say the only way we'll ever get close to anything like this is by leveraging personal LLM assistants, unfortunately.

What about complex SPAs? Database drivers? Polyfills? TypeScript?

I ran some of these in comparison with Chrome, and Chrome was consistently faster, but only marginally (1-20%). I'm actually quite impressed, an integrated Intel HD 620 / 4x2.4 GHz (!) rendering 10,000 fishes at 30 FPS in a webbrowser.

Great game idea. I'd suggest you limit the questions top international topics though. I got a suggestion for "name a hurricane" - this probably wouldn't generate very interesting responses outside of America.

Pinta *IS* Paint.net, just forked at an earlier stage before the latter became closed source software.

Also, is "washed and bleak" really that big of a problem for an image editor? It just doesn't matter what it looks like as long as the UI is intuitive and has the features that you need. It should also be noted that Pinta very much looks just like your overall Desktop appearance on Unix. I'm on XFCE and it's so incredibly theme integrated it looks like it's part of the system.

Personally, I really like Pinta. Biggest problem is the bugs and crashes. Wish I could use actual Paint.net though, but there's no way to use it on Linux.

In other words, a fork?

Or how does the semantics of patch/changes/update differ in any way from maintaining a fork? The packaging has nothing to do with this. It may not be a well-maintained fork, the maintainers might not see themselves capable of adding features and bugfixes on their own, but a fork is a fork.

I agree with this - you need to change a few settings unless you're an absolute purist - but once you have done that, it's basically a nicer, well-maintained professional Firefox fork

It can have severe performance implications in some areas with very bad internet bandwidth. Also it makes instantiating a global cache more difficult. See: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... Another POV: https://brr.fyi/posts/engineering-for-slow-internet And https://danluu.com/web-bloat/ also has some minor numbers

Linking to my own comment: https://news.ycombinator.com/item?id=31040629#31043115

I've been working on an extension https://github.com/phil294/search-plus-plus-vscode-extension for instant search results in gigantic repos like this one because it's a recurring pattern that bothers me. And eventually I'd like it to use its index to provide full go-to, autocomplete etc. on a pure plain text basis, because why not? I don't get the obsession with full-fledged language integration when plain text-based search results can get you all the way 9 out of 10 times, whereas a typical language plugin will constantly suffer from brokenness, performance problems and general annoyance, unless maybe you're working in pure JS/TS. And while LSP is great, you still have to fight this battle separately for every language you use. And regular "search" features are dreadful too.

It's one of these things that Jetbrains products are vastly superior in. It's fast, always works, falls back to text matching and also natively allows multiple languages per source file.

I like it, it's surprisingly fun to play. When played in groups (with changing words), this game would be well suited for non-natives learning English.

Because it's infinitely less work than starting from scratch. It's a valid argument.

That doesn't contradict the parent comment though. Engaged users should have an option somewhere to enable it, barely affecting the overall rollout.

> apparently the same people

The only thing these two groups of people have in common is that you don't like them. I fail to see any correlation here whatsoever.