Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why separate Node.js entry within Tools/Options/Text Editor #344

Closed
elmojo opened this issue Aug 2, 2015 · 3 comments
Closed

Why separate Node.js entry within Tools/Options/Text Editor #344

elmojo opened this issue Aug 2, 2015 · 3 comments
Labels

Comments

@elmojo
Copy link

elmojo commented Aug 2, 2015

Why is there a special section for Node.js within the Text Editor? These are JavaScript files and their behavior should be governed by the JavaScript settings within the Text Editor. The Text Editor is supposed to govern file types based upon the file extension. It shouldn't matter what type of project I am using.

@mousetraps
Copy link
Contributor

Good question!

The Epic Tale of NodeLS
Once upon a time, there was an analysis engine, named JSLS (JavaScript Language Service). This analysis engine handled all the JavaScript completions in Visual Studio. Oh how JSLS yearned to be a server-side language service… but like many JavaScript aficionados, JSLS was limited to client-side code. So you can imagine how excited it was when Node.js and NTVS came along - now, it too could work on server-side code!

So JSLS, the hard worker that it was, continued to crank day-by-day on both client and server-side code. Until one day... JSLS went rogue - stealing memory and cpu from Node.js developers every chance it got.

You see, JSLS works by executing the JavaScript code to dynamically provide syntactically correct completions.
https://msdn.microsoft.com/en-us/library/hh874692.aspx

JSLS was very accurate and worked well enough for the client-side, but unfortunately it didn’t scale very well to the much larger and more complicated Node.js projects people were building. Needless to say, JSLS was struggling. And the only way it could make ends meet was to steal more and more memory/cpu.

Until one day, a wonderful knight in shining armor (let's call him Dino) had had enough. And in a bout of courage, he began writing a static analysis engine to replace JSLS.

All the settlers across the land wept for Dino, for they thought he had gone mad. "How could you possibly write a new analysis engine?! There will be so many bugs! How shall we ever conquer them?! Plus this is going to be way hard to code review!"

"Not to fear, settlers. Let the bugs flock to me. I shall swat every last one of them." For most developers, these would have been famous last words…

And so it was decided. And after much toiling away, it was time. Dino had built and checked in the static analysis engine.

The historic 1st checkin: 062aa3a

A preview build was put out. It was not well received.

JSLS laughed as heartily as Steve Ballmer laughed at the iPhone. "They think they can replace me?! Mwahaha... this is just the beginning of their woes… just wait until they realize just how much totally undocumented functionality I had..."

Day by day, the settlers grew weary - bugs were invading... there was no more outlining... no more brace-completions... no more references...

But the brave knight assured them that everything was going to be alright. They didn't have much choice but to trust him. There was no turning back. The code was already checked in, after all.

Bugs were fixed, features were re-implemented. The settlers rejoiced! Life was getting better in the land of NTVS. Every so often, JSLS would attempt to fight back, to no avail.
https://nodejstools.codeplex.com/workitem/943

Now, most of the features have been re-implemented, most of the newly introduced bugs fixed. JSLS is once again confined to handling client-side code, looking towards NodeLS with envy. You can still find it if you change the build action from "compile" to "content" (close the corresponding editor for that file if it's already open), which will bring you client-side completions.

The downside of this heartwarming story is that every so often you find feature ghosts where JSLS once ruled and also have to manage your Node.js settings separately from your client-side JavaScript settings, which is admittedly unintuitive. The good news is that JSLS and NodeLS are slowly reaching parity, and may someday make amends (i.e. we're chatting with the client-side team about potentially combining forces.)

And so here our story ends, as our brave knight continues onwards into the sunset (and by sunset, I mean grey and rainy horizon because... Seattle :-/)… off to his next great adventure.

To be continued…

@mousetraps
Copy link
Contributor

Also related to #67, #158, #345, #333, #136

@elmojo
Copy link
Author

elmojo commented Aug 2, 2015

LOL, you made me chuckle there @mousetraps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants