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.
Fresh – Next-gen web framework
281–290 of 463 posts
Re: Fresh – Next-gen web framework
#282Earlier 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…
> 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.
Re: Fresh – Next-gen web framework
#283If you need something a bit less esoteric and want a traditional, straightforward approach to building web apps with JavaScript: https://github.com/cheatcode/joystick.
Add an Express route -> tell it to render a component/HTML via a res.render() function -> it auto-hydrates everything on the client for you. Components are written in plain HTML, CSS, and JavaScript (no JSX or other funky syntax) with a quick-to-grok API.
No new concepts to learn and keeps you as close to the core technology (HTML, CSS, and JavaScript) as possible.
Re: Fresh – Next-gen web framework
#284This 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.
Re: Fresh – Next-gen web framework
#285Earlier 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…
Others have responded to the technical deficiencies in your comment.
I’ll just say it’s a bit rich to be telling the developers of React - “all this can be done with a server side rendered PHP”. The developers of React are well aware of what PHP can do, because they work at a company with one of the largest PHP (-ish) codebases in the world. Almost all pages on Facebook were completely server rendered, but they’re gradually moving towards React based web pages.
Please consider that the people making technical decisions might know what they’re doing. Please don’t condescend.
Re: Fresh – Next-gen web framework
#286Earlier 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. 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…
> 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 also need to send partials back for potential 2-3 other places that the entity is displayed on the page, even if they are not displayed on certain pages.
Just tracking and updating them whenever they change is a pain in the ass, not to mention the increased processing/bandwidth for no reason.
Re: Fresh – Next-gen web framework
#287I 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 ?
With jQuery, your rendering is 100% dynamic, meaning, you load your JS on the client/browser and when that code executes, it fetches some data and "injects" it into the DOM (technically a form of hydration). Hydration in context here means taking some HTML that was server-side rendered with JavaScript and then, in the browser, handing off subsequent rendering (in response to user interaction) to JavaScript running on…
If you `s/Hydration/jQuery/` on your hydration description, I find it's still true.
Re: Fresh – Next-gen web framework
#288Earlier 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. 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.
Re: Fresh – Next-gen web framework
#289Is it official deno project? The github repo isn't on deno's organisation.
or is it like anyone can host anything on deno.dev, similar to js.org?
Re: Fresh – Next-gen web framework
#290Earlier 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. 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…
> 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.
Of course you shouldn't use a full-js stack if your team of developers doesn't know JS, no one is arguing that because it doesn't make sense.