lightningspirit

Good to know you're still building your own tools like back in the "old days" :)

And then everybody left, yeah, I remember this exactly.

I think we're comparing two very different categories. COBOL is an application language, whereas TCP and HTTP are foundational infrastructure. Replacing a language is challenging, but replacing the infrastructure that underpins most of the Internet is orders of magnitude more complex due to the sheer number of interoperating systems.

HTTP accounts for roughly 70-80% of global web traffic, and if you narrow it to TCP-based application traffic, its dominance is closer to 95%. Comparing HTTP to COBOL is a bit like comparing trucks to bicycles...

{"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries

These two payloads are actually different. You're talking about semantics, which is determined by the payload format; in the case of JSON, these two are semantically similar.

GET gets this for free because the URL is already a normalized string

It's the same principle; the order of properties matters too.

This is controlled by the (Last-Modified, If-Modified-Since) and (ETag, If-None-Match) header pairs. HTTP is stateless; it does not require any persistence. The only thing that defines kind of an optional persistence is the caching layer, for obvious reasons.

How does the origin server indicate that?

I don't think this requires so much discussion; it is a very obvious and simple addition, IMO.

How does this break rest?

It won't break GraphQL, as it uses POST. It can very much improve it if adopted: - use QUERY method when querying resources - use POST method for mutations

Because HTTP is stateless by definition, you now need to support persistence (state) on the server side whenever you want to run a slightly different query, which contradicts the preamble.

I understand the confusion around GraphQL's cached/persisted queries, but this is not the intention of HTTP.

The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc.

Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.

I think most of the value LLMs provide comes from connecting the dots between unsolved questions and patterns or structures that have already been demonstrated, which accelerates research.

Now, reasoning in the sense of making truly original discoveries, as Einstein did with the field equations, is a different story for current LLMs.

Yeah, I was surprised by that as well.

If there's only a centralized system that uses digital IDs to hand off providers only a "yay" or "nay"...

That makes sense. Wi-Fi uses radio waves, part of the light spectrum. Like our eyes or cameras can watch and record, Wi-Fi can also be used for this purpose.

If you do `new Date('2025-11-31T00:00:00Z')` you get `2025-12-01T00:00:00.000Z`, which is weird and potential cause for bugs when parsing date string from input. Right because of these inconsistency I created a small package backed as Regex to validate Date string input before throwing it on `new Date(stringDate)`.

https://www.npmjs.com/package/iso-8601-regex

I like this solution, it looks very simple and should’ve been consider as part of best practices if it works technically. However, I also think that this whole trade off is broken from the beginning, it should be part of browser’s set of rules to either decide or not it should render the image or not by default, and the decision of eagerly load an image should just an hint given by the developer as a scape hatch. The current approach forces the decision to be forcefully deferred to the application which needs to guess what’s the best approach for the current set of devices in the market which also adds a constant maintenance burden.

It is mentioned in the article that round-robin DNS is an alternative to this setup, however, in reality, it is not the same thing, and that's the reason load-balancers exist, and it is not feasible to provide something very similar due to the very nature of a distributed and cached DNS system.

In that case, can you reduce pricing for customers, too?

I've been using Docker Swarm for almost 6 years now deploying entire stacks for customers on top of it — it's stable and incredibly cheap to maintain.

The balance example should have been explained in more detail — it’s clearly a transactional system where the balance is derived from the sum of transaction log data. CRDTs have nothing to do with it and it is a bad example.

Matt also knows that the messy WordPress API (both actions and filters) is difficult to integrate into a well-architected software project as a plug-and-play mechanism.

Actually, when someone forks a project creates a new repo. This is not the case, the plugin was indeed a take over instead.

Although jq query style is not absolutely pleasant I see many examples where this tool can be used such as data transformation, import/export and linux pipelines that need access to databases.

Docker (and to an extend, Docker Swarm) is a good alternative where simplicity, lightweightness and stability are key points. Using it for almost 4 years in many projects with thousands of views each day, both on single or two VMs. No failures, no surprises, no pitfalls, automated CI via Git. No devops required.