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

331–340 of 463 posts

Re: Fresh – Next-gen web framework

#331

Post by solardev »

rambambram wrote: post #294
solardev wrote: post #90

Earlier quoted context omitted.

For responding to user interactions (like filtering or searching) there isn't really a significant difference; like you said, it's just moving the "wait" elsewhere. But many sites are more heavily read than interacted with: blogs, news, documentation, even to some extent HackerNews and comments. These are all "write rarely, read often" sites. In those cases, prerendering can be way faster both for the end-user (it's…

That first one was way quicker for me. Might also be because I'm in Firefox on a RPi 4.

Sometimes it also depends on whether your local CDN edge has a hot copy. You could try a forced refresh and see if it's faster the second time? Up to you :)

The Drupal version is seeing production traffic, while the Next version only sees a few devs now and then.

Re: Fresh – Next-gen web framework

#332

Post by psadri »

WuxiFingerHold wrote: post #267

The next-gen SPA frameworks/libs like SolidJS or Svelte are already very fast and more importantly very small in bundle size. At least much faster and smaller than React or Angular. Therefore the advantages of SSR frameworks like this new one are much smaller when compared to e.g. SolidJS. The performance claims made for this new framework need to be proven by benchmarks. Check out this SolidJS Hackernews clone (Clie…

The problem is accessing backend data sources. Fetching that data in the first request and responding with server side rendered html > serve js that then initiates network calls to get that data (while showing a spinner in the ui)

Re: Fresh – Next-gen web framework

#333

Post by solardev »

fauigerzigerk wrote: post #117
solardev wrote: post #59

Earlier quoted context omitted.

(I am not affiliated with any of these technologies, but am a Next/Vercel customer. I am also not super familiar with anything except Next, but this is my attempt at an explanation.) I think they all try to solve the same problem: how to get a modern interactive app to run on (and be performant) what is essentially a hacked-together ecosystem, HTML + Javascript, with decades of backward compatibility baggage. The ess…

>Seconds later after the HTML has loaded, some "bootloader" JS then downloads all the other JS that enables interactivity... So until that happens the UI looks functional but isn't. The user is left to tap/click furiously on that button but nothing happens? It sounds to me like this is only suitable for pages where interaction is an exceptional thing that users will only attempt to do after reading some content.

I throttled it down to Chrome's "slow 3G" setting and it still worked fine. The filters were active as soon as the page displayed, though the images took a lot longer to load after that.

There might be cases where the issue you describe occurs, but I haven't actually seen it in testing. If it's a concern, you could of course add throbbers or the such. But generally, in our limited tests, it hasn't been an issue.

Still, it is an issue they (and the React ecosystem) are actively working on improving, with React Suspense (https://17.reactjs.org/docs/concurrent-mode-suspense.html) and Next.js Layouts (which I understand is copied from Remix(?) and can fetch component groups in a hierarchy https://nextjs.org/blog/layouts-rfc). There is also server components and streaming, which can render HTTP snippets/components (instead of pages) and send those back over the wire, similar to the PHP days: https://nextjs.org/docs/advanced-features/react-18/streaming

But again, the benefit is mostly to the developer experience. It's a lot easier to write everything in React than to have to switch between PHP and Drupal (as in the admin UI) and JS. There are some benefits to the user experience if done well, but the same could be said of a statically cached Drupal output.

Re: Fresh – Next-gen web framework

#334

Post by solardev »

xmprt wrote: post #131
solardev wrote: post #59

Earlier quoted context omitted.

(I am not affiliated with any of these technologies, but am a Next/Vercel customer. I am also not super familiar with anything except Next, but this is my attempt at an explanation.) I think they all try to solve the same problem: how to get a modern interactive app to run on (and be performant) what is essentially a hacked-together ecosystem, HTML + Javascript, with decades of backward compatibility baggage. The ess…

What happens when the user interacts with the page while it's being rehydrated? Is that click eaten, does the user see some error, or does the page remember the click and run it when it has pulled in the relevant js?

I am not sure how it works behind the scenes -- honestly, that's one of the drawbacks of Next, in that a lot of it just "black box magic" -- but it still seems to work fine when we throttle down to 3G. I am not sure how it decides which scripts to hydrate in what order... we were saving that optimization run for the end, but I changed jobs before that could occur (sadly).

There are some ways to work around that, if it actually turns out to be an issue (which it wasn't for us)... discussed it a bit more in my other response: https://news.ycombinator.com/item?id=31727249

Re: Fresh – Next-gen web framework

#335

Post by csmpltn »

tomnipotent wrote: post #315
ratww wrote: post #263

Earlier quoted context omitted.

While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered. This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP u…

> argument is that the techniques themselves were "forgotten" and are now being rediscovered Which is a silly, lazy argument. > by people claiming that the term "Server Side Rendering" can't be retroactively applied Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other…

> "The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR."

Can you provide even a single example for something we can do with JS running on both the client and the server, that was otherwise "impossible" (quoting you here), or very difficult, without this capability?

Re: Fresh – Next-gen web framework

#336

Post by datalopers »

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…

The fact that you think it’s materially different is amusing. The only “magic” here is injecting JS shims to handle bidirectional syncs for certain components (“islands” in their parlance). That is also something we’ve had for a very long time, though admittedly it was kludgy as hell two decades ago (ajax polling, SSE, long-polling, comet, etc).

Re: Fresh – Next-gen web framework

#337

Post by eyelidlessness »

DylanSp wrote: post #329
eyelidlessness wrote: post #318

Earlier quoted context omitted.

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.

Yeah this looks much more similar to Qwik. It even looks like they have a similar view serialization approach.

Re: Fresh – Next-gen web framework

#338

Post by mikojan »

WuxiFingerHold wrote: post #273
solardev wrote: post #12

Ooh, some competition for Next.js? Vercel is doing a really good job with Next, but it's good to see some competition. Of course, that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's…

Depends on your SPA framework: https://hackernews-csr.ryansolid.workers.dev/ No need for rehydration, I'd say. Combine this with code splitting for large apps.

Maybe besides the point but this is falling back behind modern HTML[0] in that it is reintroducing flashes of blank pages.

It's not a nice experience. Remix (and, most likely, Fresh as well) prevents this.

[0]: https://developer.chrome.com/blog/paint-holding/

Re: Fresh – Next-gen web framework

#339

Post by AtNightWeCode »

francis-li wrote: post #43

Ryan Dahl talks a bit about it in this talk at Remix Conf 2022: https://www.youtube.com/watch?v=4_nxvVTNY9s&t=10781s He describes it as a post-Unix web framework (i.e. built on serverless primitives like cloudflare workers/deno deploy) with the goal of <10s deployment (which he says requires JIT compilation on first-request)

He really is the JS server-side sect leader. Plain wrong about so many things you lost count while he talks. Glad that the JS community, not that I am fan, left this dude behind.

Re: Fresh – Next-gen web framework

#340

Post by ratww »

tomnipotent wrote: post #315
ratww wrote: post #263

Earlier quoted context omitted.

While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered. This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP u…

> argument is that the techniques themselves were "forgotten" and are now being rediscovered Which is a silly, lazy argument. > by people claiming that the term "Server Side Rendering" can't be retroactively applied Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other…

> Show me one such claim

In this thread: https://news.ycombinator.com/item?id=31723357, https://news.ycombinator.com/item?id=31723746, https://news.ycombinator.com/item?id=31724418

> The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary.

Sure it does, but this doesn't mean that PHP wasn't rendering on the server. The term still applies to what PHP was doing.

> Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR.

Pointing out those unique opportunities is not a problem, and I agree with you on that. But it has absolutely nothing to do with the usage of SSR or the term SSR. Also, using the same language on server and client is older than modern JS frameworks, which definitely counts as something being "rediscovered". And yes, is definitely a cool thing, nobody is claiming the contrary.

Post reply on HN