TDD in JS world means Tool Driven Development, which is present everywhere. I can bet my kidney that your super simple “Hello world!” package uses at least one tool. I can also tell you its name: Babel (woohoo, magic!). Wrong guess? So let me try again: webpack (woohoo, more magic!). Yep, we’re still talking about one line of code that displays “Hello world!”.
In the old pre-ES6 era we would simply write:
and we’re done! But come on, it’s already 2017, it’s not professional anymore. Now we must:
- create a class that will produce ‘Hello world’ (or some pure function — FP FTW!)
- create a class that will display a string
- write an actual application that will instantiate both of the classes and use them together
- and did I mention tests?
Of course, everything must be written in super crazy ES 2022 syntax that isn’t supported anywhere so we must transpile it. Don’t forget that we’re using these super ES modules that don’t have support anywhere either, so we must use webpack to bundle all files.
“Hello world” JS app from 2008:
- lines of code: 1 (actually it’s more like ¼)
- dependencies: 0
“Hello world” JS app from 2017:
- lines of code: a lot more than needed
- dependencies: you can’t even name the exact number
You know what’s even funnier? The maturity of the tools we’re using. You know what’s the version of the first webpack 2 release? No, it’s not 2.0.0, it’s 2.2.0. At the same time, Babili is at 0.0.10 (I’m afraid to check if they’ve added support for passing options…). Rollup isn’t better, being at 0.41.x version. Stability? Perhaps you should consider Java.
We were probably already doomed when someone thought “Hey, I wonder if there is a way to use ES6 syntax to write code for environments that don’t understand it!”. That thought brought us to where we’re today: Tool Driven Development in JS. What we probably should do now is create a tool to manage our tools…
Or maybe what we ought to do is just go back to writing code. Normal code.
PS: And don’t even get me started about JSX!