My Opinion About Script#

Building and maintaining large scale applications in JavaScript is complicated. It is especially becomes problematic when many developers work on a single project. One of the ways to approach this problem is to use some other language, which compiles down to JavaScript. There are various such projects out there: Coffee Script, Google Dart, Google Web Toolkit, TypeScript, Script#.

Recently I have been involved in maintenance of the project built using Script#. It lets you write code in C# language and compile it to JS. I have never heard about this tool before faced it on the project.

This is how code in Script# looks like:

Script# makes JS not so scary for c# developers. Personally coming from JS background I already felt confident with tricky JS concepts like prototypical inheritance, closures, variables scoping, “this” keyword etc. Script# instantly felt out of this planet to me. However, I spent some time to learn it and understand better it’s advantages and disadvantages. After using it for a couple of months I could better understand what I like and dislike in it.

Historical Reasons to Use Script#

Tooling

In early days you would use any text editor to write small snippets of JS code. Those text editors would provide syntax highlight at most. c# tools from other side were always providing rich IDE support. Nowadays, editors and IDEs support for JS is much better overall. Especially, products from JetBrains make writing JS a pleasure.

Debugging

Debugging of JavaScript years ago was painful. You would use alert() function to see current state of variables. There were some tools for debugging like Microsoft Script Debugger, but they were mostly unknown. Fortunately later web developers got more advanced debugging instruments in their toolbox, like FireBug came and Chrome Development Tools.

Advantages of Script#

IDE Support

Best part of Script# is that you can leverage all goodies Visual Studio + “productivity extension of choice” offers for c# developers: variables renaming, methods extraction, usages search, navigation around the code etc. These features can not be applied to JS tools easily, because of dynamic nature of JS.

Compile Time Checks

Catching errors at compile time rather than execution time gives you peace of mind. All kinds of errors can be introduced writing JS code without proper tooling. The worst part is that error will be seen during execution. Some would argue that you can write unit tests, but it would be too troublesome to test each line of code with every possible combination of arguments.

Don’t Need to Learn JavaScript

It’s compelling for c# developers that you can write client side application without learning another, weird at first sight, language. However, it’s hard to escape from not knowing JS at all nowadays. Firstly, code is being compiled to JS anyway. You see it in debugger all the time. Also, all tutorials and API references are in plain JS again. Ultimately, learning JS should be a fun endeavour for a developer. Especially these days when JS so ubiquitous.

Disadvantages of Script#

Complicated Usage of 3rd Party Libraries.

The biggest disadvantage of Script# to me it that you cannot simply start using any JS library on the project. Before starting to use a new JS library you need to write (find) c# mappings. Each function of the library you will use on the project will need to be declared in c# language. Not to mention variety of classes to be defined. Script# out of the box provides mapping for several libraries. Take a look on mapping for jQuery for example. There are thousands and thousands lines of codes and dozens of classes just to make jQuery available in Script#. It’s hard to imagine writing so much code manually just to be able to use some library.

This keeps all JS innovations arm length away from you. You would need to invest significant amount of time to write bindings before you can actually use any library.

JavaScript Snippets Conversion to Script#

When you learn how to use some library you read sample code in a plain JS. It takes some time to figure out how to write corresponding code in C#. You repeat process of  “writing code -> compiling -> checking what you’ve got” multiple times.

Syntax Verbosity

No surprise code in c# is more verbose, because of static typing. Compare:

VS

No Dynamic JavaScript Objects Representation

There are two ways to represent JS objects in c#. Each of them has it’s own drawbacks:

  1. Class object with all properties explicitly declared. It complicates things as all objects with all potential properties has to be declared as classes upfront.
  2. Use dictionary, like Dictionary<string, object>. Besides making code less readable this approach does not bring any refactoring benefits. You are still relying on “magical strings” and the only way to find all usages of property is to use Ctrl + F.

Leaky Abstractions

In some cases JS and c# are quite different. Not knowing this difference can trip you over. For example, variable declared inside curly braces block {} in c# is available only in this block. However, in JS it will be available outside of the block as well.

Conclusion

It was hard to make a decision if Script# should be used on the project for teams with extensive c# experience and small JS experience. Fortunately there’s now TypeScript available which brings better tooling to JS by introducing optional static typing. Comparing to Script# it does not step too far away from JS community and does not add too much of extra burden.

Comments are closed.