HN is full of noobs loudly proclaiming what they don't know is true these days. Ubiquitous HTTPS does not change the nature of private browser caches, and only nullify the proxy related cache headers if the origin encrypts traffic all the way to the client, which is quite rare in real life, unless we are merely talking about a dude serving this blog from his basement computer.
In general, your answer depends on where the TLS cert terminates. In most situation a CDN or a reverse proxy is involved, and the TLC cert you use to encrypt traffic from the origin to the proxy is different from the one the proxy uses to encrypt traffic from it to the browser. Whenever a MITM intermediary is involved, you should read the intermediary's documentation. These usually include Cloudflare, AWS Cloudfront, Akamai etc. With with exceptions, like the Vary header as pointed out elsewhere, these vendors largely follow HTTP caching semantics for proxy caches.
While I'm happy that simultaneously there are at least 5 known Emacs/Claude Code integration packages, with seemingly 2 or 3 battling it out on Reddit and elsewhere, I feel like the best implemented one is the quiet one that no one has ever talked about.
I just tried it. It does not support /ide integration. You can test this by typing /ide in claude code. MCP support is not the same thing as IDE support.
Oh you mean something like active file awareness and selection context? This code seems quite well architected and has websockets well integrated, both features sound like a lunch break’s worth of work if you file a ticket. Other than that, I couldn’t care less about how these capabilities are implemented or whether /ide works.
The UK has a petition website. It logs the signatory by constituency. Once a threshold os signatory has cross, the government has to respond and parliament will have to consider a debate on the topic.
I swear if I see another "SEO" guy or some rando web dev who joined the workforce after Covid complaining about SPAs by misrepresenting it, I'm gonna explode.
As someone who's been developing web apps since the 2000s, let me tell you the origin of SPA has few things to do with the "false promise of SPAs" he listed, but largely due to companies in the late 2000/early 2010s wanting to go "mobile first". This usually meant they still had a desktop second somewhere, which implied they were architecting the entire system to completely separate the frontends and the backend.
Before, what web devs meant by frontend was essentially server-side rendered HTML templates with perhaps a little bit of jQuery running on the client-side. Now, since mobile and desktop web apps are to share some business logic and the database somehow, people had to rediscover REST by reading Roy Fielding's Phd dissertation that inspired the original HTTP. This meant now every company was moving to service-oriented architecture and started exposing their backend APIs onto the open internet so their mobile apps and SPAs running in the browser can share the same APIs. This was a cost saving measure.
This period also coincided with the steady decline of full-stack webapp frameworks like Ruby on Rails and Django because for a couple of years, these frameworks had no good ways to support an API only applications. Django hadn't even reached 1.0 back then. This was a time when NodeJS was really starting to pick up momentum. Once people had started being more comfortable with JS on the server-side, lots of people suddenly realized they could push a lot of business logic to increasing powerful desktop browsers and phones, application hosts people now call "edge devices".
This is the true impetus of SPA. How is CSS going to kill this need?
Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region.
I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.
Most people and even most companies don't need horizontal scaling. Hardware has been much faster and cheaper since Heroku's heyday. Scaling vertically with 80+ cores on a single CPU and 256gb+ of ram only costs a few hundred dollars a month these days. With caching on a server like that, it can handle a million requests a second, or tens of thousands a second for dynamic data from the database on the same server.
If Deno were supported on AWS Lambda I might think about using it. FaaS on a major infrastructure provider is what I need. I'm not putting a project that means anything to me on Deno's servers, they aren't really leading the industry and might not be around in the blink of an eye the way the tech world is going lately.
An equally important but opposite problem with pipes getting stuck is pipes getting broken because some commands at the front of the pipe expects buffering down the pipe. Some years ago I was scratching my head trying to figure out why
curl ... | grep -q
was giving me a "Failed write body error". I knew "grep -q" would close stdin and exit as soon as a match is found, and therefore I needed a buffer in front of grep but I was on a Mac, which to this day still doesn't come with "sponge" (or stdbuf and unbuffer for that matter), so I had to find a cross-platform command that does a little buffering but not too much, and could handle stdout being closed. So I settled on:
curl ... | uniq | grep -q
To this day people are still confused why there's not a "sort" in front of uniq and the comment about this cross-platform buffer thing I put in the script.
Literally every open source RISC-V Chip, SoC and Board I know are Chinese, aside from SiFive. Alibaba T-Head Xuantie C9-series and E9-series CPU cores, StarFive JH7110 SoC, Alibaba T-Head TH1520 SoC, SOPHON SG2042 SoC, StarFive JH8100 SoC (TBA), several RISC-V boards from Milk-V, BananaPi and SiPeed which are state of the art RISC-V boards.
I think US are the ones doing less.
Edit: Just realized SiFive was US based, not Chinese, so edited it out.
Yes, but I'm only talking about Chinese ones here. And considering just the open source boards, as I did, SiFive only has their Freedom series chips and boards, and their contributions to the Rocket Chip project.
All the Chinese ones I listed are open source designs.
An open source ISA is a collaborative effort, and it contains several members, not just from the US. And it was inevitable either way. Going against who uses an open source an open source ISA is against open source, and going against open source is capitalist greed.
I won't be debating that, there are plenty of resources to read on it and it's a big topic if you are so deeply opposed to it.
And even if you hate China, it does not justify the opposition to using an open source ISA as a whole. It benefits everyone around the globe, and USA is not a special country. Others can use the ISA just the same, and it's better for them to do so.
You guys thinking in terms of countries is just as big of a problem, but again I don't have the time for that philosophy.
Let me know when you have an example of an open source Chinese industry standard, essentially subsidized by the Chinese government. The only example I can think of is Beidou, which nobody uses.
> an open source Chinese industry standard, essentially subsidized by the Chinese government
Hey I do have an example: Richard Stallman's only computer is a Lemote Yeeloong netbook (using the same company's Loongson processor https://stallman.org/stallman-computing.html
except iPhone 11/12/13/14/15 (with the XMM 7660 chip) and every Android phone using Qualcomm iZat chip (shipped with almost every Snapdragon processor since 2013)
And it's not "open-source" per se, Beidou is just some kind of satellite signal that happens to be compatible with GNSS protocol, so chip makers and make few tweaks to provide location service.
iPhone since 12 has not used the Intel modem, and while newer iPhones supports Beidou, it’s not clear which chip supports it and whether it is used outside of China, or even iPhones sold outside of China has support for Beidou. Even if it does, its civilian frequency only has a 10 meter accuracy outside of APAC, so it’s not clear to me it is used globally in the sense that GPS is.
Also, Loongson and OpenATOM lol. Are they industry standards?
Why? There are plenty of older useful sites which work just fine over HTTP. If you mean for cases where https is supported, but link is http - I agree.
There are plenty of good reasons to use HTTPS. [0]
It doesn't make sense to link to HTTP when the site works fine over HTTPS, which is the case here. I'm not sure I'd want to completely ban all HTTP though.
Honest question: what is the consequence of visiting an HTTP link rather than HTTPS for a site where my interaction is read only? Is there some security issue? Or is it privacy concerns.
The privacy issue is that your local WiFi provider, direct isp, and all the intermediate isps can see not only which site you visit, but all your activity within that site (like which pages you visit or things you download).
The security part is that any of those who can view can also do a “man in the middle” attack. Comcast could decide to send you a different version of the website that was more favorable to their company, or inject ads (ISPs have been known to inject ads on sites they don’t own before https was big).
A hacker could send you a version that gets you to download malware by replacing content or links. They can see and effect everything you do and see in such a site if they can intercept your request.
Is that still the case tho? Recent Deno releases have obscured how well it's Node compatibility mode is, I was just wondering if you have more details.
In general, your answer depends on where the TLS cert terminates. In most situation a CDN or a reverse proxy is involved, and the TLC cert you use to encrypt traffic from the origin to the proxy is different from the one the proxy uses to encrypt traffic from it to the browser. Whenever a MITM intermediary is involved, you should read the intermediary's documentation. These usually include Cloudflare, AWS Cloudfront, Akamai etc. With with exceptions, like the Vary header as pointed out elsewhere, these vendors largely follow HTTP caching semantics for proxy caches.