Why JavaScript is giving me depression… (Part 2)

Disclaimer: This is not a serious post. It’s intended to be a little tongue-in-cheek. Before you try and start a war in the comments section for either the “JS sucks” camp or the “JS is the second coming” camp, I won’t be approving any of those comments as THIS POST ISN’T SERIOUS and I’m not speaking for either side.

This post is an extension my previous rant about why I’ve come to really dislike JavaScript. I’m currently in the process of replacing a bunch of my Node.JS microservices for Oystr and reading my old Node.JS code is really painful. A lot of it is to do with the lack of typing but one other problem has become really apparent with JavaScript – promises are horrible to look at.

If you aren’t aware of promises, they were meant to be a pattern to deal with callbacks. Callbacks, as a pattern, are used extensively to deal with JavaScript’s single threaded model. The problem with callbacks is that you tend to end up with a lot of them heavily nested. Promises are a way to reduce the nesting of anonymous functions.

I’m currently working to replace my authentication and authorization microservices in Oystr. As a result, a single request from a browser requires multiple requests to the security database meaning there are a lot of callbacks. At the time I built it, I used promises as that was the thing to do. What has become apparent in my revisit is that promises make your code extremely difficult to follow. With callbacks, although you have deeply nested structures, your code was somewhat linear. With promises, your callback logic is “deferred” and as a result you find that the code just jumps everywhere.

Async/await should hopefully help resolve some of the problems with this but seeing Chrome only just started supporting it this month (December 2016), you’re probably going to continue to see the horror of promises for some time to come. Promises were meant to be a panacea for callbacks, but on reflection, they’re really just a “deference” of the problem to another part of your code-base.

Uncategorized

4 thoughts on “Why JavaScript is giving me depression… (Part 2)

  1. Hey Chris, I hope you don’t mind some serious discussion here 🙂

    Although I haven’t come across the promises problem you mention (yet) I have been struggling with Javascript as well (whilst learning on the go). So much so that I went looking specifically for alternatives (even more than I generally do).

    I was initially big on Typescript since it is typed and fully compatible with Javascript. However I read that it doesn’t have a goal of soundness, i.e. that all programs that compile will be correct. Still an option to consider.

    Next there is Elm, which you have no doubt heard about, being the inspiration for Flux and having many properties similar to React, all built into the language and framework. This seems great but also a bit like Eiffel vs C++ (if you remember the 90s 🙂

    In conclusion, at least for now, I have decided to stick with Javascript (as the language improves) and try to use Facebook’s Flow to add type checking to improve error catching at compile time. None of this helps with your Promises though.

    Happy New Year to you!

    • Hi Ashley,

      Thanks for the input.

      Just to make it clear, my growing dislike of JavaScript is in terms of it’s use as a server-side language on Node.JS platforms when there are other languages available. Unfortunately I’ve probably only alluded to that with my mentions of Node.JS rather than state it explicitly.

      I think libraries and frameworks like React/Redux, Angular, jQuery etc. do a lot to simplify client side development. After having used JavaScript almost daily for the last 10 years in commercial projects, my personal preference for client-side development is NOT to use transpilers. For teams I’ve led in the past, the deciding factor in choosing Typescript has been purely commercial. As most of my consulting work is in the enterprise space, my development resources are often from a C#/Java background and often they aren’t as comfortable with pure JavaScript.

      With that point made, my main argument in these posts is that given we have access to choose better languages like Java, C#, Go etc. for the server-side. By choosing to use Node.JS I feel that we unnecessarily inflict more damage on ourselves by trying to keep one common language across client and server. JavaScript itself, based upon my experience, doesn’t lend itself well to server-side development.

      When I first started building Oystr a year ago, I was definitely seduced by the idea of being able to share code between the client and server. The experience I’ve accumulated since that initial decision has led me to the current point of reflection where I think it was a completely horrible decision. What I’ve realised in all this is that the strengths JavaScript has as a client-side language don’t translate well to server-side development.

      In terms of your own circumstances, I totally agree with your decision to stick with pure JavaScript for the client-side. In fact I have no intention of moving Oystr to Angular 2.0 due to Angular 2.0’s recommended use of Typescript. If you’re working in a browser then you should be doing JavaScript IMHO. If you’re on a server though, I’d definitely recommend you to use something else.

      I hope that clears some misconceptions on where my rant is aimed at.

      Happy New year to you too! 🙂

  2. We are using Javascript / NodeJS on server-side as well but only for front-end. I believe if one wishes to do make an isomorphic/universal SPA client (with rendering on the server) then NodeJS is really the only way to go. Express will also be useful for generating the odd template-based page to go with the SPAs. From what I’ve seen, Javascript was a horror in the past but getting better with ES6 and ES7. I wish we had started with Typescript, and may migrate new work there, but for now Javascript/Babel and Flow will need to do on client and front-end server.

    Yes, I agree for Enterprise apps it’s better to have something more … enterprise class … on the server. I wouldn’t use Node.JS for back-end server application, I don’t think the ecosystem is mature or capable enough. As you probably know, we are using Scala / Akka / CQRS on the server. I feel liberated in a way because once one has SPAs and uses HTTP/REST to communicate between front-end apps (either client or front-end server) one is free to mix and match technologies and even replace them as needed. There are extra interfaces to manage though.

    With regards to single language and code sharing, interestingly there is Scala.JS for the client and front-end server that transpiles into Javascript. I believe it has most of the features of Scala and code can be reused, though I am not sure what code we would need to reuse given our front-end is pretty much purely for view. I’m not sure of your dislike of transpilers but did see a bit of their nastiness recently when I found an issue was caused by my lack of understanding of how Babel was rearranging the order of code. Why do you not prefer Typescript (if I understood correctly)?

    Good to chat, cheers Ashley.

    • My problem with transpilers is more to do with the principles that typically led to their choosing rather than their usage. Maybe I’ve not been talking to the right people in the development community, but more often than not I’ve found the two main reasons why people choose transpilers is –

      1. Unfamiliar with JavaScript
      2. Uncomfortable with JavaScript as a language and “wished” it were something closer to C#, Java, Clojure etc.

      My opinion is that to be really effective with a transpiler you need to understand what kind of JavaScript it’s likely to compile to. IMHO if you understand JavaScript that deeply, I question whether the 2 reasons above would still exist.

      Of course all this discussion may be moot over the coming years if web assembly begins to gain traction. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s