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

221–230 of 463 posts

Re: Fresh – Next-gen web framework

#221

Post by BurningPenguin »

bsaul wrote: post #204
BurningPenguin wrote: post #184

Earlier quoted context omitted.

Reading about SSR feels like we went full circle.

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.

Yeah, i guess the tooling around it got way better. No need to download scripts from hundreds of websites. Just npm install and off you go.

I'm just not a huge fan of SPA in most cases. I had to commute a few years ago everyday and it was near impossible to read any news website, because their stupid React or Angular SPA toy just decided to stop loading. Mobile reception isn't that great in Germany, when you're sitting in a train. The weirdest thing was to watch the content load and then like 10 seconds later going blank, because the connection timed out.

Re: Fresh – Next-gen web framework

#222

Post by chrisweekly »

lmiller1990 wrote: post #62
tunesmith wrote: post #17

Earlier quoted context omitted.

Deno vs Node appears to be one of them.

Sure - this seems to be an implementation detail, though - eg, Remix and Next.js are both on Node.js but seem to have some difference that's not abstracted away, in terms of how you develop, how concerns are separated, etc.

Remix is not "on node", it can target other runtimes including Deno and Cloudflare Workers.

Re: Fresh – Next-gen web framework

#223

Post by Dracophoenix »

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…

> or whatever the .NET equivalent is

That would be Blazor for anyone interested in checking it out.

https://en.wikipedia.org/wiki/Blazor

Re: Fresh – Next-gen web framework

#224

Post by gbalduzzi »

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…

> 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 building a "buy form" for internal use (by employees only) in a shop. There is a ton of domain login used to select which field to display, what validation login to use, how to autocomplete some fields ecc ecc. The system is a PHP/Laravel server with SSR rendering and vue only used for some specific advanced components. Most of the logic inside the form has to be written two times: in PHP and in vue. Most enum types are repeated (and must be kept in sync). Having one shared codebase would simplify A LOT the development.

Re: Fresh – Next-gen web framework

#225

Post by mypalmike »

csmpltn wrote: post #200
chrischen wrote: post #175

Earlier quoted context omitted.

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…

I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much…

No post body was provided.

Re: Fresh – Next-gen web framework

#226

Post by PontifexMinimus »

3np wrote: post #81
davidjohnstone wrote: post #66

Earlier quoted context omitted.

You put square brackets around parameters. e.g., routes/greet/[name].tsx https://fresh.deno.dev/docs/getting-started/dynamic-routes

To add on this: Looks like you can do that for directories as well. Here's how it works: https://github.com/lucacasonato/fresh/blob/4bb07f4bcebfc2056... So the example above could be: user/[username]/page/[pagename].ts

Hmmm. I suspect there is some software out there that doesn't like directory names with square brackets in them.

Re: Fresh – Next-gen web framework

#227

Post by mypalmike »

noobermin wrote: post #191
wruza wrote: post #179

Earlier quoted context omitted.

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…

Isn't this how webpages used to work with jquery? Are you telling me everything just went full circle back?

In the same way that C was "full circle" from assembly because it had loops.

Re: Fresh – Next-gen web framework

#228

Post by Dracophoenix »

solardev wrote: post #90
lmiller1990 wrote: post #69

Earlier quoted context omitted.

I've actually worked with things like Create React App, Vue CLI etc a lot but never any of the "meta frameworks". Based on what you are saying, it seems like the main difference it where things are evaluated? So, if I do my filtering on the client (with React) I need to make a request, get all the data, filter, render. For something like Remix or Fresh, you can do it on the server first [0]. Either way, the user has…

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…

Given all the benefits you have listed, would the next big bottleneck to solve be the backend? I think it would be better to reduce/get rid of JS/Node and move on to server side Julia or C++.

Re: Fresh – Next-gen web framework

#229

Post by csmpltn »

gbalduzzi wrote: post #224
csmpltn wrote: post #220

Earlier quoted context omitted.

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

> 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/apache/thrift/

Re: Fresh – Next-gen web framework

#230

Post by resoluteteeth »

justshowpost wrote: post #197
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…

Nit-pick: It does have a build step to generate the manifest file, at least currently. This is needed because Deno Deploy still lacks dynamic imports. So, their claims of no build step are as of now still aspirational.

It sounds like it only needs to be regenerated when you add/remove components though, not when you simply edit them.
Post reply on HN