Are there performance, scalability, or reliability disadvantages to Classic ASP/JScript?

Question

Writing Classic ASP code in JScript has a lot going for it: more humane syntax, a sane object system, programmer familiarity, and a general lack of annoyances. You can even mix legacy VBScript and new JScript code in your existing Classic ASP apps if you're mindful of a few quirks.

I've been thinking that there's got to be some reason that it isn't used more. Is it just momentum and the lack of documentation? Or are there good reasons from a performance, scalability, or reliability point-of-view to stick with VBScript?

N.B.: I'm only interested in comparing VBScript and JScript. I know that Classic ASP is a pile in general, but I have no choice here.

Answer 1

I vote in favor of JScript. I did some research a few years ago and found no real performance impact to using one or the other. It's true that many examples and documentation (all of which will be old) will use VBScript, but these are easy to translate if you are moderately familiar with JScript.

JScript is Microsoft's flavor of ECMAScript, or "JavaScript".

• JavaScript runs on Windows, Linux and Mac (and also iPhone, Android, Windows Phone and even .NET and Java via compiler/interpreter projects). VBScript runs only on Windows, and even then only has two major interpreters that I know of: Classic ASP and Windows Scripting Host and both are deprecated.
• JavaScript is an open standard, VBScript is a proprietary language ( http://en.wikipedia.org/wiki/ECMAScript )
• JavaScript is included by default on every Windows operating system after '95
• Microsoft, Google, Mozilla and more are actively developing ways to make JavaScript run faster in other environments, like the browser. There is no such development for VBScript, which is pretty much dead end.
• JavaScript is an object/prototype language that supports OOP (including inheritance, polymorphism and encapsulation through closures). Try doing any of this in VBScript.

http://javascript.crockford.com/prototypal.html

http://ejohn.org/blog/simple-javascript-inheritance/

http://w3mentor.com/learn/javascript-examples/object-oriented-javascript/example-of-encapsulation-using-javascript/

• Both VBScript and JScript can use built-in tools to parse XML, but JScript wins with JSON
• JScript in WSH can do anything VBScript can do with one or two very rare exceptions. In these RARE cases, you can call out to VBScript using the scripting engine ActiveXObject.
• JScript has the far superior/modern try {} catch {} which even VB.NET adopted, whereas VBScript has only ON ERROR

VBScript might have an edge over JScript with certain API's or interfaces, but this is easily remedied. The same thing jQuery does for the awful DOM API in the browser, JScript on the server-side can do because it's just so darn flexible.

There shouldn't be maintainability issues with JScript on the server side (as opposed to VBScript) because any decent web programmer NEEDS to know JavaScript, which Microsoft has embraced (see Windows 8, see VS2010 including jQuery in templates, etc. and so much more).

I think it has more to do with the audience and ignorance. Microsoft likes to cater to its VB developers. I used to be a VB developer before my eyes were opened to C# and JavaScript.

Please! Use JScript. Promote JScript. Let's move forward and leave VBScript in the dust.

Answer 2

Let me bottom line this at the top the answer. Use VBScript server-side. For two key reasons.

1. 99.99% of all samples/examples/discussion about ASP coding is presented in VBScript.
2. VBScript is designed to work with OLE Automation interfaces.

There are no real scalability or performance concerns with using JScript server side.

Reliability needs further qualification. The JScript engine is as realiable as the VBScript engine. However much to the reliablitity of system depends on the developer.

Being well versed in both VBScript and JScript I thought I would give JScript on the server ago (since of the two Javascript is my prefered language.) What I found was I easily got confused between code that was to be running server side and code to run client side, it all looks the same. Hence having the server-side code in an entirely different syntax from the client is not to be underestimated.

The real killer reason to avoid JScript is that VBScript is designed to work with COM/OLE Automation objects whereas COM/OLE Automation has had to be "shoe-horned" into JScript. I was constantly finding code that was trying to add a property to an object that being actually an ActiveXObject would not accept the creation of aribitary properties. Also code that is quite succinct if VBScript (yeah I know you didn't expect me to say that) becomes more cumbersome since JScript doesn't understand the concept of a default property as VBScript does.

Typically server-side code means working with ADODB and I found that was a bit nasty looking in JScript. VBScript is a much more natural partner for ADODB that JScript.

You also need to consider the ASP maintainence developer/contractor that comes after you. Working in ASP in the modern world is bad enough but you aren't doing your business any favors working in ASP in very non-standard way. In 5 years time there will still be work out there for older devs making good money tweaking very old but working ASP code but they'll expect it have been written in VBScript else they'll just walk away.