Tooling - the orphan child of web development?
Tags: webdev, tooling, ide, vscode
Published: 2018-04-01 20:27:19

---
title: Tooling - the orphan child of web development?
published: true
description: How JavaScript moves fast, but tooling does not
tags: Web Development, Tooling, IDE, vscode
---

# Once in a Dev Meetup...

Even though I consider myself mostly a backend developer, from time to time I try to get my feet wet in the frontend areas and keep in touch with what is happening in the world of HTML, CSS and JavaScript. On such an occasion, I recently visited a local developer meetup and attended some pretty neat talks.

One of the speakers (a full-time react frontend developer) was presenting some of the new aspects in React 16 and did a live demo on some of them, switching back and forth between WebStorm and a browser. In the Q&A session, I could not help myself but asking if he could open the structure view of his JSX file for a moment (I wanted to see what it looks like). He gave me a weird look, so I directed him where to click in the IDE. When the panel popped up, he said 

> "I have never seen this before, what is that?"

I was sitting in the audience, baffled, at a loss for words. I personally do not use WebStorm (due to the subscription model), but one of my primary issues with VSCode is that it *still* does not provide a proper outline / structure / symbol tree view (there is a [plugin](https://github.com/patrys/vscode-code-outline), but it's very basic). I consider such a view essential for working with larger code bases. And this frontend developer was standing out there, looking at his WebStorm window, and had no idea what to make of it.

# Tools can't keep up the pace

JavaScript frameworks just keep popping up like crazy these days. The latest and best way to write GUIs is just not what you have been doing six weeks ago. Being used to the release cycles of Java (even though it is picking up the pace as well these days), this speed is insane. Modern web development doesn't even shy away from changing the very syntax of the employed languages (hello [CSS Modlues](https://github.com/css-modules/css-modules), or even JSX as such). But in all this entire process, somehow nobody seems to care about the editor support for all those shiny tools. The "notepad is good enough" mentality is somewhat deeply rooted in the web development community today it seems. This is in the same vein as all the JavaScript developers out there who still use neither [TypeScript](https://www.typescriptlang.org/) nor [Flow](https://flow.org/) - why this is the case is beyond me. Sure, for a 2000 LoC web page, that is totally enough. But in the areas where I spend my working time in, there is no such thing as a "small" application. Thousands of files containing hundreds of thousands of code lines are day-to-day business there. Try to convince me how any of that should work without proper tooling. I'll wait.

> If for every 100 JavaScript frameworks one decent IDE would pop up, the web world would be a better place.

# But we do have VS Code!

[Visual Studio Code](https://code.visualstudio.com/) is indeed an excellent editor, I personally think that it's the best editor Microsoft has ever published to date. However, neat as it may be, it's an *editor*. It is not an IDE. Now, I am fully aware that there are people out there who prefer editors (legend has it that somewhere lives a tribe of people who use [vim](https://www.vim.org/) without being forced to). To all these folks - I'm sorry, but you came to the wrong article.

There are features that are absolutely essential for being productive in large code bases (in my personal opinion of course) that differentiate an IDE from an editor:

- **Code Completion**

I'm not talking about _word_ completion or _best guess_ completion here, but the real deal. With the uprising of language servers, this has become a lot easier to achieve (at least for strongly typed languages) even in editors.

- **Structure View**

Also known as outline or symbol tree view. When skimming through a code base, I don't even want to see the source code, but only the structure, and I need to be able to navigate it quickly to get an overview.

- **Type Hierarchy View**

Ever wondered how many subclasses of your class there are in your entire code base? An IDE can tell you the answer at the press of a button. "But why do you even need it, inheritance is avoided in JavaScript anyways" - that's for another article ;)

- **Refactorings**

Even though the hipster scripting kids on the web these days are blissfully ignorant about it, the [Code Smells described by Martin Fowler](https://martinfowler.com/bliki/CodeSmell.html) **do** affect them as well as anybody else in the software engineering business. And adequate tools for refactoring are a necessity to deal with them appropriately.

- **Auto Import**

I don't want to look for the exact location of a class I need every time. An IDE is smart enough to offer me matching proposals given the class name and add the import accordingly. It can also do that for an entire file in batch, also removing all unneeded imports in the process.


> These are **basic** IDE features. We are not even talking about more advanced structure analysis possibilities here.

Ok, let's see how our dear vscode lives up to that list. Thanks to TypeScript and its language server, it has you covered when it comes to code completion. I've found this feature to be working very well, no complaints there.
On to the structure view, as indicated before, there is a third party plugin that offers very basic functionality, however, vscode at the moment does not even let you relocate the individual view panels on screen, and the current default location for the structure view is in the bottom left corner of the screen - which is less than ideal.
Type hierarchy is an unknown word in the vscode dictionary. As far as I know, there are no third party plugins either.
What about refactorings? Well... vscode **can** handle renamings. Mostly. Except if you rename a folder. Or move a file. Or... well, let's face it, restructuring typescript application folders at the moment is a major pain. And if you believe that the extent of refactorings is renaming and moving files around, you'd be sorely mistaken. Just have a look at what [IntelliJ does in the refactoring department](https://www.jetbrains.com/help/idea/refactoring-source-code.html) for Java. *That* is the level of tooling I am talking about.
Auto-import is a double-edged sword in vscode for TypeScript. Some imports are recognized automatically, others are not; I've yet to find out how exactly this is determined. There is a third-party plugin named [TypeScript Hero](https://github.com/buehler/typescript-hero) that is said to have import organization for an entire file, but I have not tried it yet.

My verdict for vscode as an IDE is therefore mixed - while it does some things extremely well (code completion, smooth text editing, fast startup), it has definitly drawbacks in other areas. And as far as non-commercial tools are concerned, this seems to be about as far as we go at the moment.

# Final words

Coming from enterprise Java to the Web dev world, I am puzzled why not more people are kicking and screaming for better tool support. Frankly, I am amazed how web devs build large application these days, equipped with what is in comparison nothing more than makeshift hammers consisting of sticks tied to stones. And when asked about it, they will tell you _"It's okay, I don't need more than that"_. Is this just a matter of background and mentality? Would these folks desire more advanced tools if they knew what they were capable of? What are your thoughts on tool support for web development?