A few months ago I discovered an exciting alternative to JavaScript, that is both, close to original language and yet innovative, more robust and convenient. The language is called Spider and one of its best features is that the language embraces JavaScript instead of reinventing the wheel. Therefore writing Spider feels like a natural extension and not like learning yet another programming language.
Recently I've published an article about the Spider programming language on SitePoint. The article certainly got some attention and I feel that a few people got the idea wrong. For instance, one of the guys who wrote a comment posted the following:
I don't see a point in starting a JS project using a custom syntax. If the project grows to huge size within a year so that you need one or two new devs, it becomes a pain for them to get on with it. That is assuming, the syntax survives that long and documentation exists and it's being maintained.
Well, that is certainly a valid argument, but I'd like to point out that the same is true for most JavaScript libraries out there. Remember AngularJS? Once people thought that might be a good thing. Now people are all in for Meteor or React. I wonder what will be the situation in a year from now. At the moment I think only a single thing is sure: There will be a new kid on the block!
There are other counter-arguments as well. For me the most important counter argument is the following: To have a language that can be fixed (independent of current browser needs) and transpiles to the currently available technology is a huge bonus. Especially if one is able to get the source and distribute it among a company or project. In the end the project does not need (tiny or even bigger) rewrites, when the current technology stack is evolving. The only thing that is required is another round of compilation, which should happen from time to time anyway.
Now of course people may come up with some argument against compilation. An example:
Pointless project if you don't have your own interpreter embedded in browser. If it is compiled to JS then it is JS nothing more, and it can't be in any case better then JS.
Here I think somebody didn't understand the purpose of a layer on top of JS that is resolved during compile-time. Its the same as with higher level languages in general. You can't beat the lower level in points of raw performance, but you gain productivity, robustness and flexibility. The first point is measured in the time from a starting a project to the project's end. But this time is not only influenced by the lines of code that are required, but also by the time that is spent in debugging. The second argument purely thinks about debugging. Initially debugging may have been a problem, but since modern browsers support source maps it is trivial. The key question is therefore: How many bugs does an average programmer introduce in the program by mistake? Bugs that are not algorithm dependent, but only occur due to quirks in the language.
For me the third point, flexibility, is the most important one. A language like Spider transpiles to ECMAScript 6 from the start. Of course currently ES5 is used as a target, requiring Google's Traceur for the code transition and as run-time support. Nevertheless, once ES6 is fully supported, it is easy to drop dependencies (no rewrite required: better performance with a single re-compilation) and in the future (ES7, ...) further optimizations can also be done without touching the source code of existing applications. That's great!
So would I use it in future projects? Maybe. These are all good reasons, but depending on the project there may be better choices (asm.js, TypeScript, CoffeeScript, raw JavaScript, ...). Hence it still depends, but I consider Spider an exciting alternative!