What are people using JScript.Net for?

Question

I'm interested to know who uses JScript.Net and for what sort of applications. Whenever I'm reading MSDN .Net documentation, I always notice the JScript samples but in all the years I've been a C# dev I've never actually known anyone to use it.

What sort of applications are people using this for, and how does it measure, in terms of flexibility, power and general usage, to C#?

[Edit: Just to clarify - I'm not asking what JScript.Net is, I'm asking what people are actually using it for - i.e. interested to know actual usage scenarios and how people have found it to work with]

Answer 1

The JScript.NET Wikipedia page is pretty explanatory: http://en.wikipedia.org/wiki/JScript%5F.NET

In short, it seems to be JavaScript with the .NET library.

Answer 2

JScript .NET is a modern scripting language with a wide variety of applications. It is a true object-oriented language, and yet it still keeps its "scripting" feel. JScript .NET maintains full backwards compatibility with previous versions of JScript, while incorporating great new features and providing access to the common language runtime and .NET Framework (from JScript.NET).

Besides, you might find this stackoverflow post helpful as well: Can JScript.NET be used to script a .NET application?

As for who is using, I am honestly not aware of (I am pretty sure there are out there).

Read Introducing JScript.NET.

My personal thought was that it could be awsome for web developers who're used to write in plain JScript and want to get the benefits of .NET without need to learn a new language, or for those who want to have all their code written in one language.

Answer 3

Rob - I have used JScript.NET in anger in one place in my code, which is essentially to expose the functionality of its eval method. Here is a cut-down version:

static public class Evaluator
{
    private const string _jscriptSource =
        @"package Evaluator
        {
           class Evaluator
           {
              public function Eval(expr : String) : String 
              { 
                 return eval(expr); 
              }
           }
        }";

    static private object _evaluator;
    static private Type _evaluatorType;

    static Evaluator()
    {
        InstantiateInternalEvaluator();
    }

    static private void InstantiateInternalEvaluator()
    {
        JScriptCodeProvider compiler = new JScriptCodeProvider();

        CompilerParameters parameters;
        parameters = new CompilerParameters();
        parameters.GenerateInMemory = true;

        CompilerResults results;
        results = compiler.CompileAssemblyFromSource(parameters, _jscriptSource);

        Assembly assembly = results.CompiledAssembly;
        _evaluatorType = assembly.GetType("Evaluator.Evaluator");

        _evaluator = Activator.CreateInstance(_evaluatorType);
    }

    static public object EvaluateToObject(string statement)
    {
        try
        {
            return _evaluatorType.InvokeMember(
                "Eval",
                BindingFlags.InvokeMethod,
                null,
                _evaluator,
                new object[] {statement}
                );
        }
        catch (Exception)
        {
            InstantiateInternalEvaluator();
            return null;
        }
    }

You can obviously create overloads for other return types. I can't claim the original idea for this was mine! Uses for this would be, for example, to evaluate a string expression like 3 + 4 to 7 without expression parsing.

Answer 4

I don't know how it compares performance-wise, but I know that JScript.NET is one of the languages you can use with Unity 3D.

Answer 5

I'd just assumed it was used by Microsoft to inflate the number of languages .NET supported at launch for marketing purposes.

Answer 6

JScript .NET is one of the languages supported for writing application extensions for Sony's family of media editing products. Sound Forge & Vegas.

In particular Sound Forge has a window that you can use to edit and run scripts to manipulate audio files.

It turns out the Microsoft made it pretty easy to add scripting to your application using one (or all) of the .NET supported languages. VB, JScript & C#. Just just have to expose some objects from your application and hand those objects (assemblies actually) to the compiler along with the user's script text.

They have a web forum for script writers for Sound Forge

Answer 7

With the Business Process Management tool Metastorm BPM you can use JScript.Net to extend your workflows. For example you can add custom .Net .dlls to the engine and interact with them in your processes using JScript.Net.

My experience was quite positive. I've implemented just some small glue scripts but I'd prefer scripting with JScript.Net to VBScript (the second supported Scripting Language) anytime.

Answer 8

I'm late to the party here, but I want to add my take:

I see JScript.NET being useful for server-side code. It's pretty natural to use something server-side that is essentially the same as what you use client-side. Also, it makes working with JSON that much easier so can be a boon if you're creating a web service that communicates via JSON.

I wrote a web service where I work in C# but am thinking of migrating to JScript.NET because of those reasons.

Answer 9

I use it quite a lot, almost exclusively, for ASP.NET and related web-stuff.

You can use it for pretty much all the stuff you can use the other .NET languages for. It makes MSIL, just like the others ;) Compiled with the "fast" option which turns of some of the native javascript traits, like prototype extensions and eval, it performs just like any other code on the CLR.

It's certainly not a full-fledged member of the family, in the sense that it seems somewhat left behind in .NET 1.1 in terms of features, the tool support is non-existant, and the documentation is downright appaling. That's part of why I like it so much, actually, makes me feel like I'm programming.

If you have a lot of (j)scripts lying around that needs to be converted to .NET, this is the obvious choice as you will usually need very little rewriting for that to work. Otherwise there's no particular reason for choosing JScript.NET over any other .NET language, and many reasons not to.

It all comes down to personal preferences since it all ends up as the same CLR code, regardless of language. I find JScript.NET easy-going, natural to write and with a flexible simplicity like no other language I tried, so I use that until I encounter a problem that the language just can't handle. Hasn't happened yet.

Answer 10

Well, I'm trying to use it. I can't say I've been successful.

I've not done a lot of web coding in any environment, but here is my 2 cents.

I wanted to expose some database tables to a web page, so I threw together a quick Classic ASP (yeah, yeah, I know) page that pulled the data from SQL Server and returned the table as a JSON object. Rather than locate a JSON serializer for VBScript I just wrote both sides in J(ava)script and imported json2.js on the server to provide serialization. It worked great; honestly it took less than an hour to have it spit back a nice JSON representation of the table, 50 minutes of which was a fruitless attempt to get JScript to import json2.min.js directly rather than throwing <% %> wrappers around it and renaming it json2.min.asp.

But everyone says it is sick and wrong to use Classic ASP in this day and age, so I'm trying to replace my quick & dirty ASP + Jscript + ADO implementation with ASP.NET + Jscript.NET + ADO.NET. After some head-pounding-keyboard moments I have ASP.NET v4.0.30319 up on IIS6 and have a "hello, world" page that does some simple loops javascript via the <@ language = "JScript"> directive. So far so good.

I were following Best Practices here I'd be wrapping everything in a class etc, but as I'm just try to get out of the driveway I tried doing a quick port of my existing code, which imports various useful bits of Javascript from other files using ASP include statements.

Including some simple stuff using <--#incude file="somejsconstants.asp" --> worked fine and let me access constants from that file. But my attempt to pull in the JSON serializer with<--#incude file="json2.min.asp" --> didn't work, and firing up a version of json2.js suitably modified to be a standalone aspx page and threw the same error. (The compiler error is Objects of type 'jscript_aspx' do not have such a member.) JScript.NET seems to be unhappy with the use of closures, a near-omnipresent construction in today's javascript libraries.

From postings above it's clear there are plenty of ways to serialize JSON objects in the .NET platform, but my gut feeling is that if JScript.NET barfs on Javascript written by Douglas Crockford, then it is a quirky, incompatible rathole not worth investing my time in. I might as well follow the ASP.NET masses and use C#.