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.
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!