Live data from Hacker News

Fresh – Next-gen web framework

fresh.deno.dev

171–180 of 463 posts

Re: Fresh – Next-gen web framework

#171

I don't fully understand the difference between this (and something like Remix, which seems similar) and other frameworks like Next.js (React) and Nuxt.js (Vue). Can someone explain a bit about the differences, and pros/cons to each?

(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…

at the top you mentioned "Rails". Rails handled the backend. You defined database schemas. It built forms to edge them. To a certain level you install got a working front end and backend.

Where does Next fit here?

Re: Fresh – Next-gen web framework

#172
post #168

> Island based client hydration Software development already has its own vocabulary, but I feel quite ignorant now.

It only makes sense to the con artist that put it on their resume first.

Let me try:

Hair dry volcano hydration off the cliff only, no added sugar.

Re: Fresh – Next-gen web framework

#173

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…

> except you can write code like it's not the old days.

I imagine you mean that writing (frontend) code now a days is better than how it was in the old days. Well, at least from my perspective that's not the case. "Modern" frontend code requires:

- a package manager (npm)

- node (or deno or whatever)

- transpilers (or is it plugins?)

- TS

- 10K+ dependencies

And to be honest, what is all that good for? To being able to "hydrate" some server-side rendered template? Not good enough reason.

Re: Fresh – Next-gen web framework

#174
That's funny how many smart people understand that web is a giant pile of hacks on top of hacks, and how incredibly important web for modern apps distribution (I bet you buy tickets, pay invoices, do you medical check ins etc on web apps), and yet leaders of this ecosystem do not even ask the question whether foundation of web (html/css/js) is even a good solution.

Instead they create new hacks.

Island based client hydration, right.

Re: Fresh – Next-gen web framework

#175
post #168

> Island based client hydration Software development already has its own vocabulary, but I feel quite ignorant now.

Knowing what it is now, describing it that way makes total sense... but it only works for people after knowing what it is... kind of like an inside joke.

For anyone wondering what it means: it ships only the JS for select components (usually ones that have some sort of client-side interactivity, such as the incrementing counter on their demo page), so it only has to hydrate that part (where hydration is reconciling the client bundle execution result with what is actually on the page).

This is opposed to the standard way React works which is the entire JS used to render the page—even the static non-interactive bits like plain HTML—is shipped to the client and all your function component functions are run (just without the actual inserting DOM elements again if SSR is used).

React is currently developing server rendered components that works with streaming SSR introduced in React 18 that delivers this same functionality. Basically your app can then be composed of server components and client components (essentially what all current react components are), and only the JS for client components is actually sent to the browser and hydrated.

Re: Fresh – Next-gen web framework

#177

I don't fully understand the difference between this (and something like Remix, which seems similar) and other frameworks like Next.js (React) and Nuxt.js (Vue). Can someone explain a bit about the differences, and pros/cons to each?

The end result might be same but all of these frameworks/library/tools have some tricks up their sleeves that makes things easier for developers to implement certain functionality. The major difference with Fresh is that it runs everything just-in-time when it is needed, hence doesn't require building no shipping anything by default to the client(but you can still ship some JS for client side interactivity). The key…

> The key here is no building (packing, bundling, transpiling).

How is that possible? In the documentation (https://fresh.deno.dev/docs/getting-started/create-a-route) I see .tsx files... so I imagine that at least one needs to compile TS to JS and then JSX to JS. Perhaps I got that wrong, though and browsers nowadays support TSX out of the box.

Re: Fresh – Next-gen web framework

#179
post #168

> Island based client hydration Software development already has its own vocabulary, but I feel quite ignorant now.

Instead of sending a rendering routine which then fetches data and renders everything on an empty page, they prerender a part of a template (constant) and send it along with fetch-data routine which only fills in missing values later. That’s why you sometimes see a form but its values are shaded for a while. This makes them think that you’re less annoyed because at least something is visible quicker.

Island-based probably means that hydration is not whole-page but granular, making parts unshade at different times, to your enjoyment.

Post reply on HN