This list alone has saved me many late debugging nights, just by not making or using systems that ignore the list.

[0]: https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

But in my experience, webp is better enough that the whole file loads around the same time the jpg progressive loading kicks in. Given that progressive jpgs are larger than non progressive (so not a 'free' feature), jpg is just a waste of bandwidth at this point.

In general, I recommend people back up binary files to cloud storage, like S3, and only commit optimized, deployment ready assets to git. There's also GitLFS, but it's clucky to use.

Ideally, images are compressed _before_ getting committed to git. The other issue is that compression can leave images looking broken. Any compressed image should be verified before deploying. Using lossless encoders is safer. However, even then, many optimizers will strip ICC profile data which will make colors look off or washed out (especially if the source is HDR).

Finally, use webp. It's supported everywhere and doesn't have all the downsides of png and jpg. It's not worth it to deploy these older formats anymore. Jpgxl is ever better, but support will take a while.

Anyway, I made an ImageOptim clone that supports webp encoding a while ago[0]. I usually just chuck any images in there first, then commit them.

[0]: https://github.com/blopker/alic

Everything we do is open source too[1].

[0]: https://www.totem.org/ [1]: https://github.com/totem-technologies/totem-server

The WIP code was committed with the expectation that very few people would see it because it was not linked anywhere in the main readme. It's a calculated risk, so that the code wouldn't get out of date with main. The risk changed when their LLM (wrongly) decided to elevate it to users before it was ready.

It's clear DeepWiki is just a sales funnel for Devin, so all of this is being done in bad faith anyway. I don't expect them to care much.

Yes, there is a VS Code folder in that repo. However, it doesn't exist as an actual extension. It's an experiment that does not remotely work.

The LLM generated docs has confidently decided that not only does it exist, but it is the primary installation method.

This is wrong.

Edit: I've now had to go into the Readme of this extension to add a note to LLMs explicitly to not recommend it to users. I hate this.

I hope actual users never see this. I dread thinking about having to go around to various LLM generated sites to correct documentation I never approved of to stop confusing users that are tricked into reading it.

[0]: https://deepwiki.com/blopker/codebook

It sounds ok, but impressive for the size.

Comments URL: https://news.ycombinator.com/item?id=44456568

Points: 2

# Comments: 0

Not exactly where I'd like to see us go, but at least we'll never get outdated information.

Comments URL: https://news.ycombinator.com/item?id=43785278

Points: 5

# Comments: 1

CSpell is the thing everyone uses in VSCode, but they don't offer an LSP for other editors to use. Someone has made an LSP for it, but CSpell is also pretty slow since it's all in JavaScript. After spending way too much time[0] trying to find an alternative, I just wrote my own.

Codebook[1] is written in Rust, so it's very fast, and (IMO) is much less annoying than CSpell because it uses Tree Sitter to only find spelling issues that the developer has control over.

Codebook also comes with an LSP, so it could be used in other editors, but I haven't tried that yet.

I want to also shout out to Spellbook[2], which is the actual spell checking engine I used to make Codebook. The makers of Helix wrote it, and it's fantastic.

[0]: https://blopker.com/writing/09-survey-of-the-current-state-o... [1]: https://github.com/blopker/codebook [2]: https://github.com/helix-editor/spellbook

Comments URL: https://news.ycombinator.com/item?id=43198928

Points: 4

# Comments: 1

Django's biggest issue is their aging templating system. The `block`, `extend` and `include` style of composition is so limited when compared to the expressiveness of JSX. There are many libraries that try to solve Django's lack of composition/components, but it's all a band-aid. Today, making a relatively complex page with reusable components is fragile and verbose.

The second-biggest issue is lack of front end integration. Even just a blessed way of generating an OpenAPI file from models would go a long way. Django Ninja is a great peek at what that could look like. However, new JS frameworks go so much further.

The other big issue Django has _is_ solved by Cot (or Rust), which is cool (but not highlighted): complicated deployments. Shipping a bunch of Python files is painful. Also, Python's threading model means you really have to have Gunicorn (and usually Nginx) in front. Cot could have all that compiled into one binary.

In Bottle, returning a generator or iterator will send the response in chucks, instead of all at once. The effect would be that the test results load in one by one, providing the user with feedback. No JavaScript needed.

There's not really a backend that takes advantage of all that. In theory, one server binary could handle REST, web sockets, background workers, and have generated type safe client packages for every platform. Dart also has a great Rust ffi story. It would be great to see that leveraged.

ServerPod is a great start, but it's really Flutter focused. The web apis feel like second class.

Additionally, database management isn't a solved problem yet. ServerPod uses yaml to define models, and the other main option is just a Prisma wrapper. Dart needs something like Drizzle.

I wish the Dart server ecosystem was more mature though. Being able to compile Dart into a static binary is so nice for deployment.