9

Preference for dynamic and static typing is largely a matter of taste, and different people find them more or less suitable in different situations.

My question is, would it be technically possible to have a statically-typed alternative to JavaScript for client-side web page augmentation etc.?

Armand
  • 6,508
  • 4
  • 37
  • 53

13 Answers13

21

There's certainly no technical reason such a thing couldnt exist. There's nothing particular about client-side code that mandates the use of dynamically typed languages.

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
16

Since it's highly unlikely that another language will find broad adoption, your best bet would be to create a statically typed version of JavaScript (i.e. a language close to java) and a preprocessor that converts that to normal JavaScript.

For example, your script looks like that:

<script type="text/staticjavascript">
   String foobar(int foo, String bar) {
      String result="";
      for (int i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

and the preprocessor checks that every variable, function, object etc. is used correctly according to it's type, and changes the script to 

<script type="text/javascript">
   function foobar(foo, bar) {
      var result="";
      for (var i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

which every browser can handle.

user281377
  • 28,352
  • 5
  • 75
  • 130
  • 5
    +1 for a pragmatic approach – Gary Dec 15 '10 at 22:41
  • Really this question isn't about pragmatism - it's about theory. Will update. – Armand Dec 15 '10 at 22:54
  • 2
    I would also suggest using type inference. – Oliver Weiler Dec 16 '10 at 12:22
  • Helper Method: Very good suggestion, but I don't change my example now, since type inference would make the static version very similar to the dynamic version, since the example is so simple. – user281377 Dec 16 '10 at 12:39
  • 4
    I don't think a statically typed javascript would be very close to java, other than syntactically. Javascript and Java have many differences beyond static vs. dynamic typing - class-based vs. prototype-based OO for one. Since your sample code seems to be class-based, I'd argue that "staticjavascript" is a misnomer for that language and it should rather be called something like "client-side java". +1 for compiling to javascript though (btw the Google Web Toolkit does compile java to javascript). – sepp2k Dec 16 '10 at 14:48
  • This already exists I think. It's called TypeScript. – Asad Saeeduddin Sep 24 '14 at 17:44
  • @Asad Yes, Microsoft created it 2 years after my answer. I can only guess that Anders Hejlsberg of MS read my post and thought "wow, what a great idea" ;-) – user281377 Sep 25 '14 at 08:02
8

My question is, would it be technically possible to have a statically-typed alternative to JavaScript for client-side web page augmentation etc.?

Sure. The Google Web Toolkit compiles statically-typed Java to JavaScript... Just think of it: all the beauty and flexibility of Java, with all the performance of machine-generated JavaScript!

Seriously though, you could do this for all sorts of languages, and many have tried (there are, or have been, compilers for C and C# as well). Whether the end result is practical or not depends on what you're trying to accomplish: Google's after a consistent platform for developing very large client-side apps, and has their own JavaScript engine to boot; you may well find that adopting such a beast for hover-effects and the odd AJAX call introduces far more pain than simply learning to live with a bit of untyped code...

Shog9
  • 8,083
  • 2
  • 45
  • 56
  • 3
    I can't totally tell if you are joking about the "benefits" of GWT. If you are, bravo. Working with GWT was one of the most maddening experiences of my life. – Nicole Dec 16 '10 at 00:09
  • @Renesis: As if working with Javascript and browser compatibilities wasn't already maddening? But it does have slick features, like downloading multiple images in a single image, and then cutting them up on the client. – Macneil Dec 16 '10 at 01:33
  • 1
    @Macneil They may have fixed this by now, but when I was working with Sprites it almost negated all benefit because it automatically wrote other CSS background properties that you may not have wanted, so you had to clutter up your CSS every time to override it. – Nicole Dec 16 '10 at 02:03
6

Most of the benefits of statically-typed languages are realized at compile time. If the language is going to be interpreted on the client, then a good deal of those advantages are lost. If you compile them on the server, then you need to figure out how to get them loaded and run on the client (think ActiveX controls). You could go with a hybrid approach (compile to some intermediate tokenized form), but then you're basically back to Java applets.

TMN
  • 11,313
  • 1
  • 21
  • 31
  • 2
    +1 for explaining a possible reason *why not*, not just answering if it's possible. –  Dec 30 '10 at 21:23
4

It exists already.

ActionScript 3 (the scripting language behind Flash and Flex) is a dialect of ECMAScript that implements strong types, and you can use it in more or less the same client-side way as JavaScript (the difference being that AS3 requires a flash plugin, and is compiled). I personally try to steer away from it these days, but if you're in the "static" camp, give it a whirl.

That answers the principal question, and now that we have that, your secondary question becomes "Is Flash practical?" The answer is "yes", with a few "if"s and "but"s

  • ...if you need to hide your code for whatever reason.
  • ...if you want a very, very (past jQuery level) high level of interactivity
  • ...but even without HTML5, the cross-browser compatibilities are getting much better lately.
  • ...but HTML5 is coming soon.
  • ...but one of the big draws of static typing/compilation (as opposed to interpretation) is the added speed it allows through optimizations (and Flash doesn't really have very good speed, despite the type system)
Inaimathi
  • 4,884
  • 1
  • 26
  • 34
3

In theory, you can stick any scripts on a page you want. The <script> tag has a type attribute, after all.

The only barrier is getting enough market share in terms of implementation in different browsers to make it worthwhile to use.

So yeah, it's kind of unlikely at this point.

Anon.
  • 2,195
  • 15
  • 14
  • So, no problem with the static typing then? I'm not too bothered about the practicalities of this catching on. – Armand Dec 15 '10 at 22:36
  • 1
    @Alison: You can place any textual content you want in a script tag (with one exception - it can't contain the character sequence ``). You could stick Brainf*ck code in there if you really wanted to. Then all you need to do is implement an interpreter for your chosen language in the browser you want to use. – Anon. Dec 15 '10 at 22:44
  • @Anon. thanks, very interesting. If it's that easy, it's probably been done somewhere. I do remember ` – Armand Dec 15 '10 at 23:06
  • Alison: vbscript was IE-only, and some people used it when IE's market share was >90%. Today, with IE's market share somewhere around 50%, probably less in some parts of the world, it's a major no-go; and as long as no browser gets that much market share again, don't expect anything like a new client-side scripting language to happen. – user281377 Dec 15 '10 at 23:15
  • @Alison: Internet Explorer *still* supports VBScript as a scripting language... I should know, we have intranet sites here that use it (and hence *require* Internet Explorer - urgh!) – Dean Harding Dec 15 '10 at 23:24
  • @Dean: There's a lot of businesses, apparently, that have intranet apps that keep them on IE. Fortunately for me, I only have to use IE for the payroll app, not anything else. – David Thornley Dec 16 '10 at 19:49
2

Would it be practical? No.

Is it possible? Yes!

Developing your own statically-typed alternative to JavaScript would be time-consuming, at best. At worst, you wouldn't be able to convince any existing browsers to implement your client scripting language, and would have to write your own.

Marcie
  • 3,009
  • 2
  • 19
  • 21
1

Would it technically be possible? If it's to be implemented in Java, I'd say "very, very hard, but possible" without significant performance loss.

I'm actually handwriting a statically typed DSL in Java right now, and the only way I've found to avoid runtime type-checking is to use generics and suppress "unchecked" warnings... that is, until the time came to implement multi-dimensional arrays (class parameters must be known at compile time and are thus inherently finite, whereas multi-dimensional arrays represent an infinite number of types...) Still trying to figure this one out, unfortunately-- I'm sure I'll encounter similar problems with user defined classes.

Thing is, I keep stumbling on these sorts of problems, but after sitting on it for a while, I come up with a good solution. So, to do it and have the performance benefits of static typing (no runtime type checking), I'd say it's extremely difficult, but not impossible. Minus the performance, I'd say hard but very possible.

I know it's an old question, just thought my experience might be valuable to someone.

Philip Guin
  • 111
  • 4
1

Maybe you find your answer here: https://stackoverflow.com/questions/86426/why-require-javascript-rather-than-supporting-a-standard-browser-virtual-machine

Note: In my opinion more recent answers are more insightful despite their lower score.

Community
  • 1
Ebrahim Mohammadi
  • 549
  • 1
  • 4
  • 7
1

You can use languages such as haXe to write your code in a statically typed manner and export it to javascript. JavaScript is becoming very fast, so it is sufficient as an output language. Trying to enforce a statically typed language as a web standard is near to impossible. Attempts to introduce static typing into JavaScript have failed for reasons to broad to discuss.

back2dos
  • 29,980
  • 3
  • 73
  • 114
0

Optional static typing was part of ECMAScript's Project Harmony - whether or not it will ever happen in client-side [browser-based] JavaScript is unknown I guess. See this Wikipedia link: http://en.wikipedia.org/wiki/ECMAScript#Future_development

jqueryrocks
  • 101
  • 6
0

It's technically possible to write client-side scripts in any scripting language that the user agent (browser) supports. In practice, the only widely supported language is JavaScript / ECMAScript. Convincing browser makers to implement and support a new language at this stage is unlikely to succeed; thus, if you wanted to use a new statically typed client-side language, you would need to either translate the new language to JavaScript, or implement an interpreter for it in JavaScript.

There are several projects that already do something like this; for example, Google Web Toolkit, as mentioned in one of the other answers.

mithrandi
  • 101
  • 2
0

Given you have no hope in getting all browsers that are used in the real world to support a new language; the language will have to compile down to jscript.

As all the examples of the web are in jscript, the language should mostly look like jscript.

I think there is scope with have a “sub set” of jscript that is check by a static checker but is also valid jscript. E.g:

  • All variables must have a comment that say there types before the first usage.
  • All usages of variables must be valid with the above.
  • Functions/class may not be used if they have not be declared in a comment#
  • A comment at the top of the js file must list all other js files that it depends on.
Ian
  • 4,594
  • 18
  • 28