[GoodbyeEarl]

I'd really like to know how to deal with users input, forms and other stuff without JS. Every tutorial we see today is like "throw tons of JS to this problem and it shall work".

[tsm]

Vanilla forms just GET or POST to some server endpoint with all of the <input>s passed in as query parameters. Frameworks (e.g., Rails) put some syntactic sugar on it, but that's really all that's happening. If the form submission contains invalid input, it's customary to return to the form page (with all the values already filled out) and show a server-generated message about what went wrong.

JS is absolutely not required for any of it.

[GoodbyeEarl]

Thank you! it is actually enlightening :)

I think it's a little bit awkward to not use put, patch, delete... I wonder however if my server must follow the same technique, if not how to wire a delete endpoint to handle a form post and so on. I'll try to handle a form using only get and post sometime just to see how it works. Thank you!

[flukus]

Well you just made me feel old. For put/patch/delete you can just as easily wire different options to different URL's. We had URL's like /Foo/Delete?43. It may be awkward in a particular framework but it's about as simple as things get.

I've always hated put/patch/delete because it tends to result in data centric UI's instead of workflow centric ones.

[GoodbyeEarl]

Here it is https://github.com/viniciusCamargo/express-crud-barebone here is my try on this approach to server requests. Any suggestion would be welcome! :)

[GoodbyeEarl]

Hmm now that you mentioned I realized I've seen this pattern before but I've never given it a thought. I'll definitely try it sometime, it seems to work pretty well. BTW sorry for make you feel old, it was not my intention haha

[dzonga]

I would really want to know more about this too, built a simple site without all that JS bloat

[GoodbyeEarl]

I'm thinking about push some code to github this afternoon using these techniques with nodejs, if you want to I can send you a link to the repo ;)

[GoodbyeEarl]

I'm glad for not being alone here :) I wish things were simpler...

[quasse]

Where is your user input going in the end? If it's going to a server, I sure hope you're validating it there.

Anything you do on the client side via JavaScript can be bypassed by the end user and provides no guarantees about the input you receive.

[appleiigs]

Same with HTML. Need validation server side no matter what.

[fl0wenol]

Are you being facetious? Otherwise I feel old.

When I learned HTML4 forms and CGI, javascript was solely the domain of input validation if it was available.

Okay I definitely feel old.

[GoodbyeEarl]

lol sorry, but I was serious :P

[CaptSpify]

Is this what you mean: https://www.w3schools.com/html/html_forms.asp ?

[teddyh]

Please don’t ever link to w3schools.

https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms

https://www.w3.org/TR/html51/sec-forms.html#sec-forms

http://caniuse.com/#feat=forms

[GoodbyeEarl]

Hmm I've been using w3schools for quite some time now but I ALWAYS double check it with a third source, often MDN. I really like their straight to the point approach and I think they've been fixing some of the odd stuff lately. I don't really think it's really that bad if you already have some previous experience, it can work OK as a quick reference.

[CaptSpify]

Sorry, but why not?

[gspetr]

http://www.w3fools.com/

[digler999]

all that link says is that w3c is "not reputable". no evidence. For learning the basics in webdev (coming from C/C++) I've never had a problem with w3c.

[teddyh]

It used to have more detail:

https://web.archive.org/web/20110117085131/http://w3fools.co...

Even if they have fixed all these instances since then, that all those errors were ever produced is a bad sign, especially when there were better alternatives even then.

[GoodbyeEarl]

thanks mate!