JavaScript, amidst its funny quirks, is an interesting platform for functional programming. Especially given its highly mutable nature. Yes, you heard that right: a mutable functional programming language.

Let me head things off real fast. I’m not an expert on JavaScript. Not sure if I would qualify for senior status should I join a JavaScript-only team. Take my comments with a grain of salt. I just happen to express more interest in JavaScript than most of my surrounding teammates, and have learned a little more, so they tend to come to me with questions.

JavaScript is HEAVILY based on writing functions. You create them, you pass them around, you anonymously declare them, and you invoke one function while passing in two other anonymous functions. Functions within functions within functions. It is, as I like to say, Inception-esque.

But JavaScript is built on some of the craziest notions. Not a week goes by that someone doesn’t post a truth table of JavaScript comparison operations. It’s rules for converting and not converting between strings and other types is absurd. On a fundamental level, JavaScript is broken.

That last comment might ruffle a few feathers.

• “You talk about Java a lot. It can’t be as bad as Java!”
• “Python is crazy with its mandated whitespace formatting. Pu-lease!”
• “AbstractSingletonProxyFactoryBean. Need I say more?”

(Heh, that last one makes me laugh too. Yes, it’s a class from the Spring Framework, and when you say it, it illustrates either everything wrong with Java or with the Spring Framework.)

But JavaScript doesn’t have a standardized packaging system. With Java, you have JARs. Python has eggs. And Ruby has gems. To fill the gap, there have been several packaging systems (AMD, Webpack, Browserify, UMD, and requireJS come to mind).

JavaScript somehow has made it into every browser out there (arguably the only reason it has grown in stature), yet many people today are coding in the newest spec, ES6, which hasn’t been folded into browsers. So, we use Babel.js. It’s a little toolkit that transpiles ES6 code into ES5 (currently supported version). But to accommodate all the build systems i just mentioned, there a LOTS of recipes to hook it into your packaging system of choice.

JavaScript, something born in the web browser, has made its way server side. Java itself includes a JavaScript engine (Rhino, Nashorn). node.js emerged as a new way to build server + client apps purely in JavaScript.

The thing is, when you start talking JavaScript, code geek to code geek, you have to do a little content negotiation. Because you might speak native JavaScript when your buddy is heavily into jQuery. (Believe me, the apps look very different on that aspect alone). You might be using Webpack bundles while your buddy wants something simpler like requireJS. You might be coding ES6 while your buddy uses ES5. If you didn’t get it, ALL these are orthogonal choices. You can write jQuery + Webpack + ES6.

If you haven’t caught my drift, this is why I elected to yank most of the JavaScript code from Learning Spring Boot – 2nd Edition. I had plunked down quite a bit into the 1st edition, and too many people found it distracting. I’d be happy to yak about JavaScript at a conference, but most people aren’t interested in that.

At the end of the day, I find JavaScript cute and fun. I like building frontends using React.js. But if I had to make it my full time job, I’d probably go nuts. It’s that freaking crazy.

Happy coding!