Microsoft Adds Node.js Support To Visual Studio

shutdown -p now writes "Coming from the team that had previously brought you Python Tools for Visual Studio, Microsoft has announced Node.js Tools for Visual Studio, with the release of the first public alpha. NTVS is the official extension for Visual Studio that adds support for Node.js, including editing with Intellisense, debugging, profiling, and the ability to deploy Node.js websites to Windows Azure. An overview video showcases the features, and Scott Hanselman has a detailed walkthrough. The project is open source under Apache License 2.0. While the extension is published by Microsoft, it is a collaborative effort involving Microsoft, Red Gate (which previously had a private beta version of similar product called Visual Node), and individual contributors from the Node.js community."

Comments

Visual Studio...

[fisted]

...does it even Clippy?

Won't purchase without.

Re:Visual Studio...

[shutdown -p now]

Not yet, but you can file a feature request.

Re:Visual Studio...

[shutdown -p now]

Still no feature request. I'm disappointed.

If there is one in the tracker and it gets over 100 votes, I'll personally implement it. It's going to appear once you open a project and ask, "It looks like you're trying to do some work. Would you like to be distracted?". If you say yes, it'll open Slashdot in a Visual Studio tab. ~

Just what the nodejs

[stewsters]

I'm sure the NodeJs hipsters running the latest flavor of Linux with custom desktops will close out their sublime text and immediately wget that.

Re:Just what the nodejs

[Anonymous Coward]

but is wget ready for granny?

Re:Just what the nodejs

[pieisgood]

If I had the mod points.....
This describes my friend perfectly. I will say though, he's a way better programmer than I am.

Re:Just what the nodejs

[Anonymous Coward]

Microsoft has been fairly involved in Node for some time now...they had a pretty large presence at NodeConf when I went about 18 months ago. But even if Node developers don't want to use Windows or VisualStudio, the fact that they've open sourced it could lead to the development of better IDEs that Node developers do want to use.

Re:Just what the nodejs

[Anonymous Coward]

Well, Ceylon 1.0.0 just came out about a week ago and has great IDE, js, and node.js support, although it is not "pure" node.js. So I guess that already happened?

Re:Just what the nodejs

[Anonymous Coward]

Well I was about to, but now the mood is ruined so I'll curl it instead.

Spoilsport.

Re: Just what the nodejs

[Anonymous Coward]

MS also has been helping Java with own jvm. Is this also a kiss of death...

Re:Just what the nodejs

[Anonymous Coward]

They'll do that once Microsoft buys out Sublime and closes it.

Re:Just what the nodejs

[Anonymous Coward]

I had to look up what "sublime text" was, and I must say I'm not impressed.

I use an old copy of Crimson Editor (v 3.70, before it became "emerald editor" and pioneered the whole ALL CAPS MENUS AND TABS thing, long before Microsoft copied it). Sublime just isn't as good (hell, neither is Notepad++ or Emerald). Crimson has as many project-level features as any of the others, and it has that one "killer app" that nothing else does quite as well: column editing mode. I've never found a column-style editor as good as Crimson's. It's a godsend when converting huge spreadsheets into SQL insert statements, which I have to do quite frequently in my line of work.

Hipsters can keep it. I'll keep on truckin' with Crimson.

Re:Just what the nodejs

[phantomfive]

Microsoft has been scaling back the use of ASP.net internally. The groups I've talk to use it mostly to talk to the database, and do everything else in Javascript.

Apparently there are some groups at Microsoft who have gone all the way and are now using Javascript everywhere.

Re:Just what the nodejs

[tibman]

Column mode like when you do alt+shift+up/down?

Re:Just what the nodejs

[batkiwi]

It depends on what you mean by "asp.net".

Over the last 3 years asp.net has evolved from "gui controls you compose on a page with TONS of overhead" to "a lightweight framework that looks a LOT like spring". What most people who have used asp.net in the last 10-12 years think of as asp.net is basically dead.

http://www.asp.net/web-api for example. Many people us this and knockoutjs for dotnet based web projects.

Re:Just what the nodejs

[KingMotley]

Or Visual Studio's holding down ALT while selecting a block, or textpad's block mode?

Re: Just what the nodejs

[Anonymous Coward]

The Embrace of death, perhaps.

Re:Just what the nodejs

[butalearner]

Note that AC specifically said, "that nothing else does quite as well," which is not quite the same as "that nothing else does." Personally I'm not aware of any bothersome differences in implementation, but I'd be interested to hear them. I want to say that one editor I've used will plop a bunch of whitespace at the end of a line if you copy and paste the uneven ends of lines, but I just tried the three at my disposal at the moment (VS, Notepad++, gVim) and none of them did that.

Here is how to do it in a bunch of different editors, by the way.

Re:Just what the nodejs

[butalearner]

Replying to myself. I just did some searching, and it seems that up until VS 2010, it didn't have zero-width selection, which I have just verified to be true in VS 2008. I can see how that could be a bit annoying, though there is a pretty simple workaround (select the column, press tab, then column select the new whitespace). Notepad++ (6.2.2) and gVim (7.3) both have zero-width selection. Any others?

Re:Just what the nodejs

[pspahn]

...also create selections with middle mouse+drag.

I like Sublime. I find that for my workflow, it's light-weight helps it stay out of my way. I used to hang onto Notepad++, but found that Sublime is easier to use.

I've tried and been disappointed from so many IDEs that I basically just gave up. They all have great features, but it's tough finding one that has the correct mix of features I'm looking for. Sublime is cross-platform and not built with Java. That's a big one. S/FTP integrated is essential (so many IDEs make such a mess of FTP integration it's nearly unusable).

Re:Just what the nodejs

[Anonymous Coward]

the question is: does it have a vim mode?

Re:Just what the nodejs

[Fallso]

I'm sure the NodeJs hipsters running the latest flavor of Linux with custom desktops will close out their sublime text and immediately wget that.

Linux? Too mainstream, man.

Re:Just what the nodejs

[Anonymous Coward]

If you regularly need to convert spreadsheets into SQL insert statements you should have long since spent half an hour writing a spreadsheet formula or macro or a perl script or something else to do it. Doing this in a text editor is an error-prone waste of time.

Re:Just what the nodejs

[fantazem]

Ultraedit

Re: Just what the nodejs

[Anonymous Coward]

As someone who used to swear by Crimson Editor for years... I have to say you are wrong. Sublime Text is simply better. It has a "multiple cursors" paradigm that not only lets you do column editing but it lets you insert text in multiple places throughout the document even if they aren't column aligned. Ctrl +D to add the next instance of the selected word to the multiselection is my top used feature now.

But the real power of Sublime Text and the reason I will never go back to Crimson Editor is the package manager for third party extensions. I use tools now like Text-Pastry, which let's me insert ranges of incrementing numbers into whatever column I want.

heh

[Anonymous Coward]

Microsoft adopts my least favorite free software project. No harm no foul.

node.js.Extend.too ?

[denis-The-menace]

Does anybody have dollars to bet against my donuts that they will require the use of proprietary keywords and extensions?

Doing anything else would be so bizarre for Microsoft.

Re:node.js.Extend.too ?

[cbhacking]

If it was compiling down to .NET, there would probably be some completely optional extensions to make use of the .NET framework (mostly, adding interoperability with other .NET languages). As is, I don't even know about that. I have no particular use for Node.JS myself, but I do like having more languages and frameworks supported in VS.

Re:node.js.Extend.too ?

[shutdown -p now]

There is no proprietary keywords and extensions involved here. It works with the standard V8-based Node.js implementation from http://nodejs.org./ In fact, that doesn't even come in the box, so you have to download and install it separately.

Re:node.js.Extend.too ?

[mwehle]

Does anybody have dollars to bet against my donuts that they will require the use of proprietary keywords and extensions?

Doing anything else would be so bizarre for Microsoft.

I think you've got this backwards. If you are sure that Microsoft will require the use of proprietary keywords and extensions then it is you who will be willing to wager dollars, and you will only require doughnuts to back the opposing position.

Re:node.js.Extend.too ?

[Nerdfest]

That's the 'embrace' part. They have been a little better about standards lately though, so you never know.

Re:node.js.Extend.too ?

[shutdown -p now]

(disclosure: I am a developer on PTVS and NTVS team)

I would hope that the track record of our particular team with Python Tools would speak for itself here - it's been out there for two years now, with 2.0 released last month, and it was and remains all about standard Python. While it does support IronPython, for example (but also Jython, PyPy, and other third party implementations), CPython remains the primary target because that's what the community uses, and our goal is to attract developers from said community to VS, Azure, and other Microsoft platforms and products, not to hijack their language/framework of choice.

The story with NTVS is similar: it's all about making VS a compelling choice for Node.js developers without forcing a Microsoft-top-to-bottom stack on them (which no-one would accept, and rightly so). In that sense, it is in line with Azure offering Linux VMs, or the ability to write Node.js-based Azure push notification services for Windows and Windows Phone.

Re:node.js.Extend.too ?

[Nerdfest]

Yes, your team has a great track record, but unfortunately Microsoft has the worst in the business, or at least very close to it. You've got to expect some suspicion.

Re:node.js.Extend.too ?

[shutdown -p now]

Sure, karma is a bitch. In fact, part of what we're trying to do as a team is to turn it around, both the external perception as well as internal company understanding on openness - not just open source, though that as well, but generally working together on common things, and purging the NIH and the "we must be in charge" syndrome.

It's not just us, too - it has been a growing thing in the developer division, in general, with a lot more stuff being open sourced, and a broad change of attitude from a single monolithic take-it-or-leave-it stack, to going where the people already are and supporting what they already do. You might have noticed some other glimpses of that if you've been following the general news on MS dev story, e.g. with a renewed effort on C++ standard conformance, or a lot more attention to JS and HTML5.

Re:node.js.Extend.too ?

[Nerdfest]

The developers may want to have a word with the legal/patent department if they're looking for goodwill from the developer community at large. What Microsoft is doing with the Android patents is up there with SCO. They also teamed up with Appple as 'Rockstar' for some of the worst patent abuse around, and lobbied against the current patent reforms. It's going to be a big job.

Re:node.js.Extend.too ?

[KingMotley]

Not nearly as bad as what Google/Motorola have been doing with theirs, namely h.264 crap.

Re:node.js.Extend.too ?

[KingMotley]

Can you do PHP next? Thanks.

Re:node.js.Extend.too ?

[Nerdfest]

I think it was just Motorola when that started, but regardless; even if they're insisting on some ridiculous value to their patents or something, at least they're not making people sign an NDA to have a look at what they're being threatened with. I'm still amazed that that sort of thing is legal.

My understanding is that it's just a court decision on the F part of FRAND, but I haven't followed it closely.

Re:node.js.Extend.too ?

[Anonymous Coward]

The exchange ration has reversed since that saying was first used. Doughnuts are more valuable than dollars now.

Re:node.js.Extend.too ?

[shutdown -p now]

DevSense are the PHP-in-VS guys. Have you seen their product? They do, in fact, share a lot of code with PTVS, and contribute back improvements.

Re:node.js.Extend.too ?

[exomondo]

If you are concerned not about the product but the actions of those associated - but not directly involved with - the team who made the product even when those actions have nothing to do with the product then which company provides products you do use? It can't be Microsoft or Apple or Google or Canonical or Amazon or pretty much any company.

I buy the argument that you don't want to support the actions of companies engaging in the sort of behavior you find reprehensible and that is valid but really the approach to that should be to not support the products involved (in your case Windows Phone, and perhaps those manufacturers who have agreed to pay royalties, if Samsung really believed they were without merit I don't think a behemoth like that would knuckle under). If not then the list of companies you can support is pretty short.

Re:node.js.Extend.too ?

[shutdown -p now]

My own personal take on software patents (which is obviously my own only, does not represent the opinion of my employer in any way, blah blah etc) is that they can play a useful role, but they should be significantly scaled down in terms of what you can patent. Complicated algorithms, like, say, MP3 or H.264 or other compression stuff - probably yes, since that takes real time and effort to develop. But I'd love to see the "one click" patents die a fiery death. Some laws that would require non-discriminatory licensing for useful patents for interoperability and standards compliance purposes would also be great.

So EFF gets part of my paycheck every year. Ironically enough, it qualifies for MS donation match program, so they match it dollar for dollar. ~

Re:node.js.Extend.too ?

[Anonymous Coward]

We have good reason to be wary. Typescript (as of v. 0.9) expects an IE-only behavior from a String built-in function. (I can't remember exactly *what* the behavior is, but is *is* present.) Every other browser's JS implementation has a the same String implementation.

We've been badly burned in the past by MSFT's subtly incompatible extensions. We know that MSFT *loves* to move into Extend mode once it feels it has enough marketshare to do it without substantial consequence. We're all just waiting for the other shoe to drop. Perhaps if we stay away for long enough and your "communities" stay small enough, it never will. That would be *great* for the computing community as a whole, no?

Re:node.js.Extend.too ?

[shutdown -p now]

We have good reason to be wary. Typescript (as of v. 0.9) expects an IE-only behavior from a String built-in function. (I can't remember exactly *what* the behavior is, but is *is* present.) Every other browser's JS implementation has a the same String implementation.

This sounds very surprising to me because 1) TypeScript compiler is itself written in TypeScript, and 2) it runs on Node.js (as a console app). So if there's something IE-specific there, they'd be the first victim to that, which implies that it is not intentional.

Can you clarify? TS itself doesn't add any new semantics to JS, it's strictly about syntactic sugar (like classes) and compile-time type checking based on type annotation (which is type-erased, so at runtime there's no difference whether there are annotations or not). I suspect that what you're referring to is an incorrect type annotation on String that describes IE-specific behavior rather than what you actually see. This is where they define it (interface String). If it's still wrong somewhere, I bet you could just make a pull request to fix it, and they'll accept it.

Re:node.js.Extend.too ?

[Anonymous Coward]

No amount of DevDiv love can erase this:

http://www.microsoftstore.com/store/msusa/en_US/cat/Scroogled/categoryID.67575900

Re:node.js.Extend.too ?

[Anonymous Coward]

why would you need to erase that? the only people that get angry about the scroogled campaign are all the google apologists, just like how all the microsoft apologists hated the mac vs pc ads.

Re:node.js.Extend.too ?

[Anonymous Coward]

So EFF gets part of my paycheck every year. Ironically enough, it qualifies for MS donation match program, so they match it dollar for dollar. ~

Oh, so now they put back EFF in the donation program ? Also MS person here ... I remember indeed that many many years ago EFF was in the list of organizations you could donate to, but something like ~10 years ago I could not find it anymore and I stopped looking for it ... It was during the time of the SCO trials.

Regarding this "growing thing in the developer division" about openess and open source ... Do you still need to get approval from your PUM for any piece of open source software that you install on your machine -- even it it's just a binary ?

Re:node.js.Extend.too ?

[Pherdnut]

Paying Microsoft for a tool is only in part distasteful to me as a JS developer because of their 20 years of anti-competetive practices many of which has made life as a client-side UI developer a pain in the ass. It's also distasteful because I can read the history of my most negative working experiences in the end results of all their products. It positively reeks of design committees with no firm hand at the helm and clueless upper management that weighs success in terms of quantity of bullet points on feature lists.I certainly get the sense that there's something of a sea-ish change going on with MS lately but I'll believe it when it sticks and they start acting like a tech company again.

Just what we needed...

[Anonymous Coward]

...more crapps!

Stop with JavaScript

[sanosuke001]

Please, for everyone's sanity, stop it with the JavaScript crap; it's a terrible language, a terrible platform for applications, and supporting it is just prolonging it's Reign of Terror. (this is why we still have flash).

Re:Stop with JavaScript

[Anonymous Coward]

When you get all browser makers to agree on a new language to use we can stop with JavaScript.

Re:Stop with JavaScript

[sanosuke001]

No, we shouldn't build applications in browsers in the first place.

Re:Stop with JavaScript

[royallthefourth]

"please don't make me learn how to use Javascript properly"

Re:Stop with JavaScript

[Anonymous Coward]

Convince everyone to go back to 1993 then.

Re:Stop with JavaScript

[Anonymous Coward]

Get them to agree to implement Dart :)

Re:Stop with JavaScript

[lgw]

Yeah, that C-to-JS compiler is a pain to work with, please don't make me.

Re:Stop with JavaScript

[bill_mcgonigle]

it's a terrible language

Yeah? It has many of the language features of a first class dynamic language. There are better languages, but what is it about JavaScript as a language (I don't care what you think about how it's used on specific websites) that you find objectional.

Re:Stop with JavaScript

[i kan reed]

Oh yeah, good idea. Let's just be rid of this whole Internet thing, and all the crap people put on it.

Re:Stop with JavaScript

[Anonymous Coward]

The performance and capabilities of these browser applications feel like they're from 1993, but yet they require 100x the resources of a modern desktop program.

Re:Stop with JavaScript

[sanosuke001]

1. Being dynamic

Re:Stop with JavaScript

[sanosuke001]

Yeah, it's so great that it'll allow you to just decide to use some member variable somewhere without declaring it and making it impossible for someone maintaining it to know that it even exists. Or the fact that there's no way to know the type of a variable without basically reverse engineering the source code in its entirety.

Re:Stop with JavaScript

[sanosuke001]

I had to do some JavaScript at work and talked them into letting me use Dart instead; unfortunately, Dart isn't perfect either (get rid of the dynamic typing and get Dart VM support (instead of it running dart2js) and get it out of beta and it would probably be a lot better. It's definitely a step in the right direction but still too dynamic for me. I prefer structure.

Re:Stop with JavaScript

[Anonymous Coward]

It is a good idea. They should write their fuckin' apps in a programming language that isn't an absolute piece of shit.

Re:Stop with JavaScript

[Anonymous Coward]

JavaScript will certainly let you shoot yourself in the foot if you're careless, but it's nowhere NEAR the foot-gun that C is.

Re:Stop with JavaScript

[Anonymous Coward]

So... if I'm understanding... you want a language that isn't dynamic?

Re:Stop with JavaScript

[tiagosousa]

Of course crying for the end of javascript is a lost cause at this time. But back on topic, node.js is supposed to run in the server, so it doesn't need browsers to agree on anything. Yes, I understand the sinergy of using the same language in both client and server, but it doesn't excuse the fact that javascript is perfectly avoidable server-side. From that perspective, I actually agree with him.

Re:Stop with JavaScript

[Dahamma]

Well, duh, the point is not having to port/compile native apps for all platforms. With Javascript you just write one web app that is 100% compatible on all platforms, OSes, and browsers! Man... I thought I could keep a straight face while typing that but I give up.

Re:Stop with JavaScript

[Anonymous Coward]

1. dynamic
2. stupid
3. functions are not objects. don't pretend that they are
4. objects are not functions. wtf.
5. proto does not inheritance make
6. single threaded
7. it runs in a browser, and that's enough. don't run it on a server, really.
8. null vs undefined - for fucks sakes, just make up your mind

Re:Stop with JavaScript

[kiddygrinder]

yeah! when i want to fill in a form i want to download an executable rather than piddle around with this javascript crap! hell the internet should just be replaced with an app store!

Re:Stop with JavaScript

[tiagosousa]

Good news: it *is* out of beta!Sadly, it'll be years, if ever, before we see dart VM in browsers outside of google (I'm sure it'll come to chrome soon, now that they declared dart is production-ready.)

Regarding dynamic typing, don't forget it has static type annotations, too. I was a bit suspicious at first but now it's one of my favorite features of dart. On the one hand, the annotations give a peace of mind because everything is checked at compile-time. On the other, sometimes it's useful to be able do just declare a dynamic var to speed up prototyping, or because it's a minor thing and its type is completely irrelevant, and it just works. Best of both worlds, in my opinion.

Re:Stop with JavaScript

[Anonymous Coward]

Please, for everyone's sanity, stop it with the JavaScript crap; it's a terrible language, a terrible platform for applications, and supporting it is just prolonging it's Reign of Terror. (this is why we still have flash).

I know there are a ton of responses to this already, so I probably don't have a lot of chance of being modded up. That said...

Please give JavaScript a try.

Just a year ago, I held a similar to view to your own.
JavaScript was just a toy language. Nice for adding special effects to a web page.
I saw some interesting toys built in the browser, but I would never have called JavaScript a 'real' programming language.

I'm not sure what made me consider Node.js; I probably saw it in some Slashdot article.
I downloaded the thing and gave it a shot. Now I am absolutely hooked.

After a decade of writing in various assembly languages,
followed by a decade of writing C/C++,
followed by a decade of writing Java,
I will unashamedly admit, CoffeeScript is now my favorite programming language and Node.js is now my favorite platform.

I learned the ropes with the book Smashing Node.js.
If you enjoy writing software, I humbly suggest giving it a try.

Re:Stop with JavaScript

[royallthefourth]

it's so great that it'll allow you to just decide to use some member variable somewhere without declaring it

Undeclared variables are implicitly global. A code inspector will warn you about mistakes like that!

there's no way to know the type of a variable

It should be clear from the way it's used or by the documentation (if it exists). This is true of not only Javascript, but every dynamic language. If that's not good enough, use one of the readily-available and straightforward debuggers. Another quick approach is to just console.log(var)

Re:Stop with JavaScript

[Anonymous Coward]

There are a number of reasons. Admittedly, the language has a lot of quirks (this shows a few). But so so other languages. I think the bad rap js gets comes down to three things.

1) It's a prototype based language but people expect it to behave like a class based language.
2) The DOM. (which isn't the language's fault).
3) traditionally, a lot of JS code is often copy pasted from various sources and hacked together to mostly work by people that have no business being a programmer.

Speaking of tradition, the old days of browser incompatibility during the IE vs Netscape wars didn't help it's reputation much.

Re:Stop with JavaScript

[shutdown -p now]

What you really want is PNaCl. LLVM bitcode running sandboxed in the browser at native speed is the pinnacle of client-side scripting - you are not limited in your choice of languages and frameworks at all; if you want to script in C, you're welcome to do so, and if you prefer some high-level dynamic language like JS or Python, then you just run the corresponding VM in the sandbox.

Re:Stop with JavaScript

[NoImNotNineVolt]

Forms on webpages have been around since at least HTML 2.0, in 1995.

Or, for a cynical twist on your post:
yeah! when i want to fill in a form i want to download a script that my browser will execute in a virtual machine rather than piddle around with this html crap! hell the internet should just be replaced with untrusted executable code!

Oh wait. That already happened. Fuck you and the executable webpage you rode in on.

Re:Stop with JavaScript

[OhPlz]

Oh yeah, good idea. Let's just be rid of this whole Internet thing, and all the crap people put on it.

WWW != Internet

Re:Stop with JavaScript

[tibman]

no problem! i'll send you some binaries you can run to access my site. It's safe, TRUST ME.

Re:Stop with JavaScript

[Anonymous Coward]

1. Dynamic
2. Prototype-based objects
3. Extremely shitty design that makes optimizing it very hard (see 1)
4. browser support. I shouldn't NEED a large library to abstract away the browser just to do simple things like set styles.

Anyone using node.js is just stupid. There is absolutely 0 reason to use javascript for anything unless you *must*. Trying to move it from the only vaguely cross-platform browser language to some sort of actual runtime? Fuck that. Node.js is a warning flag that you've already made bad decisions.

Re:Stop with JavaScript

[vux984]

Work arounds to flaws in the language do not make it a better language.

It should be clear from the way it's used

Except when it isn't.

or by the documentation (if it exists)

You know it won't.

This is true of not only Javascript, but every dynamic language.

JavaScript is worse than others. In part because its used by some of the lowest common denenominator programmers. "script kids who copy-pasta shit together".

You don't give people with the least discipline or skill at programming a language that has the least rules. Yes, it makes programming something that "works" easier. But it does so by making the programs themselves unmaintainable garbage.

Its not a bad language per se, but its a terrible language for the role it gained dominance in.

Re:Stop with JavaScript

[Anonymous Coward]

No, we shouldn't build applications in browsers in the first place.

You're right. Everything would be so much simpler if we all just downloaded Win32 fat clients anytime we wanted to have any sort of interactive content on the Internet.

No more browser headaches (everything would look and work the same on every Windows PC!) and no more security vulnerabilities (If the exe was compromised, Norton would take care of it!)

Re:Stop with JavaScript

[i kan reed]

Yes, okay, we can worry about that couple percentage of traffic some other time.

Re:Stop with JavaScript

[Anonymous Coward]

"use strict"

Re:Stop with JavaScript

[Anonymous Coward]

You mean like the one you are currently using? Idiot.

Re:Stop with JavaScript

[Anonymous Coward]

Not OP, but here are some of the reasons I dislike JS:

1. Dynamic type system
Yeah I know, not very original, but that doesn't stop it from being annoying as fuck when you're used to strong, static typing. This one point can't really be emphasised enough, because it leads to a tonne of secondary issues that are all rooted in this.

2. Bizarre implicit type coercions
Somewhat mollified by ===, but it's definitely a wart.

3. Unintuitive scoping rules
E.g., vars are lifted to the top of the scope, which is NOT necessarily the closest opening brace. Yes, I understand exactly why and how it works, but that doesn't stop it from being illogical and annoying.

4. Variable shadowing can lead to very subtle errors that are hard to find

5. Hell, even misspelling a variable can cause strange and difficult to find errors--especially in combination with the scoping rules and/or shadowing

6. No useful module system
Well, not in browsers at least, though I suppose several other js use cases actually fix this.

7. Slow
Maybe not compared to other interpreted languages, but certainly compared to compiled ones. I'll concede that this is not an issue in many cases, but definitely not all.

Re:Stop with JavaScript

[Anonymous Coward]

It's not that Web-based applications are necessarily a bad idea, it's that the browser was never meant as an application platform - it was conceived for browsing content. As a result, all Web applications suffer from the "every-problem-is-a-nail" issue.

If we backed off the HTML-CSS-JavaScript approach and really re-thought the idea of serving applications over the Web, I'm sure we could come up with something better. Something solid, universal, and secure. But that horse left the barn long ago.

Re:Stop with JavaScript

[Tablizer]

JavaScript crap; it's a terrible language, a terrible platform for applications

I disagree in a general sense. It's fine as a small-scale client-side glue and simple event-handling language. However, it's ill-suited to build entire GUI engine or OS-like contraptions out of. "Static" languages are better for such a thing, and probably such engines should be built into browsers instead of downloaded each time, or perhaps an open-source Flash-like plug-in.

Don't use a screwdriver as a hammer and don't use a hammer as a screwdriver.

JavaScript is not evil, it's just working in the wrong building.

Re:Stop with JavaScript

[Anonymous Coward]

I've given it a try. Read all the usual huff and puff about "the good parts" and all that. Worked with it daily for a few years.

Nope, still don't like it as a language. I mean, I suppose it's not horrible when your'e setting up something relatively small, but when that's the best I can say about it... Well, yeah.

It's also quite telling that none of the languages you compare it to are particularly elegant or nice to work with.

Re:Stop with JavaScript

[Anonymous Coward]

Can only speak for myself, but my problems with it have nothing to do with the things you mention. For example, regarding (1), I rather dislike classical class/inheritance systems, so that can't possibly be part of why I dislike js.

I guess my major gripe is with the dynamic typing and all the silliness that derive from it, but I find a lot of other issues too. You're definitely correct when you say other languages have warts too though. Damn, don't think I'll ever find a language I truly like (though e.g. Haskell is dangersously close to something not entirely horrible).

Re:Stop with JavaScript

[shutdown -p now]

I have to note that there is a fairly big difference between the broad JS community, and the much narrower and more elitist Node.js community.

Re:Stop with JavaScript

[Anonymous Coward]

I use javascript on the server because its what I can use in the browser too. A lot less headache.

Re:Stop with JavaScript

[Anonymous Coward]

Don't use IE6 then. We didn't have webgl in 1993, a modern computer with webgl sent back in time would revolutionize personal computing.

Re:Stop with JavaScript

[Anonymous Coward]

You fail it. Web traffic is typically 20%-30% of all Internet traffic.

Kan u reed this study?

http://www.ipoque.com/sites/default/files/mediafiles/documents/internet-study-2008-2009.pdf

Re:Stop with JavaScript

[narcc]

That would have been really funny 10 years ago.

Re:Stop with JavaScript

[clockwise_music]

1. Being dynamic

LOL.

Re:Stop with JavaScript

[Anonymous Coward]

Careful that you don't slip and fall, with your programming paradigm shifting under your feet like that...

Re:Stop with JavaScript

[Anonymous Coward]

Why? Seriously.. Why? I love programming in Javascript. Server side JS is fun. I do SNMP code in JS for polling 1000+ machines from an older Mac mini and it works beautifully. It syncs with a Windows server machine also running nodejs. I was an assembly language programmer back in the day. Pick whatever you want to program in. Go make your own nodePython or nodeLisp. Native client might be good but its not cross browser/platform yet.

Re:Stop with JavaScript

[brantondaveperson]

I love this kind of slashdot comment. If someone on slashdot hates it, it must be good.

Re:Stop with JavaScript

[Anonymous Coward]

How about Ceylon?

asm.js isn't too bad.

Re:Stop with JavaScript

[sgt scrub]

I agree. When I set out to replace all of my XUL code I eventually came to the realization that I should start with everything new. Everything I've used Java for has had to be recoded several times because of changes, and vulnerabilities, in the JVM. Using pure javascript and XML/SVG was close and with the exception of javascript is where I would like to be. However, there are some things that need heavy lifting. LLVM provides a way to work like you to in the world of compiled software, eg write ASM modules that you call in C/C++ functs to increase speed. I've seen attempts to do it with JVM but man where they nasty ugly and difficult, and that is a comparison to MASM which IMHO says a lot.

Re:Stop with JavaScript

[Anonymous Coward]

Now cite specific examples!

Re:Stop with JavaScript

[Anonymous Coward]

Yes, exactly like Slashcode. It's crap... and the effort required to make it work decently would probably be 100x what would be required for a desktop app equivalent.

Re:Stop with JavaScript

[CaseOfThaMondays]

And 10 years ago is what a lot of Slashdot users seem to be stuck in for this thread. I bet none of them have used node and know what additions it brings to regular JS or even looked at code for it. Node JS is server side and can power entire applications that never care about browser version so why is that relevant? I think most this thread is made of people who think javascript is like the IE 6 days and have no idea how to write proper JS.

Re:Stop with JavaScript

[Pherdnut]

It doesn't matter what the language was. Lack of proper support for the DOM standard on IE's part was the problem, not JavaScript. The ECMA spec has actually been very evenly supported since IE5. Always behind on the latest of course but at least we didn't have to polyfill native language methods in to replace stupid proprietary MS shenanigans for the core language.

But the last version of Netscape Navigator was closer to full compliance with CSS2 and the DOM specs than IE8 was. It took those assholes 10 !@#$ing years to add table-display properties. We've been normalizing the entire event system for IE's sake for a decade too until IE9 came out.

All of this by the way is why JS ended up reigning supreme on the client-side web. Nothing in popular use normalizes or handles UI concerns as well as JS does.

Re:Stop with JavaScript

[Pherdnut]

Oh, FFS, stop crying and learn how to take responsibility for flow of data. If Java and C# devs at the median level knew the first thing about OOP vs. procedural they wouldn't piss their pants every time they saw a dynamically typed scripting language. I moved from client-side work to becoming more of a generalist and I am completely blown away by how moronic the vast majority of server-side code I've been exposed to is. Absurdly deep inheritance schemes. Getters/setters everywhere. Design patterns that make no sense in the context they've been placed in. How the hell is OOP any different from crap-procedural code when you have 25 methods from 25 different classes and objects all mutating the same data? It's just function spaghetti with redundant class syntax.

Type systems are about design tradeoffs (performance and compiler debug convenience vs. flexibity), not whether the language is closer to the one-true-way to do it right. Anybody who believes static types makes their code more robust is lying to themselves. If static typing protects you from anything it's from learning how not to write illegible, unmaintainable shit code that can only be tended to by using IDE crutches to work stupid faster.

In C/C++ I wouldn't have it any other way than static. When I'm writing UI and higher-level architecture, I'll take my variable length args, first-class functions, closures, extreme object mutability (but still not lacking for encapsulation), because when you actually have a little bit of discipline and attention to detail, you can get a lot more done with a lot less code and that is always easier to maintain, reuse and modify in the long haul.

Re:Stop with JavaScript

[Pherdnut]

Strict mode solves the implicit global issue. 'use strict;' at the top of the file isn't what I'd call a particularly painful workaround but I can't say I ran into a lot of implicit globals back when we just avoided them out of convention. By 'we' I mean professional developers who take the language seriously. Not like dynamic drive or some web designer just plugging in the jqueries for some disposable throwaway web app at an interactive agency.

On the type thing, if you mean, with code, there's typeof. If you get 'object' you can hit it with .constructor.name, which would be useless if it had an anonymous function as a constructor but then why would you? That would be stupid and worthy of shaming the team member responsible.

If you mean just reading the code, it's a silly gripe unless you're in the habit of using var names that are meaningless to anyone but yourself but even then it doesn't take long to see what's expected of a var when there's a lot less code in play in the first place due the fact that it's not statically typed.

Re:Stop with JavaScript

[Pherdnut]

I beg to differ. I've ran into people who've been working with Java and C# for years who haven't learned a damned thing about the craft of writing decent code since leaving school. The protectionist paradigm might make it easier for them to produce working apps but it doesn't make their shite-code any more maintainable in the long haul. In JS, it doesn't take long to realize you're going to need to do better than spraying jQuery at every problem when you run into something like a SAAS app that has a lot of complexity and needs to be maintained and modified over time.

For one, you definitely learn to appreciate the value of encapsulation better than devs who just auto-attach getters/setters to absolutely every property, completely nullifying one of the most critically useful aspects of OOP or drop interfaces on every single class because they know test-first TDD is the only way they can feel confident their shit-architecture won't go to pieces on them at any given moment.

And I'm sorry but what language doesn't have lowest-common denominator programmers. I've seen offshored Java code that looked something like this:

someObject.doSomething(i);
i++;
someObject.doSomething(i);
i++;
someObject.doSomething(i);
i++; //repeat 16 more times

I've never seen a web designer working on a disposable throwaway app for some interactive or ad agency do something that lame. If anything, the worst JS I've ever seen has tended to be authored by people from stricter protectionist paradigms who have never learned to write code that was legible without the aid of IDE crutches. Not that there's anything wrong with IDEs when you don't let them get in the way of having a clue. I just think people should start with languages like C and JS via text editor before they're allowed to touch an IDE.

Re:Stop with JavaScript

[Pherdnut]

Really? Cuz I sure thought Python was in the Ubuntu building.

Re:Stop with JavaScript

[Pherdnut]

What prevents you from writing something large with it?

Re:Stop with JavaScript

[kiddygrinder]

good luck man, maybe if you bitch particularly hard the internet will go backwards 10 years, but i can't really see it

Re:Stop with JavaScript

[Pherdnut]

Given what people were doing with HyperCard in the late '80s and the fact that HTML's predecessors at CERN were called things like scriptGML and GMLguid (not sure if guid relates to unique id or related to gui - but I only see reference to docs for SGMguid), I don't think it totally escaped their notice that there might be other applications of HTML and they added forms in '93 when it was only just starting to hit critical mass in academic circles.

HTML/CSS/JS have nothing to do with the fact that web app security is tricky. That's more to do with the stateless nature of TCP/IP which I assume was conceived as such because it would have been too much work to track state across redundant packets. Serving an app from a server to a client in any context requires not trusting the client and it wasn't any different on the internet before it was confused with the web. The technologies in use on the client-side change nothing in that regard and the onus of security falls on the server to not trust data from a client blindly.

Although we can do things that help in terms of damage control on the client-side like vetting data that comes from the server before injecting it anywhere just in case it's been compromised.

As an approach to creating GUIs for apps, I think the trio was revolutionary and it's no coincidence that CSS-style presentation is emulated in other contexts. Before the DOM era of web development, nobody was building GUIs of equivalent complexity with the speed and flexibility in the face of design changes that a typical web UI dev is expected to.

Re:Stop with JavaScript

[vux984]

I've ran into people who've been working with Java and C# for years who haven't learned a damned thing about the craft of writing decent code since leaving school

At least they went to school. :)

And I'm sorry but what language doesn't have lowest-common denominator programmers.

That's not the point. Javascript however was picked up by non-programmers. C is a terrible language for non-programmers too, but there aren't literally millions of people who don't know the first thing about programming writing C. You have that with Javascript, not because their is anything particularly intrinsicly good about javascript, but because javascript is what's embedded in the browser, and they want to manipulate the browser.

If the browser had embedded Pascal, we'd have a bunch of non-programmers writing shitty Pascal, but at least with Pascal there's less to hang yourself with.

. I just think people should start with languages like C and JS via text editor before they're allowed to touch an IDE.

Actual programmers? In an academic environment? Absolutely.

Self taught web "programmers" and "designers"? Never going to happen. So they should have simpler tools.

Re:Stop with JavaScript

[Pherdnut]

Browsers have been supporting JavaScript the language quite evenly since IE5, although IE naturally drags behind on having more recent version features. You're getting JS twisted with IE refusing to correct their proprietary DOM methods, the DOM being a language independent API for interacting with HTML and CSS.

You have to actually know a language and its execution environment(s) to optimize for it.

Given type systems are a design tradeoff, not a valid criticism.

I'd like to see you try to write something in a static typed language that's smaller than popular JS approaches to normalizing the DOM API.

Re:Stop with JavaScript

[Pherdnut]

1. Learn how to write maintainable code in a dynamic type system and I guarantee it will improve your code quality in static languages. The most common fail I see in Java and C# is a total failure to understand and appreciate how critical encapsulation is to separating OOP languages from procedural.

2. Implicit type coercion allows for a lot of convenient shorthand that's easy to understand and that involves a lot more than just === vs ==. When there's no reason not to go with explicit comparison I favor it but I like having the option a lot.

3. Scope is function-based. 'use strict'; indirectly solves any hoisting problem you would otherwise be unlikely to run into barring really sloppy code. As a legibility practice I typically declare all but counter vars at the top.

4. Yes. As var or property shadowing could in a lot, I dare say most popular languages.

5. See point 4. But also the right text editor or IDE can help you with this.

6. It doesn't even make sense as a criticism of JS in the browser where code comes together via script tags. People use require.js for SPA-style apps which IMO are over-implemented.

7. So as legit of a criticism as say comparing C#, Java, or Python to C, all of which I would say modern browser and JS execution environment JITs are competitive with even before you consider the architecture advantages of being able to do more with less of a mess.

Re:Stop with JavaScript

[Anonymous Coward]

asm.js is fantastic! Anyone who says JavaScript is slow should read about how they ported the Unreal Engine 3 to asm.js and got over 140 fps.

Node.js?! How 'bout C89 support?

[Anonymous Coward]

Unfreaking believable.

Re:Node.js?! How 'bout C89 support?

[Tridus]

But Node.js is the trendy new thing!

Re:Node.js?! How 'bout C89 support?

[bmajik]

Visual Studio is a huge organization, and only a subset of people work on the C compiler.

The people behind VS C89 work and Node.js are entirely different people, with different funding and business justifications.

I work on VS LightSwitch. I never talk to the C compiler team about anything.

Re:Node.js?! How 'bout C89 support?

[kthreadd]

C89 doesn't web scale.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

There are many teams in Microsoft. The one that does Node.js (which is also the one that did Python) is different from the one that does Visual C++.

That said, so far as I know, Visual C++ is C89-conformant. Did you mean C99? If so, they're working on it - in fact, VS 2013 includes most of C99 standard library, as well as _Bool, compound literals and designated initializers.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

Neither does javascript. The language has literally zero support for multi-threading or other parallel processing.

Re:Node.js?! How 'bout C89 support?

[khr]

How 'bout C89 support?

For that matter, how about C64 support? And small enough to fit on floppy disks...

Re:Node.js?! How 'bout C89 support?

[jones_supa]

What? There still is an C compiler team for VS? I thought they mostly just dragged the same C compiling engine from version to version, possibly just doing minor adaptations to keep it working with the newest VS.

Re:Node.js?! How 'bout C89 support?

[jones_supa]

By the way Wikipedia says that VS is C90 compliant (woohoo, what an improvement...). Anyway, if someone believes that is wrong, feel free to fix the article. :)

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

It was in 2008. Not anymore. NodeJs is an old fart right now. Nobody really cares about it except the slow hipsters.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

C90 is the same thing as C89 (it was originally ANSI C89, later adopted as ISO C90).

Re:Node.js?! How 'bout C89 support?

[bmajik]

http://blogs.msdn.com/b/vcblog/

Re:Node.js?! How 'bout C89 support?

[jones_supa]

Oh, okay.

Re:Node.js?! How 'bout C89 support?

[phantomfive]

Yeah that's what I came here to say. There are some parts of c99 that would take a week or so to implement, and yet they still haven't done them......

Re:Node.js?! How 'bout C89 support?

[jomama717]

No multi-threading is kind of the point with nodeJS. It's a different approach than your normal "servlet" where you're firing up new threads for every request and sharing a pool of database connections between them. In this model you run a nodeJS listener and it uses a simple event loop, just like in the browser. If you want to scale you spin up 50 more node instances and slap them behind a load balancing proxy. They are all typically hitting a highly scalable nosql datasource on the backend, which can also easily spin up another 50 instances if needed.

I've dabbled, it is definitely fun for little side projects but I haven't tried to do anything major league with it - in any case, don't knock anything until you try it. For giggles try creating a large searchable data set using elasticsearch and nodejs running behind apache proxies, one hour into it when you have a working site you'll see the appeal.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

Can you give an example of something in C99 that is not in VS 2013, and that would take a week or so to implement?

The only things that aren't there that I can think of off the top of my head are VLAs and "restricted", and both are fairly major features (well, unless you are okay with a no-op "restricted", but you can have that already by #defining it to expand to a blank string).

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

I did this over a decade and a half ago with I/O completion ports. kqueue and epoll offer the same thing. People simply don't bother to learn the proper techniques when they first come, and then instead latch on to whatever trendy reinvention of the wheel that gets enough buzz.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

Yeah, but the callback model is incredibly ugly. In Lua I can do precisely what Node.js does--juggle thousands of simultaneous connections--but at least be able use a normal flow of control via the use of coroutines.

See, for example, http://www.25thandclement.com/~william/projects/cqueues.html

Which also supports spinning up kernel threads in the same process, so that you can scale to multiple CPUs on a single server without having to run multiple different instances.

Re:Node.js?! How 'bout C89 support?

[jomama717]

Interesting - it has occurred to me that a lot of these "new" fangled frameworks and such really are just a return to concepts and practices from the past - didn't know what the historic analog of this nodeJS (and the like) stuff was. Thanks.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

Do they have stdint.h now? Or are you still supposed to ifdef on MSVC and typedef unsigned __int32 to uint32_t?

How about conforming to C89's strict aliasing rules? Restricted pointers? They have that under __restrict, but again, you have to #define if you want to use restrict with MSVC code.

Re:Node.js?! How 'bout C89 support?

[jomama717]

I'll check that out. Agreed that shitloads of nested anonymous handler functions is ugly as hell... and seems to be were most complex javascript leads. I'm not a huge proponent of node or anything, but I do think it has its uses.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

They are wrong.
The following SHOULD be undefined behavior according to c89's strict aliasing rules

float f=1;
long L = *((long*)&float);
L|=0x80000000;
assert( f == -1);

Strict aliasing allows the compiler to assume that L and f are not using the same memory location, and thus reorder/inline/whatever the code. It allows C to access data as fast as fortran does, but they don't implement it because it would break code like the above.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

Note that GP asked about missing C99 feature that "would take a week or so to implement". Having said that:

Do they have stdint.h now?

It has been there since VS 2010.

How about conforming to C89's strict aliasing rules?

A compiler doesn't need to do anything special to conform to those rules, so this has always been the case. Conformant programs have to be written carefully so as not to trip up an optimizer that relies on strict aliasing, though. I have to admit that I don't know whether VC++ optimizer does use the opportunities presented by strict aliasing, like g++.

Restricted pointers? They have that under __restrict, but again, you have to #define if you want to use restrict with MSVC code.

There's no support for "restrict" yet, and __restrict is subtly different in semantics.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

Yeah, but the callback model is incredibly ugly. In Lua I can do precisely what Node.js does--juggle thousands of simultaneous connections--but at least be able use a normal flow of control via the use of coroutines.

In C#, this was solved with async/await, which, like Lua coroutines and Python yield, let you basically write the code as sequential, sprinkling "await" in points where you want asynchrony. Since then, a similar thing has been proposed for the inclusion in C++17, and there is another proposal for EcmaScript 6 - support for which has already been added to Node.js.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

Designated initializers? It's hard to say without being able to look at the source code, but designated initializers should be fairly pretty easy, as it only involves the parser. They allow you to initialize a structure or union by name (or array by index), rather having to use the exact order of layout.

Compound literals? That's conceptually very simple, although it involves both changing the parser as well as some simple AST manipulation work.

Those are my two favorite features of C99, and I use them all the time.

The problem with compound literals, though, are they directly conflict with semantics for a similar-looking C++ construct, list-initialized temporaries. Whereas compound literals have block-scoped lifetimes, C++'s temporaries are scoped to the expression. And because Microsoft is married to C++, now, I could understand them having problems supporting a construct in C that behaves (in very risky ways) different than in C++. This already has caused problems in GCC--http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220

Just more proof that C and C++ have become incompatible languages with significant differences. It always irks me when people write C/C++. *sigh*

OTOH, if Microsoft accepted that C and C++ are different languages, rather than sticking to the old idea that C is a subset, then it would probably be easier for it to begin implementing newer C standards.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

Designated initializers?

They're there in VS 2013 already.

Compound literals?

Also in VS 2013.

_Bool / stdbool.h as well, and most C99 standard headers except for tgmath.h are there as well.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

Those are all substantially different than coroutines. Coroutines allow you to _invert_ the producer/consumer relationship between two blocks of code. That you can abuse them to simulate cooperative multi-threading, or enhance pre-emptive multi-threading, is merely evidence of their abstractive power. But they allow you to do so much more.

Python's yield is just.. horrible. It's a crappy compromise, because real coroutine support would require massive changes to their VM. It's the same reason JavaScript has eschewed coroutines in favor of this clunky yield interface. Yield in Python and in JavaScript is a hack which tells the compiler that the next function invocation will require a separate stack frame which can be paused. But it's conceptually ugly as hell because you have to make explicit use of these directives part of your exported API.

Whereas with coroutines all the rest of your code can remain oblivious, whether you're simulating threading, or you're wrapping a callback-oriented scheme so it returns a value rather than forwards one.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

You can also do exactly what Node does in Lua using the actual underlying C library that Node uses with this (for those who prefer callbacks to coroutines but still prefer Lua).

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

It is undefined behavior in all conformant C89 compilers, including VC. Undefined behavior, by defnition, is any kind of behavior, including "it works as I expected it to".

Re:Node.js?! How 'bout C89 support?

[phantomfive]

Variables not being restricted to the first line of a function. [EDIT]: looks like this is fixed in VS 2013. Thanks, Microsoft!

Also, array sizes defined at runtime is theoretically easy, but depending on their codebase (ie, if they are crappy compiler writers that depended on things they shouldn't have), I could see it being hard.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

Also, array sizes defined at runtime is theoretically easy

Dynamically stack-allocating arrays is indeed easy, which is why this feature is also being standardized in C++14. The problem with C99 VLAs is that they are far more than that - you also have things like VLA typedefs (which should remember the size at the point of the typedef, even if the expression that defined it changes later), or parameter arrays where their size is specified by another parameter. Also, the abomination that is dynamic sizeof.

but depending on their codebase (ie, if they are crappy compiler writers that depended on things they shouldn't have), I could see it being hard.

The compiler itself is really ancient. Consider this: gcc 1.0 was released in 1987; Microsoft C was released in 1983, and that was built on top of an even older third-party codebase that was purchased back then. It probably changed a lot since then, like gcc did, but all legacy codebases of that size acquire a lot of legacy cruft (hence why Apple decided to stop mucking around with gcc and just do Clang from scratch). I don't know much about current VC code, but one piece of information that the team has shared publicly is that the front-end doesn't actually operate on an AST, but is rather a multipass process-as-you-parse thing, which makes a great many modern C++ features like constexpr very costly to implement.

Re:Node.js?! How 'bout C89 support?

[phantomfive]

The compiler itself is really ancient. Consider this: gcc 1.0 was released in 1987; Microsoft C was released in 1983, and that was built on top of an even older third-party codebase that was purchased back then. It probably changed a lot since then, like gcc did, but all legacy codebases of that size acquire a lot of legacy cruft (hence why Apple decided to stop mucking around with gcc and just do Clang from scratch). I don't know much about current VC code, but one piece of information that the team has shared publicly is that the front-end doesn't actually operate on an AST, but is rather a multipass process-as-you-parse thing, which makes a great many modern C++ features like constexpr very costly to implement.

ok, that's pretty interesting actually.

Re:Node.js?! How 'bout C89 support?

[Blakey Rat]

You realize that "undefined" doesn't mean "it crashes the app" or even "it doesn't do what the author expected"?

It just means undefined. That's anything from, "it works exactly like the author intended" to "it causes the soft soap dispenser in the ISS to squirt soap on the spacesuits." It's undefined; it could do literally anything or nothing at all.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

And small enough to fit on floppy disks...

I believe that was implemented somewhere around Visual C++ 1.0, but has somehow regressed since then. Probably because they didn't have any unit tests back then.

Re:Node.js?! How 'bout C89 support?

[Anonymous Coward]

Wow! That's awesome. I might actually try to port some of my open source projects to Visual Studio, finally. Theoretically they should just compile, plus or minus some unintentional portability bugs.

What caused this about face? For years Microsoft management was adamant that they had no intention of ever bothering to life a finger to support C99 (and later C11), whether fully or partially.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

Ironically enough, it was the desire to ease porting of some popular open source libraries that have gotten to rely on C99 features. I don't know the full list, but the one that was specifically named on VC blog (and that should now compile with no modifications) is ffmpeg.

Re:Node.js?! How 'bout C89 support?

[shutdown -p now]

If I understand you right, the problem with transparent coroutines as you describe them is that they require pervasive support from every single language you have anywhere on your call stack to work. It's all well and good if everything is in your language, but what if you call into a C library which then calls you back? Given the recent trend towards asynchrony in general, this is a very common pattern, and in some cases simply unavoidable (e.g. on WinRT, many core APIs are async only, like sockets).

The nice thing with yield/await and explicit continuations is precisely that it doesn't require any mucking around with how the regular stack works, and so it's compatible with any promise-based or callback-based scheme across any two languages.

If I did not understand correctly, then can you elaborate on the difference between what you want, and yield/await?

Re:Node.js?! How 'bout C89 support?

[Pherdnut]

I think the trick is to write something that helps you build objects with methods that fire off events on themselves so internals can listen and respond and outside observers can too. Gives you a much more pleasant/legible interface to work with and the debug/testing/decoupling wins are huge if you're also passing data in event objects.

JavaScript, its better than a kick in the head.

[TiggertheMad]

If you know of a better client side web scripting language that has wide spread browser support, we are listening.

nothing? Yeah, I thought so....

Re:JavaScript, its better than a kick in the head.

[Tridus]

Not really sure what that has to do with Node.js applications deployed to something like Azure. How many browsers are going to be running that?

I know I can think of things I'd rather do than inflict Javascript on myself in more places than I have to.

Re:JavaScript, its better than a kick in the head.

[Dahamma]

ActionScript! ;)

Re:JavaScript, its better than a kick in the head.

[devent]

If the W3C would make a byte code standard to access the DOM then nobody would use JavaScript and rather port any other language to use the byte code. Much like for the JavaVM there are numerous languages available (about 25 languages), for example C, Python, Ruby, and new languages like Scala, Groovy, (and about 30 other languages). The JavaScript code is compiled and re-arranged for faster execution to a byte code language that is run under a Virtual Machine anyway.

The question of whether I know a better client side web language is moot because there ain't no choice. Other then of course plug-ins or add-ons to the browser. It's like asking is there any better gaming operation system then Windows... (at least I can install Linux and run some Linux games that are better then Windows games).

Re:JavaScript, its better than a kick in the head.

[NoImNotNineVolt]

Server side scripting.

There was a day when web servers were expected to do the heavy lifting instead of offloading everything to client browsers. And somehow, they were able to afford this kind of outrageous web server horsepower without inundating visitors with advertising.

We've come a long way.

Re:JavaScript, its better than a kick in the head.

[ADRA]

Who said anything about client-side? Nod.js is server side JS, which IMHO is pretty dumb unless you're doing it for user front facing DSL's (which its awesome for).

Re:JavaScript, its better than a kick in the head.

[Anonymous Coward]

Well supported in-browser? No, but Lua is a better Javascript than Javascript.

Re:JavaScript, its better than a kick in the head.

[Anonymous Coward]

Or unless you've got one set of individuals for all development, both client and server and can't afford to divide your subject matter experts way of thinking. Because thats what you get with each new framework, methodology, language semantics, etc. Javascript on client, server and if you're lucky, in your database. Holy shit, no data transformations, all I gotta know is one language. Nirvana man.

Re:JavaScript, its better than a kick in the head.

[shutdown -p now]

The cost of round trips between client and server are still way too high for a lot of stuff, especially when you want smooth UI. Remember those horrible forms which reloaded the page (to show a different set of controls) when you changed selection in some combobox?

Re:JavaScript, its better than a kick in the head.

[nschubach]

... Webforms... blech. "Just wrap it in an update panel!"

Re:JavaScript, its better than a kick in the head.

[Pherdnut]

If nobody would use JavaScript given alternatives, then why is it spreading to desktop-os, server-side, and cross-platform mobile apps (to be fair - it's not the only choice I'd make for mobile at this time - canvas support blows and web views are still ragged bleeding edge)? There were other options in the '90s, although IIRC I think you had to download interpreters. And of course Java Applets, VB, Flash, etc... At the end of the day the browser vendors know what every UI dev knows. A primarily LISP/Scheme-inspired language like JS is an excellent design for the task. It's easy for rookies to pick up and start doing basic stuff with it but there's also a powerful language worthy of study there that happens to be a good fit for the roles its had so far if you take it seriously.

What people fail to understand, is that your typical experienced UI dev tends to have had a lot more exposure to other languages than your typical web server-side dev, most of whom can't even be bothered to become functionally literate in HTML beyond basic syntax which they new from XML anyway and often have no idea how CSS works. Those of us moving on to generalist territory aren't just picking Node.js for a lack of basis for comparison or because we're afraid to learn anything other than JS. I was actually a little wary of Node at first until I tried it. I've always enjoyed Python when I needed it for file-system type stuff and I loved Django (but sadly could never find work with anybody who was using it), Ruby wouldn't suck if it had a decent interpreter but I've never understood the excitement over Rails which I find 'meh, C# can be tolerable with MVC but why you would pay for it with so many superior alternatives available is beyon me, every experience I've ever had with Java-only teams or the disaster code they leave behind has been completely miserable (the language is a little crude but usable), and I'm a little too turned off by PHP's lack of consistency in API to take it especially seriously for my own use but I respect a good PHP dev.

I probably like Node as much as I do for reasons typical to JS devs.

* Takes 5 minutes to get it up and running on any platform - no surprise there. We're used to executing code right out of a console or by hitting "refresh" in a browser. Having to fiddle with XML config before you can even compile, servers with really pointless default settings, or a cluster-fucked code base that gets into a fight between Ant, Eclipse AND Maven because some tools wanted every technology they could think of on their resume is not something I would expect to run into with Node.js. You install it on Mac, Windows, Linux, it runs. Anything expecting a great deal more effort than that just to execute code tends to get tossed.

* Async event-driven architecture in a familiar format. All that concurrency stuff everybody gets so excited about is just second nature to anybody who's been handling event driven UI code for years. As are a lot of aspects of functional programming. We're not almost there. We don't need to attend workshops. It's just what we've been doing for years with a language that serves those needs well.

* Whoever's benchmarks you're reading, I think it's safe to say Node's performance is strong at this point. Barring stuff from people who still don't quite get the concept of needing to keep things async with the JavaScript.

* C/C++ bindings - two things JS doesn't have, design for more advanced math handling and performance that absolutely hands-down kicks absolutely everybody's ass, easily glued to. It's a nice tag-team. All the architecture/implementation advantages of an extremely flexible scripting language with C right there to burn through any computationally intensive tasks for a performance advantage or to handle scenarios where static types can be advantageous. JS here and C there will always appeal to me way more than Java or .NET and all the baggage they bring.

* It's straightforward - It's mostly just a C event loop with a not-gargantuan fil

Re:JavaScript, its better than a kick in the head.

[Pherdnut]

Webforms is the anti-christ to any competent web UI developer. All thin-client solutions are. Since the DOM API became reasonably well-supported around 2000, reloading the page to swap static lists for a paired combo box widget was never a competent or necessary thing to do. Loading dynamic data in via ajax moves pretty damn fast nowadays if you keep processing of data to a minimum on the back-end.

Pearls before swine.

[RightSaidFred99]

Kind of pointless to post this here, you'll mostly just get bad jokes from ca. 2002.

Oh, does it have clippy?! (desperate gaze around room to see who's lauging)

Pfft, they'll probably embrace and extinguish it lolzerlolzers haha lolzers!

Oh, where's monkey boy to announce it! Terr heerrrrp!

What about Powershell ?

[slincolne]

Isn't it strange that there is a group within Microsoft that can turn out such great tools for for languages developed outside, but where they are touting Powershell as a strategic tool you are stuck with a toolset that lives back in the 80s ?

Why can't Microsoft put out a Visual Studio plugin for Powershell with full intellisense, breakpointing, inspections, etc. ?

Sad :-(

Re:What about Powershell ?

[shutdown -p now]

Why can't Microsoft put out a Visual Studio plugin for Powershell with full intellisense, breakpointing, inspections, etc. ?

We don't need to - someone else already did that.

Keep in mind that we're a relatively small group - 6 developers/testers (we all do both) and 1 project manager, covering two projects already (PTVS and NTVS). We can only do so much. Then again, that's precisely why the code for both products is open source - so that people can take it and use it as a foundation for similar products for other languages. Here is one more for PHP, for example.

Re:What about Powershell ?

[KingMotley]

I think you are confused. Have you ever taken a powershell script, right click it, and select edit. A full blown IDE comes up. Breakpoints, step tracing, call stack, interactive commands, etc. Yes, it could use a watch window, but there are other tools if you really really want to write some complex powershell scripts that integrates into Visual Studio.

Sort of deserve each other, right?

[Anonymous Coward]

Okay, so if you use a slow scripting language as your web server, you might as well use a slow, bloated IDE to develop it? It's JavaScript - you don't need Visual anything.

And I actually speak from authority on this one - after decades of using Emacs to make web sites, I had a run-in with ASP.NET in Visual Studio, and SUDDENLY I had satori about why most web sites are slow and don't work properly. The horror is beyond words to describe. It's actually designed to be slow! I was amazed by the "postback" stuff. Every time you do something, you take a round-trip to the server.

Re:Sort of deserve each other, right?

[Anonymous Coward]

http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

"As the above tests show, node is fast. Really fast. Much faster than Apache - many more requests per second, higher transfer rate with much smaller number of failed requests at the same time. Really shining.

"Obviously it is more hungry for system's CPU and memory, but this should not be surprising considering its performance.

"What needs to be kept in mind though is that everything really depends on what you want to use Node for. As already said in many places, Node is not something that should replace Apache everywhere."

How to revert the uppercase menus

[jones_supa]

Ok, here's a cool little tip that many will enjoy. A couple of days ago I discovered that there is actually a registry setting to turn off the silly uppercase menus. Enjoy.

While we are at it, can we also have a SuppressDamnSlowStartupAndSluggishUserInterface flag? The other day a teacher of mine intended to open a C file which was part of MicroC/OS-II, into Notepad++. However VS owned the filetype association and the guy was like "aarrrgghhh...how can I make this stop??" when VS fired up and was running that "Loading components..." bar forever and it couldn't be terminated.

Re:How to revert the uppercase menus

[JLennox]

That's like taking a harrier jet to your mailbox and complaining the engines take forever to warm up.

If you want to peek the contents of a text file, open it in a text editor. It'll be a while when using xcode^H^H^H^Heclipse^H^H^H^H^H^Hvisual studio.

Also, SSD.

Re:How to revert the uppercase menus

[shutdown -p now]

VS loads very slow the first time you run it after installing (because it runs first-time initialization code for all packages), and also after installing a new package. But, once primed, it should be pretty fast. Not as fast as Notepad++ or something similarly lightweight, but no more than a few seconds, and certainly no eternal progress bars.

Re:How to revert the uppercase menus

[Anonymous Coward]

> That's like taking a harrier jet to your mailbox and complaining the engines take forever to warm up.

Yeah, but the problem here is that the OS said, "Oh, you're going to the mailbox? Let me warm up the Harrier jet for you," and then didn't let him shut down the engines once he realized he was in the jet...

Re:How to revert the uppercase menus

[Anonymous Coward]

Back when I was at TAFE doing a course in programming, the way the computers were setup, the first time you opened VS after every login was "the first time". Massively annoying because, as what was said above, the file associations for anything code related was set to open in VS and it isn't really reflex to right click to open a file.

Ironically, none of the teachers recommended using VS for any of the work we were doing and, apparently, the only course stream that used VS was the diploma level programming which very few people even made it into (was 2 people in the three years I was there that did the diploma level).

Re:How to revert the uppercase menus

[Pherdnut]

My rule is that if you crash when I type CSS too fast, you have 3 more versions to go before I start taking you seriously again. One more version to go now.

Re:How to revert the uppercase menus

[shutdown -p now]

*shrug* There was pretty much a complete rewrite of everything HTML, CSS and JS related in VS 2012. But, suite yourself.

VS2013

[Cammi]

Now if only Microsoft can provide downloads on MSDN for VS2013 that isn't corrupt ..... might be to much to hope

Not for everyone

[codepigeon]

It looks like this is only supported on VS2012 and VS2013 Premium (and up) editions.

Re:Not for everyone

[shutdown -p now]

That is correct. Please vote for the feature request to provide a version that would run on some free VS edition (Express or Shell). We already have such a thing for Python Tools, but it would require some more effort with NTVS, and it would help a great deal if we can show numbers proving strong community demand for such a thing.

VS doesn't have Intellisense

[sproketboy]

It has retard sense unless you use resharper.

W3C isn't reliable

[globaljustin]

If the W3C would make a byte code standard to access the DOM

I'm not saying they're worthless, far from it, but the W3C has shown themselves incapable of making a proper standard.

The HTML5 debacle and the WHATWG formation sort of made it official. The W3C buys into the abstraction layer nonsense and perpetuates it to the detriment of our industry. Remember: Web 2.0 was fully embraced by W3C.

HTML5 & CSS3 transforms & canvas elements are still not being fully utilized. There are many simple HTML5/CSS3 only games & animated interactive widgets around the web. That's just the beginning of what they are capable of...

The second part of the equation is to rethink what 'website content' means....most of javascript & flash is for non-task events...things that the user doesn't need in order to do the task...ex: watch a youtube video or posting to a social media site....do we need javascript or flash for that whole interchange to happen?

LOL, WUT?

[KlomDark]

OK, I might get fried for this, but I'm a daily VS2012 V#/MVC 4 Mobile web programmer and I have no clue what Node.js is all about or why they are excited about it.

I looked at the Nodejs.org site and have not a clue WTF it's supposed to do. Anyone got a translation of what in the hell their buzzspeak means?

"Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."

What does it do that jQuery's async AJAX handlers do not? // Fully duh about it... Clue me please.

Re:LOL, WUT?

[KlomDark]

V# should have been C#

Re:LOL, WUT?

[shutdown -p now]

jQuery is about JavaScript running on the server side - in the browser. Node.js is about JavaScript running on the server - instead of C#/ASP.NET. The "event-driven, non-blocking I/O model" basically means that all APIs that are normally blocking are instead done asynchronously, with you having to provide a completion callback every time you call one - so threads are never blocked waiting for I/O. For a C# developer, this is basically very similar to all the new stuff about System.Threading.Tasks and async/await in .NET 4 and 4.5, and specifically support for the latter in ASP.NET.

Re:LOL, WUT?

[KlomDark]

Uh, why would one want to run JavaScript on the server? Makes perfect sense in the browser for cross-browser compatibility, but on the server? Why would anyone but JavaScript purists want to do that?

In the .NET world it is C# on the server, JavaScript on the client, AJAX tying the two together - asynchronously.

This is as dumb as using the code-first model for Entity Framework - Just a crutch for people who don't want to learn what they need to learn.

Re:LOL, WUT?

[shutdown -p now]

Not all people live in a .NET world.

And, well, why not?

Re:LOL, WUT?

[narcc]

jQuery is a shitty Javascript library that, on the client side, slows down websites, increases development time, and generally makes cross-browser scripting impossible. It's worse than useless.

Node.js is essentially Javascript without the browser, plus a few extras. There are various uses for it. It can be handy, but it's far from the panacea it's made out to be by its proponents.

They're quite different. The only similarity I can come up with is that both are over-hyped.

Re:LOL, WUT?

[CaseOfThaMondays]

"increases development time, and generally makes cross-browser scripting impossible. " WTF are you talking about!? jQuery SOLVES those problems, and does it very well. I haven't have a single cross-browser problem in jQuery in years, and it is always quicker than JS from scratch on large projects.

Re:LOL, WUT?

[narcc]

Nonsense. jQuery even introduces cross-browser issues!

The unstable API virtually guarantees you'll have maintenance issues in the future -- with the library itself offering solutions to help you mix multiple versions! Yeah, even if I believed that you save any amount of development time using jQuery, which I do not, you'll quickly loose it all in maintenance costs.

Oh, yes, and it's written by a group of completely incompetent people. Having looked at the code, I'm not convinced Resig understand the basics of the language. No big surprise, as his books are riddled with obvious errors.

Take a look at the code yourself. Tell me you wouldn't fire anyone on your team that produced something like it. It's a disgusting mess. If I were Resig, I'd be ashamed.

Re:LOL, WUT?

[Anonymous Coward]

You're wasting your time. Narcc is a notorious jQuery-hater around here. He would rather roll his own solutions with plain JS.

Everyone's entitled to his opinion, of course...

Re:LOL, WUT?

[Pherdnut]

You're either trolling or talking out of your ass.

jQuery's selector engine actually does a lot of selections faster than the native querySelector API does, owing to the fact that so far, browsers are just plugging into what they use for actual CSS which reads from right to left, which makes it impossible to take advantage of IDs and other selectors to isolate the query to a smaller subset. Also misuse by the DOM ignorant. No native methods for getElementsByClassName before IE8 so $('.someClass') would hit every single element in the document and check its class attribute if you didn't narrow down first.

The only thing that ever slowed it down in the past other than not having the best selector engine available, was the internals being a bit function-call-heavy. This is trivial, possibly actually perf-enhancing in modern JavaScript JITs.

jQ's utility as a DOM normalization tool is actually starting to become questionable, especially if you've dropped IE8 support but it's still very useful for drastically reducing kruft in the DOM API so I'm not sure where you're getting that it's somehow become less adept at cross-browser handling when IE itself is finally supporting DOM spec methods that it's been ignoring for a decade. I've also recently used 1.8 in a Phonegap app supporting iOS and Android and didn't run into x-browser issues relating directly to jQuery.

As far as quality of code, I haven't looked under the hood of recent versions as much but it's pretty much a textbook on how to write something that finds or builds objects of a certain type and then wraps them in method/object chaining adapter/decorator objects for normalizing an API that varies across platforms. The vast majority of "internal" methods and properties are actually trapped via function closure which drastically reduces the memory footprints of JQ objects while still effectively achieving encapsulation where it matters. Not a pattern I duplicate often but it's pretty damn useful when use cases come up.

I'm not aware of any severe performance issues with JQ in browsers or mobile at this time. IIRC it did have issues in Android way back.

I do agree that the constant edits on the API are getting beyond old but it's not like you have to update to the latest versions every time a new one comes out. The general trend is in browsers getting better at following spec and only varying in new stuff they add by way of experimenting. IE>=9 will tend to be behind the latest but they've at least ditched all their old proprietary methods for the DOM API. So it's not like there anything forcing you to upgrade for newer browsers.

If you want to rant about jQuery, rant about the quality of the modules written for it. Even the official subset libraries have been pretty weak. That and the buried or useless errors. But as someone who's equally comfortable working the raw DOM and selector APIs and who's been using jQuery since a year-long gig at a major ecommerce company where 200 idiot offshore Java devs were basically jumping up and down on the HTML without source control, and the team of 30 UI devs I was on basically spent half the week putting humpty back together again (supporting IE6 at the time), jQuery's had a nice run and it's not completely useless just yet but I'm about ready to write my own lighter-weight version of it.

It also does what I like best in a tool. It enables rapid DIY and it steps out of your way any time you want it to.

Re:LOL, WUT?

[Pherdnut]

JS's single-threaded blocking model in conjunction with an event loop running in C is the design win.

In a typical Node scenario you might tell something to write to a file and provide a callback when its finished. The handler is registered and the file I/O is handled in a multi-threaded context. When the first file operation is complete, that JavaScript handler gets called back in single-threaded land where we can be assured nothing else will happen in JS-land until the callback is done. The second I/O operation keeps going and may even complete which would put its callback in line to fire at the next available window.

All thread-handling is essentially buried and there's a clean no-interference separation of application logic from File I/O and other lower-level tasks. There's no risk of two JS operations trying to write to the same value at the same time in JavaScript-land since JS functions can only execute one at a time and on the flip-side nothing in the file I/O operations will hold up app logic in JavaScript-land until callbacks fire or be blocked by anything happening in the JS themselves. You'll never have to lock a thread in Node.js or write a queue for the purpose of making sure two things don't try to hit the same value simultaneously.

The caveat is that you have to think about what's going and have the good judgment to not do things like write your high-resolution calculation-intensive photo processing in JavaScript. That's handled by writing it in C/C++ and then binding to a JS call.

I'm not completely hopeless at other languages. I spent much of the last year debugging and tweaking Java and C# and while I have no idea why you'd spend the money with so many good open source solutions available .NET MVC is an entirely tolerable solution compared to most things Java and .NET. I might even prefer it over Rails if I wasn't paying for it. But with Node I can have the framework up and running and be ready to start writing and executing code in 5-10 minutes on any OS. If somebody waved a wand and it suddenly became Scala or Python or any other dynamic language, I would still prefer it over MVC for never getting in my way by trying to "help" me, being stupid painless to implement, and for allowing me to do a lot more with a lot less code. The JavaScript is just gravy for me.

Re:LOL, WUT?

[Pherdnut]

Well, to be fair, it is bordering on useless at this point. IE>=9 support makes the vast majority of x-browser issues go away and even IE8 has query selectors. All that's left is the event system which does more than most people realize it can do and the convenient auto-looping of a lot of methods.

Trying to find a good analogy...

[Pherdnut]

A Node.js app written with Visual Studio...

Knitting a fine silk scarf with a randomly misfiring rusty bazooka?

Sculpting a statue by ramming a block of marble with a Pinto?

How else do I express writing JavaScript in a tool written by the people who have made UI work a pain in all of our asses for the entire decade leading up to IE9 with a giant bloated IDE that has crashed on me on multiple occasions because I typed too fast, for a platform that is far more powerful in its elegant simplicity than anything Microsoft in all its quantity of bullet point evaluating design-by-committee glory will ever be able to offer.