Live data from Hacker News

Fresh – Next-gen web framework

fresh.deno.dev

291–300 of 463 posts

Re: Fresh – Next-gen web framework

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

The incentives here seem strongly skewed towards having your name on a new framework for career purposes rather than improving the ecosystem at large

Re: Fresh – Next-gen web framework

#292

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 ?

Hydration only makes sense when you have a vdom that you have to "synchronize" with the initial state of the page (the html you got from the server). The act of performing this synchronization is what hydration is about (notice that this includes setting up event handlers too). What you do here is to reconcile the in-memory representation (vdom) with the actual contents of the page (the dom). In the jquery aprroach t…

So it's the same approach to generating html, except the part that belongs to client side (event/ui-state) is irrelevant to backend _anyway_. If you separate javascript code into 2 main parts, 1) what's only related to generating html 2) what's only related to DOM API, you get jQuery approach where on the back end javascript is just yet another backend language?

Re: Fresh – Next-gen web framework

#293

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…

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

This too, demonstrates the point I raised earlier.

Instead of using a mature, widely adopted and battle-tested system which allows you to efficiently share code across multiple languages without introducing runtime hits - you instead discard it as some "huge dependency" and insist on having JS everywhere, using the latest hype of the week, consequences be damned.

Why actually spend the time to solve a problem in a mature way, when I can just add this week's shiniest NPM package to imports.json?

Re: Fresh – Next-gen web framework

#294

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…

That first one was way quicker for me. Might also be because I'm in Firefox on a RPi 4.

Re: Fresh – Next-gen web framework

#295

Earlier quoted context omitted.

Have you seen Remix yet? It’s pretty compelling in terms of competition for Next.JS. It makes different trade offs and isn’t strictly better by every metric, but overall I’m very happy with it for the two use cases I’ve tried it with. It’s a very low overhead framework once the simple conventions click. I’d still like to check this out, then redwood and a couple others too. I’m not huge on these frameworks in general…

I've heard really good things about Remix, especially the nested routes. But I think Next is trying to copy that in Layouts? https://nextjs.org/blog/layouts-rfc I use Next not just for the routing and composition and hydration, but for all the other quality-of-life improvements (image resizing, buildchain configs, hot reload), especially when it's paired with Vercel (per-push sandbox builds, stale-while-revalidate, s…

That’s correct about Layouts, and I agree, if you want something with all the quality of life tooling ready to go, Next seems to be the way to go.

It isn’t too hard to get the same/similar tooling outside of the vercel ecosystem, but it does take know how and a bit of extra time. It isn’t obviously worth it unless vercel isn’t meeting your needs in my opinion/experience.

I mostly play around with other frameworks in order to learn, but for any client where a frontend framework made sense I’d almost certainly choose Next.

Edit: people also get bent out of shape about perfect hydration and shaving milliseconds here and there, but like you mention, Next offers such a comprehensive solution in a situation where routing and hydration are only a part of the big picture. Next gets you really far without any effort up front, which is crazy. I really like it!

Re: Fresh – Next-gen web framework

#296

Earlier quoted context omitted.

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

> and I'm from a time when peopling talking "frontend" meant HTML and CSS When that is the case, the stack you are describing is just perfect even nowadays. The problem is, in most cases that is just not the case anymore.

I guess that's it. It's the difference between the "application" and "document system" that some other commenter talked about. I guess the wisdom comes down to knowing which one to choose in what situation.

I myself am looking to find the edges of building a web application with the "document system". Clicks and requests for a full page load don't matter that much if you're able to keep your app simple. Which is also defined by context, not only by programming skills. Certain situations or applications are just not suited for the "document system".

Re: Fresh – Next-gen web framework

#297
post #260

Earlier quoted context omitted.

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

> 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. No, rendering partials is not a solution once you have a moderately complex app. Example: The user submits a form to change an entity, you need to send a partial back for the successfully submitted form, but you…

The solution to this completely hypothetical an unrealistic problem is to just not have too many partials to begin with. Which is the reality of 100% of the apps made with the libraries/frameworks I mentioned, WebForms, PJAX and Turbolinks.

Re: Fresh – Next-gen web framework

#298

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 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 conclusion so far is that most of the criticism towards JS based solutions is largely outdated if you pick your tools and libs well. The leverage of something like Nextjs and similar is pretty significant over traditional SSR, even for cases where the latter made more sense a while ago, increasingly so. I don't think PHP is going anywhere in the near future, but I see fewer and fewer reasons to use it at all.

1. When people talk about isomorphic code for frontend related stuff, they often pick form validation as the example. But this is just one of many things. It's also the tooling, testing, types and other integrations that you miss if your frontend logic is spread across language boundaries.

2. Unoptimized performance of a PHP vs Node/Next application is quite significant as PHP needs to recreate the whole application state with every request.

3. Frontend without or "minimal" JS is a pure luxury that you almost never get to have and if you do, it comes with its own complexities.

4. Websockets and other features are a pain to use (if you can use them at all) in PHP.

5. Development is faster and more responsive with a React/Nextjs/etc. based implementation. The feedback loops are faster, tooling and libraries are more integrated.

6. There are quite few good libraries popping up in recent years for JS that give you more leverage than what I'm used to from PHP.

7. Commoditized hosting PHP has been one of its strengths, but even that is being outcompeted slowly but steadily.

8. By default there are things you cannot do or only with additional (unnecessary) effort if you split your frontend logic into two places, rather than having a single, comprehensive codebase. Frameworks and libraries like Next, Remix, this one and others are leveraging that. Yes it gets more complex but you also get more optimizations

Please note that I don't particularly like either JS or PHP. I think both languages and ecosystems are quite terrible in their own ways and have to be tamed by pragmatic developers. So no emotional attachment there.

Re: Fresh – Next-gen web framework

#299

What is hydrating the client?

Hydration is a technique where the content is rendered server side then client side JS attaches the necessary event handlers to make the UI interactive https://en.wikipedia.org/wiki/Hydration_(web_development)

Thanks! makes sense.

Re: Fresh – Next-gen web framework

#300
post #96

Earlier quoted context omitted.

> Island based client hydration for maximum interactivity. This honestly reads like satire. It sounds like something on the sarcastic VanillaJS homepage. This gibberish being the second bullet point in a list of core features is a huge turn off. I know it’s tongue in cheek, but still

It’s actually not gibberish. * Island refers to this https://jasonformat.com/islands-architecture/ * Island based hydration is a form of partial hydration where the boundary is the component islands.

Makes sense. Thanks!
Post reply on HN