Making a newsletter backend (axleos.com)

This makes me sad. The browser has perfectly good form submission stuff that doesn’t need JavaScript, and there’s seldom any actual reason to require JavaScript. Yet I find it increasingly common that web developers, despite perhaps (hopefully!) still using <form> and <input type=submit>, are somehow unaware of this and assume JavaScript must be used, and use JSON encoding, and trip up over CORs, and… and… Whereas in fact, you only need JavaScript to support seamless content changes based on the form submission (providing feedback or whatever without loading a new version of the page with just that alteration), and it’s normally perfectly reasonable to support normal form submission with just a slight enhancement if JavaScript runs.

Here’s an alteration of the newsletter form, which assumes that /subscribe is a regular HTTP form submission endpoint, accepting application/x-www-form-urlencoded form data and returning a basic message as an HTML fragment (or even plain text):

  <div class="hover-div blog-post-container pastel-depth-4 lift-on-hover" id="newsletter_signup" style="border-radius: 14px;">
  <h3 style="margin-top: 6px">Newsletter</h3>
  <form id="sign_up_for_newsletter_form" method="post" action="https://axleos-blog-newsletter.ew.r.appspot.com/subscribe" target="_blank">
  [… seven unchanged lines omitted for brevity …]
  </form>
  <script>
      sign_up_for_newsletter_form.addEventListener("submit", async function(event) {
          event.preventDefault();
          let response = await fetch(this.action, {
              method: "POST",
              body: new URLSearchParams(new FormData(this)),
          });
          newsletter_signup.innerHTML =
              response.ok
                  ? "<p>Signup successful!</p>"
                  : `<p>Signup failed: ${response.statusText} / ${await response.text()}<p>`;
      });
  </script>

• I’ve added the method, action and target attributes to the <form> element. The consequence of this is that regular form submission, if the JavaScript isn’t run for whatever reason, will submit the data to that URL in a new window, the idea being that the user just gets a new page containing “signup successful” and nothing else. (By contrast, on the current page, submitting the form will submit to the current URL with ?email=… added, appearing to the user as though the page has just reloaded, and it won’t be clear whether or not it worked.)

• I’ve shifted the <script> element from before the form to after it, so that the form exists when the script is run, so that it can do its thing immediately rather than being deferred until the page finishes loading by wrapping it in $(document).ready(function(){…}) (or addEventListener("DOMContentLoaded", function(){…}) would be non-jQuery equivalent, so long as it’s still an inline script). This is very desirable if the scripts are inline anyway, and quantities like this should basically always be inline for the best performance (seriously, inlining all your JS and CSS yields the best performance until surprisingly large sizes—far past 100 KB in practically all deployment and access scenarios, even with a warm cache). You only want ready dances if you’re deliberately loading the script asynchronously (which I will also defend as not unreasonable for something like this: the document is fully interactive without it, it can run later or even not at all and cause no problem).

• I’ve removed jQuery usage because it’s simply not necessary ($("#…") → document.getElementById("…"), .on() → .addEventListener(), $.ajax() → fetch()); all the native alternat...