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