Web News

Is JavaScript Really That Bad?

June 4, 2024
June 11, 2024
Episode Number:

JavaScript has seen its fair share of insults and critiques over the years, with some developers outright refusing to touch it and other skirting around the edges by relying heavily on the server-side of things (ie PHP). Love it or hate it, JavaScript is what the web runs on and it's been that way since 1995. Vanilla JavaScript runs in the client's browser, bringing interactivity to user interfaces, while keeping the server out of calculations and computations. With the introduction of Node.js, JavaScript escapes the client-side, and moves it's way into the backend scene. With such a versatile language, why does JavaScript get so much hate? Is JavaScript really that bad?


Also available on...
...and many more, check your podcast app!

Who’s in This Episode?

Show Notes

How to support the show


Prices subject to change and are listed in USD

  • Support the show from as little as ~$1/month
  • Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
  • Help support the HTML All The Things Podcast: Click Here

Learn with Scrimba

We receive a monetary kickback when you use our link

  • Learn to code using Scrimba with their interactive follow along code editor
  • Join their exclusive discord communities and network to find your first job!
  • Use our affiliate link to learn more
    • Just an affiliate link, no discount for now (as of June 10, 2024)

Show Notes


  • Creator Ruby on Rails hates JavaScript
  • SSR vs CSR
  • More and more people are talking about SSR using server languages and libraries like Ruby on Rails, Laravel, Go, Rust, HTMX, etc. 
  • Is this all because JavaScript sucks?

JavaScript On The Frontend

  • The web runs on JavaScript, whether we like it or not. It has since 1995
  • JavaScript is what your user client browser can run so when handling interactivity and data requests
  • That said, the NEED to use JavaScript is a contested point among the development community
  • For example, lets say you need to press a button on a page that will increment a counter and display that count somewhere
    • You can do this via JavaScript by implementing a variable (let count = 0) and then creating a function that will increment that count.
    • Then to display it you can create a HTML div element with a id of count-display and in JavaScript, you can update that element using a document.getElementById and a .innerHTML() to overwrite what was in between the div tags on each update in the increment function you created above. 
  • This all happens squarely in the person's browser and does not rely on any technology other than a HTML and maybe a JavaScript file (can technically be done in the script tag of HTML file)
  • This isn’t the only way to do this though, you can do this entire process on the server. Using any server language like PHP for example your increment button the page can send a request to a server which will accept a current count, increment that count and then respond back with the new count that you can then display on the frontend. 
  • The only thing the front-end JavaScript would be responsible for is sending and displaying the data from the server.
  • This can technically be further abstracted where the page itself gets refreshed with a brand new one with the updated data that the server itself formats and creates, leaving it where JavaScript would only be needed to initiate the call to the server with the button
  • This is all a long-winded way to say that you “can” technically do most everything that JavaScript can do on the server, but should you?

When JavaScript Makes Sense

  • When dealing with user interaction with the need to provide immediate and fast user experiences, JavaScript is pretty much mandatory
  • Relying only on the server can and will make for a poor user experience as any request and interaction will have to make a round trip before it can be rendered and displayed to the user
  • When an app relies on a lot of user interaction that is a good indicator that JavaScript will be needed
  • JavaScript enables you to create a ‘native’ like experience, and most web apps use it for that exact reason. Frameworks like React, Vue, Svelte make this easier to manage as well. 

When You Don’t Need JavaScript

  • When initial load matters 
  • SEO heavy websites
  • Intense background processing
  • When you can’t rely on a client device
  • Accessing secure data
  • Dealing with a user's files


  • Typically to make a good app you need a mix of both client and server and arguing that you only need one other the other is dumb
  • You can use JavaScript on both ends of the stack (client and server) but it isn’t required on the server and there is no need to push people that way if they’re already familiar with a good server-side language 
  • Tech like HTMX makes it a bit easier for a backend developer to not have to touch JavaScript but it is still running JavaScript under the hood, and also isn’t a silver bullet as it relies heavily on back-and-forth server calls.