Category: vscode

Switching from NetBeans to Visual Studio Code (for JavaScript development)

At first, I must say that I was a NetBeans developer for a long time and I still love it. It is the best IDE for Java development. Ok, maybe IntelliJ IDEA could be a competitor in such a contest, but for me, NetBeans would win πŸ˜‰

However, when it comes to JavaScript development, it’s absolutely different story. Since it has no strict type checking, then the editor must be more free. In fact, that means that the editor does not need to provide anything more than just colorings and at least some code completion (which does not need to be precisely accurate, most of the time just everything could be in there). Also, there is no need for refactoring features because it’s too hard to evaluate current coding style and make such feature really reliable.

There is nothing worse than tools which do some automatic stuff like refactoring and one can not rely on it (in the sense that it will not break your code silently).

So far so good. NetBeans for JS has a really nice coloring (well, I’m just used to it, hence I say it’s nice ;-), it also provides some useful items in code completion, it has a native support for Karma test runner, etc. So why I decided to switch?

That’s simple. The latest version of NetBeans (patched 8.2) suffers from memory leaks (I think that it happens only for JS development due to parser implementation switch, didn’t notice that in other project types) and my 6 years old MacBook Pro is not able to handle that gracefully πŸ˜‰ Yep, I was forced to restart NetBeans every hour. That was too much and I said ENOUGH! I already had a short term experience with Visual Studio Code editor, so gave it a chance and here are my switcher observations.

Code Coloring

I would never think that code coloring would be the biggest problem for me when switching from one editor to another. But it was. I wasn’t able to get used to new colors. Seriously! VS Code has a lot of native themes provided out of the box. I tried them all, but I was very nervous when coding in them. I wasn’t able to scan the code effectively through my eyes. It was very depressing.

So I tried to find some Custom Theme extension which would provide me same Code Coloring what I was used to from NetBeans. There is one, but it’s too poor. In fact, it doesn’t look like NetBeans coloring…at least for .js files. Yes, it uses the same colors, but it’s not the same. It should use them for same elements, etc.

So I decided to prepare my own NetBeans Light Theme. It is not possible to get 100% same experience, because theming in VS Code does not support semantic colorings, but I would say, that my NetBeans Light Theme is almost the same ans NetBeans one πŸ˜‰ When I applied that Theme, I was like a newborn child which gets pacifier. Calm and satisfied πŸ™‚

When you are used to NetBeans Theme colors, try to use NetBeans Light Theme extension for VS Code.

VSCode NetBeans Light Theme

Code Completion (a.k.a. IntelliSense)

Everyone of us is somehow used to it. You know…writing a code and then a small popup with code suggestions appears next to the caret automatically, or by pressing e.g. Ctrl+Space.

Functions and Properties

I use it heavily for Java development in NetBeans but didn’t use it much for JavaScript development. As I wrote before, it’s pretty hard to make a suggestion really usable for some kind of coding styles and most of the time I spent by finding the right item in Code Completion popup by pressing Up and Down back and forth. So the difference between Code Completion in NetBeans and VS Code is actually negligible. But just for me of course, because I actually don’t use it πŸ™‚ If you are used to it from your editor, you must make your own comparison πŸ˜‰

RequireJS

The project I work on uses RequireJS for modularization and that is where NetBeans is much further in Code Completion. In suggesting module paths in define() and require() functions. In fact, VS Code does not suggest anything, NetBeans suggests everything. But I think that it is just a matter of time when someone writes an extension for that. I would really appreciate that!

Edit: I found Path Intellisense extension but it doesn’t seem to work well for RequreJS modules. Maybe it could help you in other cases.

Running Tasks

Autodetection

This was a pleasant surprise. Because when you open a project in NetBeans, it tries to find the most common task runners – their config files (grunt, gulp, …) and detect possible runnable tasks what they provide.

VS Code behaves a bit differently but in the end, it detects possible tasks as well. You just need to run Tasks: Configure Task Runner command and that’s it. Then you can just invoke command console, write task and detected tasks are suggested automatically.

Custom Tasks

What is an advantage of VS Code is a possibility of defining your custom tasks for a workspace in a separate tasks.json file. I started to use it for tasks like test file, etc. because in that file you can use some magic variable templates provided by VS Code, like ${fileBasenameNoExtension}, which are replaced by proper values when such task is invoked.

Tasks 2.0.0

Commonly when you invoke a task it runs in a special Output Panel. The problem is that the output is not colored as you would expect – like running the command in terminal. And it’s also insanely slow which is really bad when you need to run thousands of tests many times in a day.

But you can switch to Tasks v2.0.0 by defining a proper "version": "2.0.0" property in tasks.json file (it’s a possibility for early adopters and can change in future versions). The main difference is that then all tasks are run in Terminal Panel. So coloring is much better and performance as well.

The counterpart of this improvement is that autodetection does not work, so you must define all your tasks in tasks.json file manually and in fact duplicate your Gruntfile.js. I already filled an issue for that so we will see what happen.

Git Integration

Git integration in NetBeans is much much further. And is awesome. Really awesome. But VS Code has an integrated support too. It’s not so good, but for basic workflow (commit, pull, push) it could be good enough. If you want more, there is a great extension called GitLens which adds a support for Git Blaming in a gutter, file history and much more. This extension is a must have for everyone who uses git. Basic editor support is just basic.

If using git is your daily bread, install GitLens extension.

Debugger

Well, do you think that we should use something else then Chrome Dev Tools? I don’t think so, but both of them have some integrated debugger. If you really want it. But, you know. CDT is CDT, so I don’t care about integrated debuggers πŸ˜‰

Extensions

NetBeans has its own Plugin Portal but as I remember I never used any public plugin. Everything what I used worked out of the box, or I wrote my own plugin πŸ˜‰ That’s not so strange as it could look like if you realize that NetBeans is not just an editor. It’s fully featured, project based IDE.

With VS Code it is an absolutely different story. VS Code is quite light editor with just basic support for some features. And as you could guess from paragraphs above, there is probably an extension for everything on VS Code Marketplace. And if it is not there now, then it will be there probably tomorrow πŸ™‚ Extensions are your best friend when using VS Code. You will not be able to live without them, trust me and just use them πŸ˜‰

Issue Reporting

If you find some problem in VS Code, don’t hesitate to file them an issue. It’s an open source hosted on Github so everyone of you certainly knows how to file an issue. The entire team is really flexible and I get answers to my issues in hours! I really want to appreciate their approach.

And that’s all! Thanks for reading and happy coding – in any editor you choose ;-)!

How I started to write JsThis, a Visual Studio Code extension

One day I read a story about how Microsoft open-sourced a great editor based on JavaScript. If you don’t know what’s going on, I’m talking about Visual Studio Code. It’s something what, at least at first glance, looks like another Sublime Text based clone. But it’s from Microsoft πŸ™‚ And because there is a lack of really good JavaScript editor at the market, I decided to give it a chance. It has a JS debugger, IntelliSense and everything what you need for JS development.

It has a support for other languages as well! Look at the overview.

First impression, first disappointment

I started it, opened a project (folder)…and…it looked quite cool. Simple, clean and what was the biggest surprise, it was quite fast.

Then I started to code…and the first and the biggest problem occured. Even though JS IntelliSense (Code Completion) works well for simple functions, variables, etc., it doesn’t work for this keyword at all. And it was the biggest problem for me, because the project I work on is prototype based. We use RequireJs modules and inside it we use this ES3 object pattern:

var MyConstructor = function () {
    this._myProperty = 'my property value';
};

MyConstructor.prototype.doSomething = function () {
    // do something
    console.log(this._myProperty);
};

return new MyConstructor();

So code completion for this._myProperty in doSomething(); method doesn’t work. I looked at the Extension Market Place whether there is some extension which could enable such IntelliSense, but unfortunatelly there is no such extension.

So I decided to write my own…and call it JsThis.

After few days I found a mention about a support of prototype style in version 0.10.8 notes, but suprisingly it didn’t mean, that it should work in 0.10.8 by default. One must enable it manually. It was clarified in a issue I filled.

Extension implementation process

First steps

It is very easy to start. Just look at the Extension web and follow both of prepared examples. There is one simple Hello World extension and one a bit more complex Word Count extension. They will guide you through the extension creation process and will show you some basics.

After reading these examples I was able to implement a basic CompletionItemProvider which was called in .js files when one invoked IntelliSense. I played with the API a bit and after few hours I had a prototype of my custom extension which collected this usages and suggested them in proper places.

IntelliSense - Code Completion

Why it swallows an errors?

What really annoyed me during the whole implementation was the fact that VSCode swallowed all the errors and exceptions which occured e.g. in third party libraries! Errors were just caught somewhere and the code execution continued like nothing happened. It wasn’t even logged to console! Why? Really don’t know…

Yes, there is a possibility to set the debugger to stop on Uncaught exceptions and All exceptions, but…you know. I don’t wanna stop. I just want to know that something went wrong. I want VSCode to just log it for me.

Didn’t find a suitable solution.

Travis integration should be simple, documentation says…

I wanted to try how difficult would it be to enable running tests on Travis. I followed the documentation and it seemed that it will be pretty simple. But actually it wasn’t.

Even though I followed the documentation properly and properly did everything what was described there, my jobs were failing. The problem was, that my project was not written in TypeScript, but in plain JavaScript.

The instructions assume, that the extension is written in TypeScript and that your code will be compiled before the test run. It automatically sets some paths to “compilation output folder” and it really can’t work. Plain JS code will not magically appear in that “output folder”, so then the test run fail.

What I had to do was to remove - npm run vscode:prepublish section from .travis.yml. That was the part which did the compilation and it ended up with a “Missing TypeScript” error.

The second thing I had to do was to add this part to .travis.yml:

env:
  - CODE_TESTS_PATH="$TRAVIS_BUILD_DIR/test"

which says where your test files are. Otherwise VSCode appends /test/out instead of just /test.

I filled an issue because I thing that it really needs to be documented somewhere.

The another problem was with defined VSCode engine version. That’s the version of API which is downloaded before tests start. The documentation says that you should use ^0.10.7. But I couldn’t. Why? To be honest, I really don’t know. When I set it then Travis started to complain and builds failed.

So I looked at some alredy existing extensions (written by Microsoft itself) and…they use 0.10.x! Ok, so I tried it…and it worked. Ok, it worked, but only on a Linux machine. Even though the documentation says that you can use:

os:
  - osx
  - linux

it didn’t work for me on OS X. So I temporarily commented that out and filled another issue. And, yes, it worked locally on my Mac πŸ˜‰

After these changes tests were passing on Travis in Linux.

Conclusion

Here I described what I bumped into when I tried to work with and on the Visual Studo Code editor. I don’t think that it’s the best solution what you can find on Internet, it’s just in beta, but it’s definitely worth trying. It’s still under heavy developement, if you look at its GitHub issues, you can see how devs are working on it.

And what about my extension? I will keep working on it. Yes, it can happen that VSCode will have a native support for such features (I don’t know anything about this support, but prototype should work in 0.10.10), but at least I will learn something new πŸ™‚

Thanks for reading!