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

251–260 of 463 posts

Re: Fresh – Next-gen web framework

#251

Post by redbar0n »

LeanderK wrote: post #148
eyelidlessness wrote: post #128

Earlier quoted context omitted.

> 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 not the old days. Hydration is actually a compromise, and not a great one for UX. It’s in fact been said to be “pure overhead”, which I think is an overstatement but only slightly. What you’re describing in the abstra…

if the code is the same on the server, one could serialise the state and transfer it with the html, right?

that’s how it works, but you also need to attach event handlers and set up the state for the framework on the client-side (for subsequent interactions).

Re: Fresh – Next-gen web framework

#252

Post by dmix »

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.

That’s one of the best designed sales pitches I’ve seen for a web framework, you could use this approach to sell any idea.

Just scrolling list of small blocks of text with small/interactive screencasts/animations that communicate the idea via succinct bullet points.

Much more fluid than the usual approach of paragraphs or breaking the page up into large blocks/sections.

It’s closer to older HTML where you just have text and a scrollbar.

Re: Fresh – Next-gen web framework

#253

Post by kortex »

FpUser wrote: post #219
jokoon wrote: post #168

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

Some of the "modern" terminology in software development makes me want to puke. "Hydration" is one of those examples. And of course ingress / egress rate sounds way more important than read / write speed / rate.

Why? This is just what language does - it's like a constantly evolving entropy code. Jargon emerges to concisely describe unique concepts. Hydration is a great example: it's important in the process, so it gets talked about a lot, but it's distinct from rendering, so it gets its own term.

Likewise, ingress/egress is not quite the same as read/write. It gets its own terminology because it's distinct.

Re: Fresh – Next-gen web framework

#254

Post by ksec »

zepolen wrote: post #208
csmpltn wrote: post #200

Earlier quoted context omitted.

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…

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.

>SSR implies there is CSR which is not the case with PHP.

Wait a minutes, so now SSR is explicit to JS and with JS CSR?

Re: Fresh – Next-gen web framework

#255

Post by rictic »

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…

> Why?

To take just one of many examples, so that you can do the same validation client side and the server side. You have to do the validation on the server because the client can't be trusted, but if you only do it on the server you have to do a full page load to validate any of the inputs, give feedback, or vary the form fields displayed.

e.g. how many times have you filled out a long and complicated form, pressed submit, waited several seconds, and then get dropped back at the same form where you have to hunt for the error message, change the requested field and try again. And heaven help you if you got multiple fields wrong, where the data from one informs the validation of another. Client-side logic can make this process much lower friction.

Re: Fresh – Next-gen web framework

#256

Post by gbalduzzi »

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.

No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.

> Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/

Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea

Re: Fresh – Next-gen web framework

#257

Post by ratww »

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…

I mean, sure, there were "web pages being rendered on the server" back in the day.

But that was the rule, and there was no name for it. Wikipedia's SSR page used to be called "Server Side Scripting", which is kind of a misnomer, and is very generic. That would also include serving JSON from the backend... and "scripting" not only limited in scope but also non-ambiguous.

So, someone had to invent a term. The name "Server Side Rendering" is quite good actually, it describes what's actually happening rather than being some random buzzword.

(Of course, there will be people claiming "ackshually SSR is only when a Next.js-like-framework does it", but that was never agreed upon by the majority of devs)

Re: Fresh – Next-gen web framework

#258

Post by ratww »

ksec wrote: post #254
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.

>SSR implies there is CSR which is not the case with PHP. Wait a minutes, so now SSR is explicit to JS and with JS CSR?

That's definition is definitely not widely accepted, however some people seem to believe it is. So I guess it's open for debate.

Re: Fresh – Next-gen web framework

#259

Post by zeroonetwothree »

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…

I’ve been developing for the web since, well not quite 30 years ago (PHP isn’t even 30!), but let’s say 25 years ago. I’ve used so much different tech in those years that I have a pretty good sense of it, and I even contributed to the development of both PHP and React. And you are totally off base. Modern frameworks are far superior for building modern web apps than older serverside tech. Demands have changed and so we need new tools to address this.

Does this mean every single “new hotness” is truly a set change? No, of course not, a lot of things are just fads. Actually I would put SSR slightly in that camp, for while it’s certainly beneficial it’s not really a game changer. It’s just a modest performance optimisation (in some cases!).

Re: Fresh – Next-gen web framework

#260

Post by ratww »

gbalduzzi wrote: post #256
csmpltn wrote: post #229

Earlier quoted context omitted.

> "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. No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole…

> No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.

You can have the backend render partials and only send the affected part. This has been widely in use and battle-tested for about two decades in .NET WebForms, PJAX, Rails Turbolinks and other technologies.

Also, wether the app does this or that is completely orthogonal to how you build it. You don't need tho share code with the backend.

> Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea

Except for cases where the team doesn't know anything other than JS, using this is significantly simpler than forcing the whole backend to be in JS. Also, there are several other options.

Post reply on HN