Hacker News Reader

Comment by manigandham | Hacker News Reader

Fresh = Deno version of Astro (static-first with SSR) and Isle (vue-focused) and bigger Next.js/Nuxt SSR (with no client js) modes. Remix also does well here with a focus on only SSR.

It's basically what the original "isomorphic" javascript promise was to have the same code seamlessly running on server and client with a flexible split on what part ran where, now possible down to an individual tag/component.

Also worth mentioning projects like .NET Blazor, Phoenix Liveview and Rails Hotwire that approach client interactivity through their own backend languages instead of JS, usually with some partial refresh mechanism using AJAX or websockets.

View on HN

> Deno version of Astro (static-first with SSR) and Isle (vue-focused) and bigger Next.js/Nuxt SSR (with no client js) modes.

I think you have just summoned Cthulhu.

yeah, i was starting to feel queezy...

> code seamlessly running on server and client with a flexible split on where that would be

It's a sound idea. Ideally this would fall back nicely when JS is disabled to good old get/post requests. It'd enforce a stricter mental model of what's a "page" and the boundaries between them. Currently, with JS component libs, this concept is somewhat blurry.

Does that mean JS running server-side? That's a full-stop dealbreaker for me.

Deno is a JS runtime like Node, so if that's not your thing then yeah, this isn't for you.

Many Node-based JS frameworks, such as Gatsby or Next, allow SSG that can be distributed by a CDN. Your comment is weird.

Dynamic responses also can be cached in a CDN you know...

The whole point of static site generation is that you don't have to manage servers; that you can instead simply generate your assets and distribute them via CDN. Sure you can manage servers and put a CDN in front of your servers, but then you still have to manage those servers...

Anyway, you're missing the crux of my point. I was criticizing GP for implying that all NodeJS-based frameworks require a dynamic server to run respond to queries at runtime. They don't.

Could you elaborate why? I’m finding the concept appealing, but would like to learn more about the tradeoffs.

Yes that’s part of the point. I’m not sure there is a name for these, I just call it frontend server. You don’t necessarily have to put your whole application there, but can focus on client interactions, and these things are really good at that.

Sorry, this is just funny considering how JS-on-the-server has become a (the?) dominant web paradigm among startups and newer tech teams. It's like a comment from 2014.

Just because it is the dominant paradigm doesn't mean it is a good paradigm.

Remember PHP was a dominant paradigm for a long time. (I actually don't dislike PHP that much myself but it is a good example since many dislike it intensely.)

Edit: JS, until TypeScript, had almost all the disadvantages of PHP (bug prone syntax, lack of typing, inconsistent ordering of method parameters etc) but not PHPs advantages (shared nothing, fast dev cycle). The only advantages JS had was that it looked cleaner and that one could use the same language frontend and backend.

Reply on news.ycombinator.com