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

311–320 of 463 posts

Re: Fresh – Next-gen web framework

#311

Post by redbar0n »

nine_k wrote: post #282
redbar0n wrote: post #250

Earlier quoted context omitted.

> Hydration in the current sense is re-running most of what the server already did, to recreate the runtime state it already had. It’s interesting that the problems with hydration is in some sense caused by the insistence on one-way data binding (deriving the view from the state). I imagine that with two-way data binding then you’d just need to attach event handlers and then the state would be derived from the view o…

It's really easy to make the states diverge this way. That's why the one-way binding is popular. OTOH if there were a way to produce a two-way implementation from a one-way description, that could be great for performance. But this is already more CS than engineering.

How do the states diverge?

I think you can have a two-way binding with a controlled update procedure, akin to one-way data-binding. I’ve read some people claim to do it by producing a kind of one-way directionality under-the-hood (?) from two-way bindings. The goal being that views can update state (and other views).

I think it was here I read it:

«‘2-way’ shouldn't be a problem if a component reports user events (perhaps transformed/mapped) to the domain model without changing it's own core state (disregarding throttling etc.) and only changes its core state in response to events from the domain model.« — peerreynders @ https://dev.to/peerreynders/comment/1objn

Re: Fresh – Next-gen web framework

#312

Post by XCSme »

jstummbillig wrote: post #284
XCSme wrote: post #281

This looks good and has potential and all, but do we really need so many new web frameworks? Is all this effort spent on slightly improving the current tooling really worth? I think the web frameworks have had enough incremental changes, we should either stick to improving the current frameworks or creating ones that bring revolutionary, not incremental, changes.

Why not both? Certainly everyone who creates a (somewhat serious) web framework is at least aware that they could also participate in the development of an existing on. If they feel there is something to gain by going from scratch, why not? I don't think the popular existing frameworks exactly suffer from under-contribution.

> Why not both?

My point was that it's fine if someone starts working on a new framework, but personally I would rather have all that effort be used for developing services or tools that are actually needed and do bring value to the community.

EDIT: To make it more clear, the issue is when the creators of such frameworks do believe they are going to change the world by recreating in a slightly different way something that already exists. If they are doing this for fun or to get experience, it's all good, but very often those frameworks do seem to have the ambition of becoming the next big thing and revolutionizing the way people are developing web apps.

Re: Fresh – Next-gen web framework

#313

Post by eyelidlessness »

mayank wrote: post #155
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…

> The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client. I understand the spirit of your comment, but this was/is also true of Google Web Toolkit (GWT).

I’m going to have to take that on faith, their site doesn’t appear to ship the JS necessary to open the nav menu. But clicking through a few links confirmed what I recall: the major difference (apart from language) is the component/templating approach. Not that one is inherently better than the other (though I do personally prefer JSX), but bringing this concept to a dev environment which thus far mostly lacks it is a good thing for users. And with more flexibility in variety, there’s better odds users will get that experience.

Re: Fresh – Next-gen web framework

#315

Post by tomnipotent »

ratww wrote: post #263
zeroonetwothree wrote: post #259

Earlier quoted context omitted.

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…

While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered. This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP u…

> argument is that the techniques themselves were "forgotten" and are now being rediscovered

Which is a silly, lazy argument.

> by people claiming that the term "Server Side Rendering" can't be retroactively applied

Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR.

Re: Fresh – Next-gen web framework

#316

Post by dgb23 »

idkwhoiam wrote: post #309
dgb23 wrote: post #298

Earlier quoted context omitted.

I've been doing both, or rather different kinds of combinations from almost full PHP to PHP with jQuery/Backbone/Angular, and since a while React SPA to Node based including Nextjs. Also just using dependency less JS and htmx as well. All depending on the scope and requirements of the particular projects. For side projects I've built stuff with quite few other languages. This is for professional context. My conclusio…

Cost is a big reason in many countries. PHP is still the cheaper option for dynamic websites. Shared webhosting costs peanuts.

That's true but Nodejs hosting slowly puts out more and more competition that is even free or similarly cheap. This is still one area where PHP shines (indirectly). The other one is legacy/ecosystem. There are still quite a few hairy things implemented in PHP that the JS ecosystem misses and that you cannot possibly amortize in a single, typical web project.

Re: Fresh – Next-gen web framework

#317

Post by dgb23 »

techdragon wrote: post #205
noobermin wrote: post #191

Earlier quoted context omitted.

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

Yep, we’re reinventing all the classic server side templating tech, but with “front end frameworks”… which I suppose is actually making them “full stack frameworks” but that’s beside the point.

> which I suppose is actually making them “full stack frameworks” but that’s beside the point.

No that _is_ the point.

Re: Fresh – Next-gen web framework

#318

Post by eyelidlessness »

DylanSp wrote: post #243
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…

> A more granular approach—termed resumability by Qwik and as I understand it the forthcoming version of Marko—works by treating the server-generated HTML as the initial state. The code executed from there is much more isolated than a full component. Is that sort of what Phoenix LiveView does? Return a fully server-rendered page on initial load, then set up a "template" on the client side that can receive any values…

This sounds conceptually similar, albeit maybe more similar to React Server Components? I’m really not familiar enough with Phoenix to get that specific though. Even in the JS ecosystem there’s a lot of nuance between seemingly similar approaches (hence why even commonly referenced concepts like hydration can be confused for what they actually do).

Re: Fresh – Next-gen web framework

#319

Post by corrral »

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…

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

In practice, the whole page re-render-from-server is often much faster. Compare how long loading indicators last on full-fat GMail versus Basic HTML Gmail and its full-page reloads. Fastest "web app" I've seen in the past five years was pretty complex, and it re-rendered on every action, even menu navigation. The backend? PHP. I'm in the center of the US and it was served from somewhere in Asia (Singapore, IIRC?). Still the fastest thing I've seen in a long time.

I'm pretty sure the "it's for performance" argument has been dead since we (the industry) stopped sending XML and HTML snippets for direct injection, and started sending JSON and then doing a bunch of processing on it before finally generating some DOM nodes and rendering something. In the wild, what we're doing is killing performance, not aiding it. At least two of your points are simply wrong (c, d), another is highly debatable (a), leaving only one (b) and I'm not sure that's worth the performance cost, at least in many cases.

Re: Fresh – Next-gen web framework

#320

Post by iamsaitam »

okhobb wrote: post #71
PontifexMinimus wrote: post #57

From https://fresh.deno.dev/docs/getting-started/create-a-route : > Routes are defined as files in the routes directory. [...] If the file name is contact.js and is placed inside of the routes/about/ folder, the route will handle requests to /about/contact. I can't say I'm particularly keen on being told what directory to put files in, or or being told that I must only code exactly one endpoint in each file. Why aren…

This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?

What is a good argument against it? It makes understanding the layout of the website easily and saves you from having to come up with your own conventions around it.
Post reply on HN