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.
Fresh – Next-gen web framework
291–300 of 463 posts
Re: Fresh – Next-gen web framework
#292I 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…
Re: Fresh – Next-gen web framework
#293Earlier 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…
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
#294Earlier 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…
Re: Fresh – Next-gen web framework
#295Earlier 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…
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
#296Earlier 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 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
#297Earlier 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…
Re: Fresh – Next-gen web framework
#298Earlier 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…
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
#299Re: Fresh – Next-gen web framework
#300Earlier 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.