Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fresh – Next-gen web framework

fresh.deno.dev

Post reply on HN
Print view View original

321–330 of 463 posts

Re: Fresh – Next-gen web framework

#321

Post by e12e »

indymike wrote: post #270
e12e wrote: post #215

Earlier quoted context omitted.

> People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months. Well, kind of. The thing is that the natural progression from server side rendering/content-generation with only html and…

> There's a real tention between "application" and "document system". Not really. The web implements a "document as application" or "living document" model. Since the most rudimentary software is just printing static text (and static graphics) you get quite a bit of mileage with just HTML & CSS. The web scales nicely from this to fully interactive applications, and I think some of the tension you are perceiving comes…

I think you misread my comment - obviously hypertext systems are "applications" for some definition of "application" - but there are distinct types, constraints and architectures. Mysql and php are not my first choice for creating a multi-player driving game - and even for an irc client they're not my first choice. However, for an asynchronous message board, news or mail client they might be fine.

Re: Fresh – Next-gen web framework

#323

Post by LeanderK »

redbar0n wrote: post #251
LeanderK wrote: post #148

Earlier quoted context omitted.

if the code is the same on the server, one could serialise the state and transfer it with the html, right?

that’s how it works, but you also need to attach event handlers and set up the state for the framework on the client-side (for subsequent interactions).

I meant the state for the framework, as I understood it the same framework was used on the serverside.

Re: Fresh – Next-gen web framework

#324

Post by eyelidlessness »

ash wrote: post #149
LeanderK wrote: post #148

Earlier quoted context omitted.

if the code is the same on the server, one could serialise the state and transfer it with the html, right?

You still have transfer the JS.

Right, but not all of it. The way Qwik serializes it is (this is from memory and probably overly simplistic, but conceptually approximate):

- Primitives already present from the server render are serialized directly into the HTML, and the compiled code reads those values from the DOM

- Everything else is split into fine grain chunks, assigned a special identifier (Qwik uses URLs) which is serialized to the HTML to fetch (which can be eager or on-demand) and activate interactivity as needed

My understanding is that currently Qwik serializes more than necessary—i.e. can be optimized further to eliminate non-interactive chunks from consideration—but that they’re focused on reducing JS cost first.

Re: Fresh – Next-gen web framework

#325

Post by roci89 »

jjdeveloper wrote: post #277
chrisweekly wrote: post #218

Earlier quoted context omitted.

https://Remix.run is the real competition for (/successor to) Next.js. It can target a Deno runtime so I guess it's competition for "Fresh", too.

I think Astro is more likely the successor to Next.js and probably not remix. I think Next will steal the best parts of Remix but Astro was built with simpler foundations and has integrations for deno with Netlify edge functions among others and unlike Remix is not tied to React but you can choose your framework.

Remix is working on a Vue and Preact adapter, so won't be tied to React for long. I see the community is looking at a SolidJS adapter too. I'd say it'll be just fine

Re: Fresh – Next-gen web framework

#327

Post by [deleted] »

jchw wrote: post #119
datalopers wrote: post #15

Quoted post unavailable.

I'm really sad that this sort of attitude is common in Hacker News. I am not a huge fan of JS, but what I hate about this is not that it's critical of JS, but that it's clearly just a knee-jerk cynical reaction. This framework in question is not doing what PHP/Ruby frameworks were doing. Whether what it's doing is a good idea or not is neither here nor there, it's just simply that you aren't understanding what it is…

[deleted]

Re: Fresh – Next-gen web framework

#329

Post by DylanSp »

eyelidlessness wrote: post #318
DylanSp wrote: post #243

Earlier quoted context omitted.

> A more granular approach—termed resumability by Qwik and as I understand it the forthcoming version of Marko—works by treating the server-generated HTML as the initial state. The code executed from there is much more isolated than a full component. Is that sort of what Phoenix LiveView does? Return a fully server-rendered page on initial load, then set up a "template" on the client side that can receive any values…

This sounds conceptually similar, albeit maybe more similar to React Server Components? I’m really not familiar enough with Phoenix to get that specific though. Even in the JS ecosystem there’s a lot of nuance between seemingly similar approaches (hence why even commonly referenced concepts like hydration can be confused for what they actually do).

I think what Fresh is doing now is more similar to Server Components, shipping full components to the client. With LiveView, once it's set up on the client, the updates it sends over the wire are much smaller. https://fly.io/blog/how-we-got-to-liveview/ shows some examples of the idea.

Re: Fresh – Next-gen web framework

#330

Post by no_wizard »

ZeWaka wrote: post #65
gavinray wrote: post #30

> "The framework uses Preact and JSX for rendering and templating on both the server and the client." Really nice to see Preact used here, it's a much more rational choice than React if you were planning on using React anyways. I set Next.js up to use Preact as the engine but it takes a bit of config work to do this and isn't an officially/OOTB supported feature.

If you're into React but faster, there's InfernoJS, which is basically React/Preact but /even faster/: https://www.infernojs.org/

no hooks yet though, which limits compatibility and arguably developer experience. Preact has better compatibility - if that's something you're looking for anyway. I suspect that was part of the motivation as well. Also, Preact is 3KB full, inferno is 7.2 KB, if I recall correctly, may have also been a motivation here.
Post reply on HN