Can You Afford It? Real-World Web Performance Budgets

Re:Can You Afford It? Real-World Web Performance Budgets by ehnto on Saturday October 28, 2017 @04:17AM (#15574422)

You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules. Where simple works, pick simple.

5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice.

While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by TeMPOraL on Saturday October 28, 2017 @07:18AM (#15574751)

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation?

Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by mrighele on Saturday October 28, 2017 @08:03AM (#15574865)

I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by nojvek on Saturday October 28, 2017 @01:06PM (#15575811)

This. Every major client lib out there uses some variant of vdom. If this dom diffing was natively supported, browser would request with current dom hash and server could efficiently reply with a diff that both server and client can compute to be the same new hash.

If it's forms. Client calls server with base hash + changes made by client and server replies with. Base hash + new diff to apply. The new diff includes validation changes.

It's trees and diffs all the way down.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by pcmaffey on Saturday October 28, 2017 @01:10PM (#15575827)

This is exactly what React's virtual DOM does. Maybe the future is making the virtual DOM native to the browser?

Bundle React with Chrome? Or how about a browser package manager that could cache and reuse all these common js libraries used on so many sites?

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by discreditable on Saturday October 28, 2017 @09:17PM (#15577567)

DecentralEyes does just that.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by grogs on Sunday October 29, 2017 @07:38PM (#15582192)

Sounds like PJAX.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by nawitus on Saturday October 28, 2017 @08:12AM (#15574889)

Page refresh takes a longer time than client-side validation.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by gjjrfcbugxbhf on Saturday October 28, 2017 @08:54AM (#15574994)

But you still need to do the server side valuation.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by Can_Not on Saturday October 28, 2017 @11:37AM (#15575458)

That doesn't detract from the value of client side validation, which is that it will be faster from the client's perspective and reduce server load.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by christophilus on Saturday October 28, 2017 @10:35AM (#15575258)

Yes, but from the end-user perspective, it's nice to not have to do a round-trip to find out that you entered something wrong.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by TeMPOraL on Sunday October 29, 2017 @07:03AM (#15578863)

Fair enough.

Still, validating a form client-side doesn't require a JavaScript framework; it would only require the server to send small snippets of JS for each field with the form.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by nawitus on Saturday October 28, 2017 @08:11AM (#15574888)

Needing a page refresh for input validation degrades experience.

"Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules."

Not necessarily. You can use the same exact code, in the same location written in the same language.

[ Parent | on HN ]

Re:Can You Afford It? Real-World Web Performance Budgets by ehnto on Saturday October 28, 2017 @08:26AM (#15574925)

But by how much and does it actually matter? It's also a pretty small example. The problem of complexity outstripping benefits only grows the more you inspect the frontend landscape.

My main point is just that the implication that JS is required otherwise the UX will be unbearable is false. It's also really easy to mess up the UX with JS and I see it constantly. I would take a fast form post over a cumbersome JS powered experience any day.

[ Parent | on HN ]