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

271–280 of 463 posts

Re: Fresh – Next-gen web framework

#271

Post by AtNightWeCode »

solardev wrote: post #59
lmiller1990 wrote: post #9

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…

Heads up on doing ad-hoc/jit-rendering in CF workers though. They bypass the cache.

Re: Fresh – Next-gen web framework

#272

Post by WuxiFingerHold »

totallymike wrote: post #269
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…

This feels like a strange argument to make when server-rendered HTML has been the norm for decades, and it's only been recently that SPAs have become popular.

It may feel strange, but as Javascript has become very, very fast in the last decade and the new SPA frameworks are highly optimised, I'm not surprised by the performance of SolidJS. Obviously for dynamic content.

That's by the way the reason I was asking for benchmarks. The new kind of SSR frameworks are by the way much more complex than the older template based server-rendered HTML.

Re: Fresh – Next-gen web framework

#273

Post by WuxiFingerHold »

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.

Re: Fresh – Next-gen web framework

#274

Post by indymike »

csmpltn wrote: post #220
zepolen wrote: post #208

Earlier quoted context omitted.

You can't compare JS SSR with PHP, SSR implies there is CSR which is not the case with PHP. Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward. And I say this as someone who was developing CGI scripts before PHP came along.

> "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward." This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. 1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversati…

> This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about.

I spent four years working on a Meteor.js app. Meteor's main appeal is isomorphic code and a high degree of reactivity. As the app evolved we replaced the in-built MongoDB with GraphQL. It was nice to have one language and GraphQL was very useful. Eventually this kind of model may be the future, but the next project I did, instead of Meteor, I went with a more conventional Vue front end with REST & websocket api for the backend. The reason for the change is that while Node is really nice, Django and Go get predictable outcomes with less time spend on tooling, patching and updates. With a small team, losing lots of hours to "our build broke because an upstream dependency changed a function signature" is not a good thing.

Re: Fresh – Next-gen web framework

#275

Post by ratww »

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…

> "Modern" frontend code requires:

Not necessarily, at least in the case of React and Vue.

Rather than using NPM, you can self-host react/vue (or preact if you need something even smaller), or serve it from Unpkg.

You don't need node/transpiler/bundlers if you're only targeting modern browsers. You can use modern syntax, async/await, ES6 import and a bunch of other features with static .js files.

JSX is a tough one, but there are solutions to that, packages domz and HTM are made to allow using React/Preact without NPM/transpilers.

Typescript is also a tough one. But it's also optional, although a good idea to have. I hope optional type annotations land in ES6 soon so typechecking can happen without anything resembling compiler phase.

-

> To being able to "hydrate" some server-side rendered template? Not good enough reason.

The "hydrating" parts is entirely optional in "modern frontend". It also needs some stuff on the server that is IMO significantly more complex than what I described above. But apart from some very specific cases, one don't necessarily need it.

Re: Fresh – Next-gen web framework

#276

Post by rambambram »

csmpltn wrote: post #229
gbalduzzi wrote: post #224

Earlier quoted context omitted.

> 1. Why should having the client and server share the same codebase even be a goal in the first place? Because, in building complex and dynamic web apps, the alternative is to repeat a lot of the same logic in both frontend and backend. Of course if you are building a blog or a simple static page this is not useful, most of the new techniques are a response to more advanced requirements. For instance, right now I'm…

> "Most of the logic inside the form has to be written two times: in PHP and in vue" Why? That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server. > "Most enum types are repeated" Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apac…

> That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server.

Exactly. This way of working is such a breeze. PHP does the logic, the state is firmly in the database, and I'm from a time when peopling talking "frontend" meant HTML and CSS. Occasionally some plain JS, and I'm good.

Years ago I was out of the webdev field for some time, and I must admit that HTML and CSS alone have made big strides.

Re: Fresh – Next-gen web framework

#277

Post by jjdeveloper »

chrisweekly wrote: post #218
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…

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.

Re: Fresh – Next-gen web framework

#278

Post by stoicjumbotron »

inglor wrote: post #142
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…

check out Qwik (by Misko Hevery the author of Angular) which does (much) smarter hydration than Next (or this Fresh thing)

Yeah, I too have been meaning to try it out. I guess the "barrier" for me is the ecosystem surrounding it.

Re: Fresh – Next-gen web framework

#279

Post by rglover »

Existenceblinks wrote: post #135

I heard the word "hydration" so many times, I sort of get it, but always have question mark in mind that what's different between hydration and jquery approach ?

With jQuery, your rendering is 100% dynamic, meaning, you load your JS on the client/browser and when that code executes, it fetches some data and "injects" it into the DOM (technically a form of hydration).

Hydration in context here means taking some HTML that was server-side rendered with JavaScript and then, in the browser, handing off subsequent rendering (in response to user interaction) to JavaScript running on the client.

Think of it like those little dinosaur sponge toys that would inflate when you poured water on them. The dry sponge is your server-side rendered HTML and the interactive JavaScript is the water being poured on it.

Re: Fresh – Next-gen web framework

#280

Post by rambambram »

jasode wrote: post #244
bsaul wrote: post #204

Earlier quoted context omitted.

it would be interesting to understand what is different now. Because IMHO it's never 100% full circle. It looks like we're back at the same point, but there are usually crucial differences in the implementation details that makes it quite different.

>Because IMHO it's never 100% full circle. It looks like we're back at the same point, but there are usually crucial differences in the implementation details that makes it quite different. Your intuition is correct. The "SSR" looks confusing because people are using that in 2 different ways: (1) Server-Side-Rendering means using Client-Side frameworks like React on the server : https://en.wikipedia.org/wiki/Server-s…

> The 2 groups are talking past each other. For people using "SSR" definition (1), it's doesn't look "full circle" because a language like PHP was never in a runtime in browsers so there was never a client-side-to-server-side re-use of the rendering code.

Exactly. As a PHP guy I'm not thinking in terms of SSR or CSR, but backend and frontend. PHP never had to do things on the client side, that is what HTML and CSS are for (and some JS). JS apparently has to go from client side to now also server side.

I don't think it's necessary an advantage to have one and the same language doing both the backend and frontend. I also don't know of any disadvantages, I have no experience with JS frameworks.

But everybody is hitting some very interesting points in this whole comment thread. You have some smart remarks about talking past each other. And I also think your observation of PHP never having to run in the browser is a sharp observation. Thx.

Post reply on HN