phil294

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