Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think that any view cache works fine with edge caching. Worst case your first request has to traverse the CDN network to your compute once every cache invalidation.

That said, none of the static site renderers really do anything special that is required to do anything on any edge. Considering the huge amount of storage and memory required to store a node_modules tree and re-render on demand, even classic MVC would easily do the same.

What would make a somewhat larger difference might be a combination of factors; something like centralised push and distributed compute via WASM. That means any logic could be compiled and packaged as-is without needing anything else. Somewhat similar to using cloud flare workers with something like Go or Zig.

Then again, like you described with the rails example, this is mostly a solved problem. Even a full server-side view with just classic HTML 4 and CSS output can do this, at very low latencies and very wide reach. After the first hit, the difference between this and static pre-rendered pages is almost irrelevant.

The biggest 'solves' one might get would be uncached always-computed content which needs to be executed on demand, and attack surface changes. But that gives us a different class of problem since we could also decide to simply offload all of the hard work to someone else and simply pay Squarespace and the likes ;-)



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: