Substituting JavaScript with HTML | Hacker News Reader

Substituting JavaScript with HTML

codementor.io

50 pointsnartin39 comments

Coolest thing is: You can do completely without JS:

    <form action="https://example.com/submit_foo" method="POST">
        <input type="text" name="bar">
        <input type="submit" value="Submit">
    </form>

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?

Form validation.

Plus dynamic fields, options

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.

Validation on the client is to catch user mistakes, validation on the server is to catch malicious actors.

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.

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

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

What is ajax

> What is ajax

Server-side validation relying on JavaScript. You still have to wait for the server to respond, and now you need to implement UI to tell the user something is happening in the background. But at least you can start proactively validating before the user actually submits the form, so there's that.

In special cases, maybe. Basic validation (Email looks like email, number contains no text...) is done by the browser automatically if you use semantically correct <input> types: http://diveintohtml5.info/forms.html#validation

Alternative HTTP methods (only GET and POST are supported in HTML forms).

Also, there is the setting of HTTP headers which requires JavaScript.

I just use a hidden field to handle that.

  <input type="hidden" name="_method" value="PATCH">

That doesn’t actually handle that however (you’re just telling a server that your get/post intends something else).

The server has to support it.

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.

Explains node.js to some degree too. Very glad I didn't enter the scene now with what I see in JS development.

The simpler solution, being that it is what it is, can't do everything that the advanced solution can do. So it's another misuse of the hammer and nail quote. This is a good example of 2 hammers that are optimized for 2 different use cases.

CSRF protection, double submits, etc etc etc etc

I always wish I could ship something like that, and it does sometimes start out that way. But it never lasts, not anywhere that cares more about UX than they care about HTML purism.

It seems as if the author is on the way to rediscovering the idea of Unobtrusive JavaScript, aka the RSJS pattern (Reasonable System for JavaScript):

http://ricostacruz.com/rsjs/

The main difference is that Unobtrusive JavaScript relies on HTML5 data attributes rather than misusing CSS classes.

Perhaps the most well-known example of the Unobtrusive JavaScript approach are the AJAX helpers of Rails:

http://guides.rubyonrails.org/working_with_javascript_in_rai...

The article mentions Unobtrusive JavaScript toward the end:

"With the addition of classes I can enjoy all the custom CSS Bootstrap provides for the most part of what we need as far as styling goes . Why can’t we have same for JS ? It turns out we actually do and such libraries are known as UnObstrusive JS libs."

HTML valid and semantic markup:

  <form action="https://formspree.io/your@email.com"
        method="POST">
     <input type="text" name="name">
     <input type="email" name="_replyto">
     <input type="submit" value="Send">
  </form>

Indirect FormData manipulation, misuse of `class`, ignorance of dataset:

  <form class="dv-add-oneto:profiles:details"> <input type="text" name="firstname" placeholder="Please enter your first name"><br> <input type="text" name="lastname" placeholder="Please enter your last name"><br> <input type="number" name="age" placeholder="Please enter your age"><br> <button type="submit">Submit</button></form>

Yep! Sounds good to me!

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.

> there no reason for our product to have be a fancy SPA, it would be just as useful if it were a static site.

So common, so true, but certainly an argument you'll never win.

> the cli generates about 2/3s of our users requests

This is more interesting, I think -- is that widely known internally? Is that number growing or shrinking? Do users start on the web interface and migrate to the CLI, or do they pick one and stick with it? Do they use the CLI by hand, or do they have scripts to make the interface better?

The whiz-bang web interface may drive sales better, but improving the way the product is used will drive retention. Try to stay positive about it, and keep a wide perspective, but do make sure that what you know and what you think are known "up the chain."

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

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

    <form class="dv-add-oneto:profiles:details">

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.

Interesting that the images on that website don't load without Javascript. If only there was a way to show images with HTML instead of Javascript.

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!

Why not use data attributes instead of classes? This is one of their intended use cases.

Data attributes seem like the right way to me.

Minimum viable JavaScript SPA:

http://intercoolerjs.org/

Clickbaity title due to not making clear that it is purely about the interface to the library.

Lea Verou called an interface like this "HTML API", which standing alone also is missing the script context but is at least clear in that it is about the API, not the entire code: https://www.smashingmagazine.com/2017/02/designing-html-apis...

List of examples http://markapp.io/

This is 'interesting', but I don't see it as useful at all. And it's not a substitution of JS, but rather of how you interface with it.

Hm, this sounds suspiciously what AngularJS (and I assume other projects too) did as early as 2011 - apply the Javascript logic via template / attributes instead of fetching elements via Javascript and applying logic.

I've mentioned it before but I had a "aha" moment when I found intercooler js, it would be awesome to have 3-5 JavaScript functions instead of always rewriting and building Ajax request. Only problem with intercooler is it expects HTML in return instead of json.

Many web applications are data-entry centric so yes use more HTML and use less JavaScript because forms are builtin. However, for anything that goes beyond this, JavaScript is not just an option - it is a must. You can avoid it but you will also not going to create anything interesting.

I can no longer tell if the cool kids are joking or not.

Reply on news.ycombinator.com