Hacker News Reader

Comment by the_gastropod | Hacker News Reader

> it's to give the user quick and actionable feedback.

Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web apps out there, I think this is a bad trade.

> React isn't helping you poll - it's helping you structure your application in a way that ensures all components receive the updated data

Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style.

View on HN

> Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc.

Is it worth spending more developer time (think $$) on optimizing things for imaginary savings on initial page load time?

> Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style.

How is that less complex than a client side application? You are essentially advocating for splitting the logic between server and client side. Of course that is possible and people do that all the time for various reasons. Does not mean that's the best way of doing things.

I think you are missing the elephant in the room. Emergence of the front end development frameworks like React was caused by ever increasing complexity of the front end applications. Which, in turn, is driven by customer demand. Customers pay for features, not for code quality, and churning out features is much easier and quicker using React vs. e.g. jQuery.

Lamenting front end application overhead is the same as lamenting using high level languages for back end services. Everybody knows that Real Programmers wrote Real Programs in assembler back in the olden days!

I'm with you on the fact that React is overused, but:

> in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework

The phenomenon of change blindness means a 100ms "blank screen" can be the difference between the user recognizing the fact that they've made an error and getting frustrated because they can't tell where the error is. The 100ms reload means if you don't want that to happen, you have to be much more careful about how you design your errors.

It's an easier design problem if the user sees the error appear immediately where their attention is already focused.

https://www.youtube.com/watch?v=bh_9XFzbWV8

I'd argue caring about this is more important for a smaller product where the marginal cost of a single user churning is (probably) much higher.

> Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not

Let's say the form has 5 fields, and I as the user make an error in the first field.

Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? That's not a difference of ~100ms, that's a difference of several seconds (or tens of seconds for a medium-complexity form).

>Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field?

Because more validation will usually happen on the server side anyway and finding out when you hit save creates less interruptions to your flow. There's no tabbing back to re-enter a field, there's no thinking it's fine only for the server side validation to reject it and there's no nagging when I skip a field to come back to it later, there's no UI jumping around when the error is shown. Client side validation takes a stateless form and interrupts me with it's stateful validation. At best it's an interruption, all too often there are silly things like not letting you tab to the next field or warning you that the second password you haven't yet entered doesn't match (and then later telling you about other problems when the backend does the validation).

Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work.

I don't think client side validation is necessarily bad, but most implementations get in my way more than the server side equivalent.

> all too often there are silly things like not letting you tab to the next field

Well, that's a criminal use of client-side validation, but it shouldn't condemn all client-side validation.

> Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work.

That's fair, but as others have noted if you're in a world where a polished user-experience really makes a difference or is a competitive advantage I'd argue that well executed client-side validation can get you to a UX-quality bar that no amount of server-side validation can reach (edit to add: server-side validation is still, of course, absolutely required).

Whether that's truly important for a given business or product can only be argued on a case-by-case basis. I think it's definitely a colorable argument that there's some overuse of client-side validation relative to product goals, but I think there are definitely places where client-side validation is hugely impactful.

Again, all of this assumes that the client-side validation is implemented at a high quality bar. Of course bad client-side validation is not useful.

There is definitely a happy middle ground. Feedback too soon can be jarring, but waiting till the end of a form can be very frustrating, especially if there are many fields and you have to reparse to find the error. I think you need both to have a good experience.

Oh, I agree.

I just think that, if you're aiming for the highest UX-bar, you're going to need client-side validation at some point. For any mildly complex form, server-side validation will usually be far past the sweet-spot you're referring to.

Now, as others have mentioned, it might be questionable whether every web-app and website should be targeting the highest UX-bar.

By the time the user presses the save button more than 100ms have passed and the user probably has filled in 10 other fields. You can avoid this frustration with a little bit of Javascript.

Reply on news.ycombinator.com