Real Developers

Real Developers use Tools

Last week this tweet generated a lot of drama in the Javascript community:

I responded to this like I respond to everything on the Twitter — sarcastically:

Adrian responded in good humor, encouraging me to wait to pass judgement until I had actually watched the talk, saying the tweet was taken out of context.

I watched the talk, read the slides, and then read the blog post about the talk. Now lets discuss, point by point, some of the issues Peter-Paul Koch has with modern UI development.

Web developers want to emulate native apps, which he thinks is not possible.

Peter-Paul Koch complains in his talk about the complexity created by separating React from React-DOM. He misses that by separating these two components React becomes an interface for rendering UIs that can be implemented by React-DOM to render in the browser. By coding to the React interface we can implement renderers (renders?) for other UI environments like iPhone and Android in React Native, or Virtual Reality with React VR.

React Native doesn’t emulate native functionality — it transpiles to native functionality on both iPhone and Android. If he thinks emulating native functionality isn’t possible I’d invite him to check out the React Native Showcase where large companies like Facebook, Airbnb, and Walmart are managing apps, natively, across three platforms with a single team writing Javascript.

Browsers are adding too many features!

PPK goes on to say Javascript developers trying to emulate native apps caused browsers to add too many features. He claims its impossible to tell which browsers support which features at any given time. Hes finishes, without a hint of irony in his voice, saying he preferred browsers in 2004. For those of you who don’t remember the internet 13 years ago IE6 had 75% market share, Chrome didn’t exist, and Netscape accounted for ~2% of web requests.

I was curious if IE6 supported some these new features browsers are implementing like XMLHttpRequest (It does, depending on which month in 2004 you’re referring to) so I went to Google and searched for “ECMAScript compatibility table” to figure out which browsers support which features and found one in like two seconds. Its worth noting I’ve never needed to search for this before because I use Babel, one of the many tools plaguing Javascript.

Javascript has too many tools!

Look at all the tools Javascript has! According to PPK this is a modern JS stack:

Excluding Yaddah Yaddah Yaddah because its a fake tool used to make the list look longer we deduce that the minimum amount of tools required to meet the “too many tools” threshold for a programming language is six. I wonder if the six count zero indexed? If so maybe we could add Yaddah Yaddah Yaddah back in.

In reality the modern JS stack looks more like this:

  1. React
  2. Babel
  3. Webpack (Replacing Browserify AND Gulp)
  4. Typescript

Six tools is not too many tools. Four tools is only two more tools than the Merriam-Webster definition of a couple of tools, which we can all agree is not that many tools.

Every language ever created has at least four tools that come with it, and at least one tool who created it. Because every language needs a package manager, build scripts, frameworks, and code analysis.

A key distinction of front-end web programming is that users download your code when visiting a web page, which means users get “punished” if your code is bloated. Source

Back end developers run their tools on something called a “server” which saves the client from loading the extra bytes these bloated libraries need to help us reuse code more efficiently. This part of the talk is especially confusing because front end tools are exactly like their back end counterparts in that the only library code that gets delivered to the client is the framework code.

Webpack generates a module by traversing my React app, eliminating dead code it finds along the way. This module is passed to Babel which transpiles all the Typescripted ES6 I wrote to vanilla Javascript so that it can run consistently across all the browsers that exist out there. The resulting code is minified and contains only the React framework code and my application code.

This talk negatively generalizes UI development, ignoring the huge advancements which have been made in Javascript that are only possible because browsers thankfully continued innovating rather than forcing us to deal with <! — IE HACK— > comments and <blink> tags in a year long moratorium.

We don’t measure a developer’s skill by the number of tools their programming language requires for same reason we don’t evaluate developer productivity by lines of code written: its a poor indicator that is easily manipulated.

So how do we measure real developers? Laurie Voss hit the nail on the head… Probably with a hammer… Which is a tool.

About the Author:

John used to be an enterprise Java developer for a large consulting firm. In his free time he enjoys large object hierarchies, inheritance over composition, and searching for overly verbose class names in the Spring framework.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.