> yes I know what I'm doing and this over-cautious compiler case genuinely doesn't apply to me and there's no way to configure that so it actually lets you do your job
I'm curious why you didn't use `unsafe`?
In general people are really bad at knowing when the strict safety rules are actually being too strict, but if you're confident they are then using `unsafe` seems like a valid path to explore.
An optimized fine grained payload with compression can out perform the course approach. Course payloads have added cost to swap in the DOM, and fine grained payloads don't require complex architecture.
Asides from rendering I have additional concerns about course SSE payloads. You basically remove any cache capabilities (though this is common with all update streaming approaches). Uncompressed the payloads are quite large and the browser may not be able to dispose of that memory, for example Response objects need to hold all body data in memory for the lifetime of the Response because it has various methods to return the whole body as combined views of the buffer. Also benefits of compression for SSE payloads are going to be drastically reduced in situations where connections easily get dropped.
IP Address is all you need to get fairly accurate (town or neighborhood) location for most of North America.
But it is necessary to send it somewhere, otherwise the internet wouldn't work.
Unfortunately it seems to have become accepted for our devices to communicate constantly and often with services we never explicitly started communication with (like Ad networks used in Apps).
Permission systems on devices should care about Network connections just as much as Location. Ideally when installing an app you'd get the list of domains it requests to communicate with, and you could toggle them. Bonus points if the app store made it a requirement to identify which Domains are third parties and the category like an Ad service.
Mine too. People seem to have are hard time conceptualizing the hour as an arbitrary number, rather than having a static (usually incorrect) meaning associated with it like 12 as noon/midnight.
Not hard, visualize the locations on the globe and a pie with 24 slices. If you start work at 12, and you want to know when someone 2 slices West will start you add 2 to get 14. 2 slice East of you, subtract 2 to get 10.
Better than guessing what timezone the region picked when it spans multiple natural time zones, and whether they do or don't have time changes.
Also it's much easier for communication, because if someone sends you a message asking to have a call or meeting at X hour there's no need to know their timezone, because your X hour is the same as theirs no matter where you are in the world.
I'm more bothered by pretending WebMCP will actually help. More than likely we'll end up seeing dark patterns emerge like sites steering the AI to book more expensive flights and hotels from ad placement.
Because that would make too much sense, and MCP is trendy. Also probably more likely is people don't want to spend effort creating sensible http APIs, instead they like using frameworks like Next.js that strongly couple client and server together.
Jokes on them though if they want this to work, they'll have to add another API, but now on the client code and exposed through WebMCP.
reply