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

181–190 of 463 posts

Re: Fresh – Next-gen web framework

#181

Post by askonomm »

sdevonoes wrote: post #177
damowangcy wrote: post #41

Earlier quoted context omitted.

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.

It's using the Deno runtime, not Node. Deno has a TS compiler built-in, thus not requiring you to set anything up in that regard.

Re: Fresh – Next-gen web framework

#182

Post by 5e92cb50239222b »

sdevonoes wrote: post #173
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…

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

We've been able to replace a couple of client applications that previously used WPF with a React frontend (and a small native application that uses WebSockets to create a bridge between the browser and a particular piece of local hardware).

Updates are now easy-breezy (update the server and you don't have to touch clients at all).

There is a place for SPAs. I just don't think your typical grocery store website should use something like that.

Re: Fresh – Next-gen web framework

#183

Post by vosper »

chrischen wrote: post #175
jokoon wrote: 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 t…

> 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.

Isn’t the difference here that with React Server Components you’re still fully rendering client-side, but you can ship the data alongside the JS? Whereas with Astro / islands of inactivity / partial hydration you ship actual HTML and then after it renders you make interactive (hydrate) only the relevant parts?

Re: Fresh – Next-gen web framework

#184

Post by BurningPenguin »

chrischen wrote: post #175
jokoon wrote: 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 t…

Reading about SSR feels like we went full circle.

Re: Fresh – Next-gen web framework

#185

Post by madeofpalk »

sdevonoes wrote: post #173
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…

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

If you think it's bad then why do you use it? Browsers still support just HTML. You can shove a just a script tag down in the page.

Eventually, you'll have enough devs working on this you'll start to run into issues with how you coordinate your work. Your site becomes large enough the code gets more complicated and needs organising to work on it without slowing you down. You'll start to reinvent the above tools to solve these problems.

Frontend/JS tooling isn't perfect, but don't pretend like other languages/systems (can) have a complex pipeline of build tooling.

Re: Fresh – Next-gen web framework

#187

Post by christophilus »

seydor wrote: post #126

A JS framework, not a web framework

It’s a JS web framework. It does pretty much what your average web framework does, except adds in first class interactivity, and drops an opinionated ORM layer. I personally really like this balance, and will kick the tires when it’s not experimental.

Re: Fresh – Next-gen web framework

#188

Post by madeofpalk »

sriku wrote: post #153

Slowly getting somewhat cynical. This is the only space where both "prebuilds everything and therefore saves rendering time and improves caching" and "no build step and so speeds up deployment" are both considered valid feature pitches.

Why does that make you cynical?

They're two different spins on how to render content. They both have pros and cons. It's good to know this and make an informed decision about which strategy you take.

Re: Fresh – Next-gen web framework

#189

Post by quickthrower2 »

wruza wrote: post #179
jokoon wrote: 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 pro…

> This makes them think that you’re less annoyed because at least something is visible quicker.

Cynicism detected!

Post reply on HN