Live data from Hacker News

Substituting JavaScript with HTML

codementor.io

21–30 of 42 posts

Re: Substituting JavaScript with HTML

#21
post #19
post #14

Earlier quoted context omitted.

Form validation.

Form validation doesn't need to be done in Javascript. I'd argue that it shouldn't ever be done in Javascript, because that means implicitly trusting the client, which is always a bad idea. Since any sane application revalidates the response on the server anyway, client side validation is just a gimmick, it's not necessary.

It creates a better user experience.

We create a worse user experience by waiting until the form is submitted to inform the user of some silly error.

For some applications, the difference isn't that big, but for many it brings a significant improvement.

Is it possible to create crappy client side validation? E.g. not letting the user temporarily input invalid data while filling out the form, or displaying over-the-top red error indicators everywhere as soon as a single mistake is made, etc... Definitely. But let's not throw the baby out with the bathwater.

The backend should never trust the client, of course. That is a separate goal of the application, however.

Re: Substituting JavaScript with HTML

#22
post #19
post #14

Earlier quoted context omitted.

Form validation.

Form validation doesn't need to be done in Javascript. I'd argue that it shouldn't ever be done in Javascript, because that means implicitly trusting the client, which is always a bad idea. Since any sane application revalidates the response on the server anyway, client side validation is just a gimmick, it's not necessary.

> I'd argue that it shouldn't ever be done in Javascript, because that means implicitly trusting the client, which is always a bad idea.

It absolutely shouldn't be done in Javascript only.

Re: Substituting JavaScript with HTML

#23
post #19
post #14

Earlier quoted context omitted.

Form validation.

Form validation doesn't need to be done in Javascript. I'd argue that it shouldn't ever be done in Javascript, because that means implicitly trusting the client, which is always a bad idea. Since any sane application revalidates the response on the server anyway, client side validation is just a gimmick, it's not necessary.

> client side validation is just a gimmick

Server side validation requires a whole page round trip. The user will have to wait, lose their scroll position... you can't rely on client side validation only, but neither is it a gimmick.

Re: Substituting JavaScript with HTML

#24
What? This is terrible. This introduces an "API":

    
Which is handled by...Javascript! And now you have a nasty mini string language API, like Angular.

We have portable, functional components. It's called React. Embedding view logic in class names is the wrong way.

These home grown solutions are what we used to do as front end developers before React. Now we write portable component code.

Re: Substituting JavaScript with HTML

#25

Wait what.. ends with: "So now the JS library listens on the special classes and acts accordingly. This as opposed to what we had earlier is that now for N number of times we work with data from the backend the JS code responsible for it is the same. So for instance if you compare JQuery to Bootstrap. whereas you write some amount of JS to use J [cut-off]". Surely this is just re-factored JS then?!

Looks like a micro framework that changes the server resource that the form posts to based on css classes

Re: Substituting JavaScript with HTML

#28
post #12

Coolest thing is: You can do completely without JS: Browser handles sending, backend handles processing. Yes, blows my mind too..

I was thinking this too. Forms never _needed_ Javascript to post. It's always worked this way. Am I missing something?

If I were to guess, it's probably because you learned HTML before JS. Those who learned JS first, or were never exposed fully to HTML, are unlikely to see the simpler solution first, because they're tempted to use JS for everything. An excellent example of the "when all you have is a hammer, everything looks like a nail" principle.

Re: Substituting JavaScript with HTML

#29
I do have to say that it has been really annoying to watch my front end team miss deadlines to keep up with Angular versions. They also seem to introduce pretty basic bugs. What annoys me the most is there no reason for our product to have be a fancy SPA, it would be just as useful if it were a static site. The most complicated form element we have is a number input and a Stripe GUI. We also have a user facing cli tool that receives little UX love from them, because they don't understand how it works. Ironically, the cli generates about 2/3s of our users requests.

I realize that fancy JS applications need to exist in certain contexts. I just think the vast majority of SPAs out there are clumsy, unjustifiable monstrosities, because..."we have to have an awesome front end, right?"

I want to be clear that I'm talking about product front ends, not marketing sites or the like.

Re: Substituting JavaScript with HTML

#30
post #9

It's nice that forms work without JavaScript. Maybe we should make more stuff work without JavaScript too !? Maybe an option to bind HTML to program state, automatically updating the element's values when the state changes for example from a web socket message, or user click, but without the help from JavaScript.

Mind = blown! Wow! Just, wow!
Post reply on HN