- 6 minutes read

Recently, I've grown increasingly uneasy about the current state of JavaScript development. I'm a full-time Java developer who tries to get familiar with JavaScript. Over the years, JavaScript has become a really nifty programming language. There's hardly anything you can't do with JavaScript. It's one of the most exciting areas of development in 2016.

Only... each time I start to read a tutorial about JavaScript, I feel stupid. I know I'm not stupid - at least if it comes to programming - so the explanation must be something different. I freely admit I'm lazy. That's a valid explanation why I don't cope with most tutorials.

Mind you, all you have to do is to use require.js. But that's something you have to do anyways, so what's the trouble? Don't be so lazy! Oh, you don't use require.js? Where have you been living in the last couple of years?

Sure, you can't do without node.js. It's not that difficult, just install it, so what's the trouble?

Yeah, right, this module requires Python. So what? Oh, you're a Windows user? Well, that's your own choice. Use Linux. It's free, and everything works like a charm.

But if you really insist on using Windows - well, we've warned you. But Google is your friend. All you have to do is to install the community edition of Visual Studio 2015. After that, you can install plugins to the Atom editor.

Talking of which - yeah, sure, the JavaScript community has their own toolchain. You've never heard of Atom or Sublime? Where did you spend the last couple of years? In a silo?

And why do you object using Grunt and Bower? These are essential tools every JavaScript developer needs!

Why does it have to be so complicated?

By now, you should have got the idea. JavaScript development isn't difficult per se. It's not even difficult to adopt the entire toolchains that are popular today. The toolchain is a bit volatile, but that's not too much of a problem if you're able to dedicate your entire working day on JavaScript.

But if you've got only one or two hours per day, you're doomed. Even such as nice and simple library as Formvalidation.io becomes a challenge.

My perception is that current JavaScript ecosystems are way too complex. I, for one, often can't wrap my head around them. Each step is simple, but there are so many steps to go that it turn out to be a Marathon run. That's only 67.000 simple steps, depending on your size. But there's hardly anybody who calls a Marathon "simple" or "easy", even if it consists of simple steps.

Cutting a long story short, I believe that the JavaScript community currently favors an intimidatingly complex toolchain. What I loved about JavaScript was its simplicity. But in 2016, hardly anything a JavaScript developer does can be called "simple".

Comparing JavaScript development to Java Enterprise development

In part, that's because the big enterprises influence the world of JavaScript programming. But the average JavaScript program consists of merely 5.000 lines if I'm to believe the article that inspired me to write this post. This, in turn, explains why so many Java developers are attracted by AngularJS. Java programmers are used to dealing with programs consisting of hundreds of thousands of lines. So they need powerful tools just to manage with the complexity. They aren't bothered by the drawbacks of these tools. That's because you simply can't cope with a million lines of code without tool support.

However, if it's true that the average size of a JavaScript program is only 5.000 line, we should really ask ourselves how to keep things simple. From this point of view, the Angular2 seed points into the wrong direction. Don't get me wrong: it's a great tool. But there's no point in using such a sophisticated tool for tiny Angular2 programs. As things go, all my Angular2 programs I've written so far are small. My biggest Angular2 program is a chess game. It consists of roughly 1.000 lines, give or take a few. Using Angular2 was fun, but I doubt it was the most cost-effective approach to writing a chess program. Luckily, I wrote it in my spare time, so nobody cared.

Foreign feathers

As it seems, I'm not the only one to feel like this. Read the fully story at Sean Fioritto's blog.

Here's another interesting read: You (probably) don't need a JavaScript framework. The author, Shaun Dunne, adds another interesting thought: When was the last time you had a look at the browser's API? Both JavaScript and the native browser API have evolved a lot over time. When I started to investigate JavaScript, our programs consisted mostly of browser switches. When jQuery appeared, it was a great relieve to JavaScript programmers. jQuery made JavaScript programmers familiar with the idea of using frameworks, and after a while, they stopped thinking about it. They use their pet framework for everything. Even for small programs that don't need such a powerful tool. If you've got a hammer, everything starts to look like a nail.

Wrapping it up

Developers love complexity. It lies in the nature of their job. Hunting down a bug is like solving a crossword puzzle, only more exciting. More often than not, this leads to sophisticated programming environments. The average project uses one or two dozens of third-party frameworks.

Sometimes developers use a particular framework proudly because mastering it shows they are part of an elite. I suspect that's the reason why the old, XML-heavy style of programming Spring become so popular. I never got it. All I saw was an XML hell that made debugging impossible. But I met many clever developers who were very loyal and very enthusiastic about Spring.

(Before you ask: yes, I do know that Spring has evolved, too. I'm not talking about modern Spring).

Usually, that's not too much of a problem, because that's the amount of complexity most developers accept and prefer. Be honest: you don't want it more simple, do you?

However, in the case of JavaScript, it is a problem. Many JavaScript programmers are only part-time JavaScript programmers. They already have their complex toolchain. Having to learn a second complex toolchain is pushing the envelope too far. That's why I've started to preach to make JavaScript simple again.

Of course, this raises the question if we could simplify all of our programming ecosystems. Maybe I should change the title of this blog to "Let's make programming simple again".


Comments