This project is read-only.

porting Circuit library from dart to ts

Topics: General
Apr 7, 2014 at 9:01 PM
I'm new to ts. Trying to figure out whether I can port a library originally written for dart.
Please see

There's a number of difficulties in porting it, starting with syntax. Dart library makes use of annotations and user-defined operators. I tried to express the same idea in pure javascript, but had to use rather ugly workarounds, which defeated the whole purpose. I'm wondering whether ts provides more syntactic possibilities.

I would be happy to discuss details/motivations/etc if there's any interest among ts users.
Thank you,
Apr 7, 2014 at 10:17 PM
I don't know anything about Dart, but if you post examples of exactly what you want to convert, perhaps I can help shed some light. :)
Apr 7, 2014 at 11:48 PM
Please consider example.
The following program computes 1+2+3+4 (please see comments)

Future<int> add4(a, b, c, d) {
return new Circuit([ // list of functions (called "gates"), => is similar to -> in js, it's just a definition of simple function.
  (@out sum1) => sum1 << add(a, b),  // "add" is a function returning Future, which completes with a+b
  (@out sum2) => sum2 << add(c, d), 
  (sum1, sum2, @out result) => result << add(sum1, sum2)
main() {
add4(1, 2, 3, 4).then(print); // prints 10

Dart has user-defined operators, so you can define << to mean whatever you want. It's defined in such a way that sum1<<add(a,b) means something like
@out is an annotation. In dart. you can annotate anything, and through reflection, find out that function has, say, one parameter (sum1), which is annotated with token "@out"
Yeah, it might sound cryptic still. Maybe you can you browse through readme for 5 min, the idea is simple.
Apr 8, 2014 at 1:41 AM
First thing to note is that TS does not have user defined operators. Another thing to keep in mind is that TS is not another programming language. It's sole purpose (IMHO) is to add a layer of types for compile-time checking, and modifiers that help when transcoding to JavaScript (as less-invasive as possible, so what you see is what you get - mostly). User-defined operators don't exist in JavaScript, which is why I'm sure it is not currently in TS (though there is/was an feature request for inline functions I believe, so if that happens, it wouldn't be far fetched I suppose).

That aside, when working with TS, you simply have to think in terms of JavaScript and Lambda expressions (which just output functions directly). Since there are no user-defined operators, you will need to create those methods BY NAME, or do the operation another way.

Take a look at this:

This is as good as you can get with TS currently I think. You'll have to give more thought to how your "gates" are processed in the Circuit constructor.

Side note: You are doing something similar to a project I started on many years back. I still own the "" domain name from it (it's on hold currently ;) ).
Apr 8, 2014 at 2:51 AM
Edited Apr 8, 2014 at 2:51 AM
Side note: You are doing something similar to a project I started on many years back
Glad to hear that!
Incidentally, I also used it many years back (in Fortran, long before the term "domain" acquired its modern meaning :-)
This idea is probably so old it's a part of folklore, it's just it never went mainstream, at least with respect to evented runtime, where it's the most natural way of reasoning (IMO).

The thing is: I need to parse parameter list of each gate to figure out what is input and what is output - the whole idea revolves around that.
When parameter is specified as output (with @out annotation), I pass Latch object while calling a gate; when it's specified as input (no annotations), I pass the value, but only after it becomes known (or, more precisely, when all inputs of the gate become known).
When Latch is passed, the only thing gate can do is to write a future to it (Latch has no other visible methods).
When value is passed, it's just a normal value; gate can do with it whatever it wants.
That's the whole trick.

Generally, gate can have more than one output parameter (that's how you can implement branching, for example: depending on condition, write future to output latch x or output latch y - so execution takes different path; sometimes there's no inputs; sometimes there's no outputs. So return value of the gate really has no meaning, and not used in any way.

The difficulty is to find a good syntax expression. After N iterations, I was able to do it in dart, but the audience for dart (at least for now) is limited, to put it mildly.
(there are other problems with dart - it can sort-of compile to javascript, but while doing so, it kind-of loses a bunch of most interesting features, e.g. reflection, so the whole thing just falls apart; the meaning of "sort-of" and "kind-of" above is too complicated to be explained in a concise manner).

There can be many workarounds, but those I know, I don't like - they are ugly. E.g. you can use something like comment (which can be just a string literal in the beginning of method body) to denote outputs, but it will look like hack.

I thought there's something that I missed that can be used, but probably no miracles here. Too bad.

I think the idea is so fundamental and simple and natural, it deserves to be supported by language directly - but it is unlikely to happen any time soon :(

Thanks for your comments.
Apr 8, 2014 at 3:29 AM
Hi Alex,

FYI: This is also on the radar already. Please vote/comment here:
Apr 8, 2014 at 4:29 AM
Edited Apr 8, 2014 at 5:01 AM
FYI: There's also this discussion:

BTW: Besides what you mentioned about comments (such as "(/*out*/ sum1) => add(a, b)"), have you considered requiring it as part of the name? Sort of like: "(out_sum1) => add(a, b)"?
Apr 8, 2014 at 2:44 PM
Yes, I considered "out_sum1", but it breaks the beauty of idea, so to speak.
Most obvious replacement that doesn't look like a hack is to specify type Latch for output parameters (so, no "out" annotation, but if it's a latch, we know it's output), e.g.
(sum1: int, sum2, int, result: Latch) => ...
However, it won't work because ts (probably) erases all type annotations, and they are not available in runtime at all. Or I'm wrong?
Is it possible to see original code somehow in runtime?
Another issue is lack of generics; we can't say Latch<int>, can we?

Interesting question that people ask: why do we need all this, if we can use raw futures.
The problem is that while using language on server-side, there's enormous amount of futures involved (hundreds, even thousands), and it's a complete mess.
Very good explanation why this is perceived as a mess comes from unexpected source:

The article contains very deep insight about kind of coordinate system missing in unstructured code. With async code, it's even more complicated: your program effectively creates another program (set of interconnected futures), and this second-order (monadic) program then loses any connection to the code that created it, and exists as one huge blob.
Apr 8, 2014 at 11:17 PM
I thought of that already also, but as you guessed, you cannot access type information at runtime. The original code is in the .ts file only.

Yes, you can have a "class Latch<T> { }" and say "new Latch<number>()". You can also create a dummy interface named 'int' if you wish (i.e. "interface int extends Number { }").
Apr 9, 2014 at 1:24 AM
BTW: If you are thinking on the "(sum1:int, sum2:int, result:Latch) => ... " route, you could do this: "(sum1$int, sum2$int, result$Latch) => ... ". You'd just have to make a note to users that text after the last "$" in the name (or before if in front) is a modifier.
Apr 9, 2014 at 1:49 AM
Oh, there are generics? Good to know, thanks! This makes things more symmetric.
BTW, "int" I used was a mistake - I don't need new type, whatever TS provides for int type is OK, Number is just fine.

In principle, something can be done about type erasure, by running pretty simple preprocessor
Does typescript provide a way to integrate with custom preprocessor?
In dart, there's an attempt to "institutionalize" these preprocessors, so it's easy to integrate with build (e.g. you install somebody's package, it comes with preprocessor, which gets picked up automatically - user doesn't have to configure anything extra).

To help writing preprocessors, dart provides kind of source reflection mechanism (long story, work in progress), but for simple things like circuit it's probably not necessary.
If TS doesn't have this feature, it would be a good idea to consider it IMO. What do you think?

(In principle, dart is a cute language, worth checking out, though there are some circumstances beyond the language that make its future very uncertain).

Apr 9, 2014 at 2:13 AM
Sorry, no pre-processors in typescript just yet. There is however a feature request to extend the typescript compiler.
Apr 9, 2014 at 2:18 AM
Apr 9, 2014 at 3:35 AM
I added my vote, of course. Thanks,
Is there any summary of releases where I can find the history of changes in the language? Just curious about the progress made so far.

Apr 9, 2014 at 4:06 AM
Edited Apr 9, 2014 at 4:07 AM
Look at the release notes under each release here: (expand "details")
It's actually just a blog post of some new features, not a consolidated list. :)

There's also a hand book:
and the language specs:

Hope that helps. :)
Apr 9, 2014 at 3:26 PM
I have an idea how to implement it with existing syntax. Similar to out_ prefix, but with better narrative.
Let's define latch as a device that transforms future into value.
Latch has 2 ports - you drop a future into one port, and eventually get a value from another port.
Suppose we have a latch called "sum". Then the port where you drop the future is called $sum, and the port where you get the value is simply "sum".
Operation of dropping the future looks like function call. Operation of reading result looks like access to simple variable.
Promise<number> add4(a, b, c, d) {
return new Circuit([
($sum1) => $sum1(add(a, b)), 
($sum2) => $sum2(add(c, d)), 
(sum1, sum2, $result) => $result(add(sum1, sum2))

How do you like it? It looks even more concise than dart version, but is it good?
And probably, it can't withstand minification: all dollars will be replaced with something else, no?
Apr 9, 2014 at 4:12 PM
Edited Apr 9, 2014 at 4:13 PM
Sure, not bad at all, but yes, minification may cause a problem. ;)
function add4(a, b, c, d) { 
    return new Circuit([ 
        function($sum1) { return $sum1(add(a, b)); }, 
        function($sum2) { return $sum2(add(c, d)); }, 
        function(sum1, sum2, $result) { return $result(add(sum1, sum2)); }
function add4(e,t,n,r){return new Circuit([function(n){return n(add(e,t))},function(e){return e(add(n,r))},function(e,t,n){return n(add(e,t))}])}
Apr 9, 2014 at 5:20 PM
Can "source maps" feature of HTML5 be used to find out original names? We would need to do it only once per run, after that we cache results (I'm doing the same in dart: use reflection, and cache results, then there's no performance penalty at all).
On the other hand, having mandatory runtime dependency on source maps is probably a bad idea (not sure, I'm a bit confused)

With minification, a lot of metaprogramming otherwise available in javascript is gone. I'm not sure why minification is so important: browser caches scripts, so it's one-time issue, just to load faster when you run it for the first time?
Probably, there are some performance benefits, too, but with modern javascript engines, I'm not sure the gains are that great.

What do you think?

Apr 9, 2014 at 8:17 PM
I've looked at TS map files some time ago and only saw identifier names (for modules, types, functions), but not original source code (i.e. function parameters). That is only in the .ts file.

Keep in mind caching seems to work best when resources have expirations properly set in the response headers. Typically if done right, the scripts should be cached, and reloading should not be an issue. I guess it comes down to frequency of expected script updates (i.e. new HTML page loading old scripts), and bandwidth for high traffic sites.
Apr 9, 2014 at 8:20 PM
Personally, I think if scripts are loaded dynamically to prevent page display lag, it wouldn't be a huge issue (except, again, where bandwidth may be an issue for high traffic APIs, such as the Google Maps API).
Apr 9, 2014 at 10:36 PM
Hi James,
A couple of questions:
1) are people in the habit of minifying nodejs server-side javascript files, too?
2) if browser caching is effective for scripts (and it should be), why people bother with minification at all? So much hassle for nothing, plus losing metaprogramming completely? Is it that hard to set headers? (Probably there's a reason, but I can't find it by googling. Maybe it's just a false belief?)

Apr 9, 2014 at 11:46 PM
Sorry, no idea, I have little experience with NodeJS.

Caching should work if done correctly (, but again, I think it's people like mobile users visiting the site for the first time that suffer the most. I'm sure this won't be as much an issue if/when speeds increase.

There's an article that may shed more light on this:

But I think it only reiterates what I figured: page display lag; but, it also mentions the round trips (communication) made before a single script is loaded (so n trips * n scripts in the header). Drupal puts scripts in the header so they all get loaded first, and minifies them to speed up the process before the page can display (the body won't render until the header completes loading the inline scripts). Personally, I employ script "load on demand" where only a "loader" .js file is loaded (one script), then the page can display as normal while the other scripts load dynamically. Usually the first time user will be reading the page, which gives extra time to load the other scripts. :)
Apr 10, 2014 at 3:03 AM
The reasons mentioned in the article don't explain why minification is done with the loss of information.
Obvious approach would be: 1) strip out comments 2) strip insignificant whitespace 3) introduce a dictionary, and replace every identifier with 1- or 2-char identifier **uniquely** within a module
4) on receiving end, restore original identifiers
How that is different from uglify? Sure, Uglify uses mostly 1-char replacement identifiers; The lossless algo above will use 1-char replacement for 64 most frequent identifiers, and 2-chars for the rest.

I'm pretty sure this would achieve 90% of savings or more. Will try to verify it though - just for curiosity.
Maybe you know the reason why it's NOT done this way?

Apr 10, 2014 at 5:26 AM
Minification is just a way to compress the file space, identifier name lengths, and remove comments. Information is usually lost with the reduction of a file size.

A dictionary would only help if a private identifier was used many times across scopes (which in my experience is rarely the case). Usually though, it is many functions or sub scopes with private vars, and a dictionary may only serve to increase or negate the reduction. Publicly accessible functions and properties are never minified (for obvious reasons).

I pondered about this for TS, and was thinking: what would be nice is a minify modifier so we can select when and where it applies to a script. I think this level of control would cover both worlds.
Apr 18, 2014 at 1:08 AM
Turns out, there's a way to write it in a way that withstands minification.
I put together a write-up for javascript:

You can notice a lot of similarities between this variant and the basic idea of requirejs - it's just with circuit, it's taken from the level of modules to the level of individual function calls.
(Somebody helped me figure this out :-)
I'd like to discuss, Criticism is welcome.
Apr 21, 2014 at 12:28 AM
Edited Apr 21, 2014 at 12:32 AM
Yeah, this crossed my mind, but I didn't know you were willing to completely change your thought on the approach - I just assumed you had a good reason for an array of functions, and that the parameter names should be validated by the compiler (as valid identifiers). Of course, you can do anything in strings, and it's not like jQuery doesn't do something similar (using strings) for element selection. ;) Personally, I hate the thought of having to put ANY code of any kind in a string (which is why I really loved LINQ [C#] when it came out). By the way: Do you really want to rely on the definition order? Did you know it's not even standard?

ECMA-262, section 12.6.4: "The mechanics and order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is not specified [implementation dependent]." That means this could change (though I'm sure not any time soon, if ever)

Why not just take it a step further from an array to nested function calls?
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("sum1", function() { return add(a, b); })
    .gate("sum2", function() { return add(c, d); })
    .result("sum1,sum2", function(x, y) { return add(x, y); });
Which would confine the names to the strings only. This also seems more clear to me regarding whats going on.
Apr 21, 2014 at 2:47 PM
In general, I need to know names of N input parameters and one output parameter. Notation i1,i2,...->o satisfies that.
For order of keys, please see

Not specified, but everybody support it, so it's non-issue: They can't suddenly break whatever they already supported.

Apr 21, 2014 at 8:39 PM
Edited Apr 21, 2014 at 8:47 PM
The top answer says "Do not rely on things staying this way.". :P ;)

My thought was that each ".gate()" (or whatever) could simply "build" the list internally, which would contain both the names and number of items, right up to the call to ".result()". Also, that inputs/outputs would be given as a list of strings (though I was missing something above). Perhaps something like this:
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function() { return add(a, b); })  // gate(inputs, outputs, func)
    .gate("", "sum2", function() { return add(c, d); }) // gate(inputs, outputs, func)
    .result("sum1, sum2", "", function(x, y) { return add(x, y); }); // result(inputs, outputs, func)
(might prevent typos, and at least you won't have to parse the "->", and simply split by "," instead [though not a big deal I'm sure])

Ultimately, in the end, it's whatever looks/feels the best to you. ;)

Edit: Or use arrays for inputs:
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate([], "sum1", function() { return add(a, b); })  // gate(inputs[], output, func)
    .gate(null, "sum2", function() { return add(c, d); }) // gate(inputs[], output, func)
    .result(["sum1", "sum2"], "", function(x, y) { return add(x, y); }); // result(inputs[], output, func)
Apr 21, 2014 at 10:46 PM
I think there's a pretty fine line here with the syntax. Sure, your variant is more straightforward. But it is more verbose.
For many people, verbosity is a deal-breaker.
Parsing is not a big deal, has no performance penalty - results can be cached (that's what I'm doing in dart).
I don't know what is better really. It's a matter of individual taste. No idea how to find out what the "majority" prefers :-)

A bit unrelated, but curious thing I noticed just recently is this: Circuit is based on Futures, but in nodejs (and in js in general), there's no standard futures library. There's popular Q library, Deferreds in jQuery, and a bunch of others, but nothing standard. And if you use any of those libraries, you need adapters for every function - because standard APIs (e.g nodejs) work with callbacks, not futures.

With Circuit, you can define semantics such that you don't need futures. Suppose "add" function is defined as
add(x, y, cb) -- standard nodejs definition with callback.
Circuit can be defined to work in callback-based mode so that the program will look like this:
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function(cb) { add(a, b, cb); })
.gate("", "sum2", function(cb) { add(c, d, cb); }) .gate("sum1, sum2", "result", function(x, y, cb) { add(x, y, cb); });

It's even shorter without futures.
What do you think?

Apr 22, 2014 at 12:54 AM
it is more verbose. For many people, verbosity is a deal-breaker.
I didn't think it would be much more verbose than chainable function calling in jQuery, LinqJS, or Promise/Futures in general. ;)

I think I don't fully see how you envision this working internally, so I'm not sure why you've added callbacks. Are these callbacks "internal Circuit callbacks" to be executed by user code when a custom action is completed to trigger next steps?

You could also consider using the circuit context as the design:
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function() { add(a, b, this); })
    .gate("", "sum2", function() { add(c, d, this); }) 
    .gate("sum1, sum2", "result", function(x, y, ) { add(x, y, this); });
... or perhaps ...
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function() { add(a, b,; })
    .gate("", "sum2", function() { add(c, d,; }) 
    .gate("sum1, sum2", "result", function(x, y, ) { add(x, y,; });
Apr 22, 2014 at 1:15 AM
> I think I don't fully see how you envision this working internally
Let's consider one gate:
.gate("sum1, sum2", "result", function(x, y, cb) { add(x, y, cb); });
It has 2 inputs and one output ("result"). When inputs are ready, Circuit will call gate function with 3 parameters: first two are values. For the third out, which corresponds to "result", circuit will pass a function (!) that can be defined roughly as
function(value, err) {
if (err)
raise internal error in the circuit (passing err and maybe other info about the point of error)
assign value to latch "result"
} :
Please note the last part: it assigns to "result" BECAUSE result is the output of the gate. So callback cb is bound specifically to "result" latch.
For another gate, like
.gate("", "sum1", function(cb) { add(a, b, cb)
the thing we pass as parameter cb will be A FUNCTION bound to latch "sum1"
Therefore, depending on whether latch is specified as input or output, we pass either value of the latch (when it becomes known), or function bound to the latch to be used as callback.

Apr 22, 2014 at 2:37 AM
Oh ok, then it's as I suspected: The end users of the design would call "cb" based on success or failure of the gate function. Sure, why not...? ;) Seems fine as well. Personally, as a developer, I'd rather see "function(x, y) { add(x, y, this); }" be bound to the latch, then I'd have access to latch-specific functions (such as perhaps "latch.result()"), and hopefully the parent Circuit object for max control.

function add(a, b, latch) {
    var val = Q(a + b).delay(10);
   // if (major error) latch.circuit.abort(); !!!, else ...
    return latch && latch.result(value) || val;  // (note: possibly allows calling "add(#,#)" by itself)

function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function() { add(a, b, this); })
    .gate("", "sum2", function() { add(c, d, this); }) 
    .gate("sum1, sum2", "result", function(x, y) { add(x, y, this); });
Apr 22, 2014 at 4:50 AM
I agree that "this: would be easier to explain, but I would go with straightforward implementation of "add", following nodejs pattern used across all nodejs libraries - they don't have a lot of ceremony about callbacks, just write cb(result,error) without checking anything - if it crashes, so be it. Functions with last parameter "cb" are not expected to return anything meaningful through "return" (as far as I remember).

I think though everything can be made even simpler, with less magic, just as
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function() { add(a, b, this.cb); })
    .gate("", "sum2", function() { add(c, d, this.cb); }) 
    .gate("sum1, sum2", "result", function(x, y) { add(x, y, this.cb); });
Where "this" is really a GATE, not latch. Because in the context of .gate(....), you would intuitively expect "this" to point to a gate, not latch. It all reads as "pass callback associated with gate". Callback associated with gate sets output of the gate
Further, you can define access all properties of a gate through "this" pointer (if needed).
Yet another possibility is to really pass the output latch as extra parameter:
function add4(a, b, c, d) {
  return Circuit("add4")
    .gate("", "sum1", function(out) { add(a, b, out.cb); })
    .gate("", "sum2", function(out) { add(c, d, out.cb); }) 
    .gate("sum1, sum2", "result", function(x, y, out) { add(x, y, out.cb); });
In which case we pass a real latch as "out", and latch has property "cb" - function to be called to set the latch. Maybe this is the simplest variant?
Too many possibilities, hard to define criteria to choose the best one.

Apr 22, 2014 at 8:24 AM
Sure, sounds good. Personally I would choose the "this.cb" idea - keeps the function parameters clean, and less to type. :) However, I'm not a NodeJS developer, so if that's a big target audience, then perhaps the last idea is better - not sure either in this case. :)
Apr 22, 2014 at 2:41 PM
I agree, probably this.cb is the "lesser evil", so to speak.
I really don't know how big nodejs audience is. A lot of hype, but no reliable stats. People may say they like something, but they don't. The only way to measure how much they like anything is to make them pay money :-) And if the stuff is free, you will never know.

Maybe you can be interested in writing implementation? Or know someone who is interested? I rewrote my dart program 10 times already, got tired. Rewriting the same thing once again in JS would not be a very exciting experience, at least at the moment :-).
It might be one of ideas that will take a very long time to reach mainstream.

Apr 22, 2014 at 5:01 PM
Edited Apr 22, 2014 at 5:14 PM
Interesting search trends: and
But some JS++ languages are somewhat young still, and TS is fairly new to the game, so it will be interesting to see how things progress.

I appreciate the offer, and really wish I had time to contribute, but unfortunately I can't distract from current projects at the moment.
Apr 22, 2014 at 5:24 PM
Dart in this diagram is a different dart, has nothing to do with programming language. Not sure typescript there is really a language either.
The chart is not reliable. There are other sites that provide better ranking for languages, e.g
Anyway, dart is a cute language, might be worth taking a look. It may evolve into something useful, hard to know.

Apr 22, 2014 at 8:34 PM
Edited Apr 22, 2014 at 9:25 PM
True - should have qualified the names better I guess. ;) Perhaps this is better:

Being very fluent in JavaScript myself makes me stay away from all JS++ type languages, with TypeScript being the only exception because it doesn't pull too far away from basic JS, and I can refactor my code easily, and prevent many type related errors. I also like that I can run the compiler as 100% JS itself to use in a JS application. ;)

I remember when I created my own lua-style script language in the 90s, and an assembly-style script language in early 2000 (much higher level of course), then proceeded to experiment with a circuit related script design, as well as other ideas I played with. These were, however, "add ons" to host applications; but now that JavaScript is JIT compiled, it makes JavaScript basically like the main host language for an application on a device - and I'm more inclined to not called it "script" anymore, since scripts (in my thinking of scripts) are usually interpreted (or transpiled). To me, writing in a new JS++ language that compiles down to JavaScript is like writing in C# to compile down to TypeScript, where all C# libraries are actually JavaScript files. I really don't see any need to learn a new level of abstraction (language) which simply transcodes to another level of abstraction that I should really learn anyhow. ;) I am aware, however, that Dart was designed to be a possible replacement for JavaScript - but given the new JS standards coming out over the next few years, I hardly see it going anywhere (nor its point anymore). The main thing missing from JS is an optional type layer - which Dart also fails at where Generics are concerned (only limited class/type generics supported, and not functions). Bottom line: I'm more inclined to create script languages to be compiled by a compiler written in JavaScript, since the resulting JS can be JIT-compiled as well. ;) In fact that is one of the ideas behind a project I'm working on - a complete tooling set in HTML5/JS/CEFSharp with its own VPL-Script hybrid language backed by scriptlets (circuit-ish like block texts with custom script behinds [TypeScript, even C# perhaps, Circuit script? ;), etc., which all compile to JS]) in a seamless client/server networking environment (I'm calling it DreamSpace Studio). So far the base framework itself (open source) is running a mobile app for a company I work for, and I am working on the IDE as well (using the ACE editor), along with a donated license from Scirra (Construct 2) to support lower level game development and networking. This is also why I'm so swamped now. ;)
Apr 22, 2014 at 10:10 PM
WOW, this graph is much more meaningful. Before 2011, all mentions of dart are unrelated, which gives us the level of "noise". After the peak, it gradually re-converges with noise level :-). Quite sad. Or funny. Depends on your perspective :-)

I have big issues with dart -> javascript compilation myself. To be honest, I'm interested only in VM (eventually, it will be part of Chrome and Android - I think this will happen by the end of this year). Javascript produced by dart doesn't appeal to me at all (I think it's just a waste of time to even work on it). I have same reasons for this sentiment as you: it's as much of a kludge as java->javascript, where you have one problem at the start, and 2.5 or 3 problems at the end. But, considered as separate language, dart has some good points (BTW, generics for methods will come, they are planned). Programs tend to be quite short, I like it. APIs are polished. Refactoring is much easier (in most cases). I don't know, but maybe TypeScript solves this problem, too.

I'm doing it all mostly for fun (I'm close to retirement age). Learned javascript several years ago out of curiosity, and liked it a lot. Basically, it's kinda LISP in disguise. Very powerful language. But I'm not using it on my day job.

In my younger years, I dealt mostly with firmware, low-level performance optimization etc. Not any more - too hard, had to switch to something less stressful :-)
BTW, I know performance side of dart well, wrote whole suite of benchmarks, compared with other languages etc.
In dart mailing list, I specialize in answering performance-related questions :-)
Apr 23, 2014 at 12:17 AM
I used LISP once for a 3D scene modeling application years ago (can't even remember what it was called now LOL). I view LISP like another flavor of assembly programming. ;) (actually, I even based my old assembly-scripting specifications on my experiences with it)

Yes, TypeScript refactors very well (no issues yet). Performance in JS is highly browser dependant. In one case, a "replace()" with regex is faster, and in another, a simple "split()" + "join()" is many times faster instead. I doubt any JS++ language gives that much thought. I have detection in my framework to override and implement the fastest patterns based on detected browser (since it's a framework for building apps [especially games] I need to consider it). I like being able to milk the speed as much as I can at the lower levels. ;) I also use JSPerf like there's no tomorrow, and have found many optimizations that many JS++ languages do not even consider. I guess I'm a control freak. :P ;) If it wasn't for development time efficiency, I'd just learn MSIL and skip C#. LOL. Hey ... there's an idea; JS assembly anyone? :)
Apr 23, 2014 at 4:26 AM
I think LLJS was (is?) an attempt to create kind of "assembly" (or, rather, C?) language based on JS:
I don't know about current state. Latest posts on LLJS are about 1 year old. There are benchmarks js vs lljs vs emscripten:
Mozilla is experimenting a lot with low-level JS. I think, having limited resources, they now shifted focus somehow towards (seemingly unrelated) rust.

Speaking of regexp: in Chrome, regexp engine is very efficient. Regexps get compiled rather deeply, Ever seen benchmark where javascript beats everybody (including C)?

If you are interested how they did it. I can find the article. Some of the people work on dart now, but regexp in dart is not yet optimized like this one.
BTW, the people who devised most of optimization methods for JS runtime (including the hack of "classification" of JS objects) are on dart team.
There's a chance that dart will reach (or even beat) performance of java in a couple of years. They are not very far behind,