Comment by ratww | Hacker News Reader

Comment by ratww | Hacker News Reader

Parent Full thread

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

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

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.

Ok then what benefit is there over a regular page load?

Faster response to user actions, smaller payload, not reloading the whole page, keeping scrolling position, keeping focus and keyboard cursor position when possible, allowing transitions and animations, no need to change browser history unless necessary, very minimal javascript necessary, allowing user to disable javascript in some cases.

Just because this is a counterexample to something that you deem good, it doesn't mean it has to be absolute shit. The world is not black and white. I would suggest at least doing some research about how things work before criticising them. They might surprise you.

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

I never claimed you argued for that. I'm simply stating the cost of each solution. Thrift is definitely much simpler in practice in all cases, except the case I mentioned as being an exception.

Reply on news.ycombinator.com