Boy am I glad I added LuvvieScript (Erlang dialect) to it last week. Its sits a bit lonely, the last transpile-to-javascript language to come in. Robert Virding of Lisp-Flavoured-Erlang pointed out that once I get it working all the other compile-to-Erlang languages (Elixir, LFE, Joxa) will also run in the browser (so no pressure then).
If you fancy developing your own transpile-to-js language I have written up the actual process in some detail:
http://luvv.ie/toolchain.html
Erlang (via Erlang Core) is actually quite a sweet example. Erlang (which is small) is transformed into Erlang Core (a language targetted at machines not humans) which has a very small set of primitives (21 in all). That Language is turned into a compact AST which is then transpiled to a Javascript AST and transformed back up to Javascript using standard JS syntax tools.
I have also written up the thinking about how to make an OTP-ish Erlang dialect in the browser work as part of Erlang/OTP's 'span of control' in the server-side cluster:
http://luvv.ie/mission.html
No. The client and the server are such different environments. In the server you want 10s of 1,000s of processes, with long lifes (years, months) and hot code loading and supervision/restart. None of this is needed/available in the browser.
So the key goal is low-impedance - the developer has a mental model where this is say a server-side process and the business rule is 'send the user a message' so they write code like:
call_user("gordon@vixo.com", modal, {"Did you brush your teeth?", {"yes", "no"}})
and the 'modal' process in my browser gets some message like:
{msg, {"Did you brush your teeth?", {"yes", "no"})
It pops a yes/no dialog box and send "yes" back to the calling process on the server.
On a browser you would also want 1000 process maybe. There can be tons of different inputs you need to monitor and then you might do a lot of transformation on them.
Supervision and restart are not only useful if a application is long running, if you implement a game, a user might to spend many hours on a page. They might leave it open in a different tab for a long time and expect it to work when they get back.
I know more about CSP and not Actors but there you use many of the same tricks (I think). And I really don't see why one would constrain the browser side.
I didn't just pluck 9 out of the air, it comes from thinking about how I would structure applications that I have written.
Take for instance our online spreadsheet - very complex GUI - 2,500 divs - but when you ask what are is the concurrency - what are the discrete functional data models that I need to manipulate - the number is low:
* a menu bar
* a toolbar
* a tabs bar
* a grid
* the cell input overlay
* 5 or 6 dialog boxes
The grid is endless scrolling set of spreadsheet cells and behind the scenes it is pre-built panels of 20x20 which are 'next-but-one' assembled on the fly for smooth scrolling.
Even if you break the grid out for max concurrency - you only add another 8 or 9 concurrent data models.
9 - 29 Web Worker processes for a page sounds liveable with.
With regard to restart and supervision I really do mean the Operational Supervision that Erlang/OTP supervision does in terms of handling errors. I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option. Page refresh covers most of what you might ever need.
I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.
If that is your goal then I dont want to clame that you have not achived it. This looks quite good for many things, my point is however that I mayself would not want to restrict myself this way.
In the future we be able to directly go from one browser to another, we might query or get messages from tons of diffrent servers, the OS might send us events and so on. More and more, the browser becomes a application deployment target.
> 9 - 29 Web Worker processes for a page sounds liveable with.
The question is not really if I can live with, the question is if I want to.
It just seamst to me that, when light weight concurrency is good on the server we should also use it in the browser. Seams to me this would help with the idea of using simular programming models on both ends.
> I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option.
I can imagen many things. Lets say a you inplment some game or simulation where you have threads of executuion doing some calculation and maybe rendering themselfs on the screen. Now it would be nice to have some sort of fail-over system that might monitor all these and can potentially restart them, maybe get some information from the server or internal data store, maybe it is required to shut down all the other threads and restart them as well.
Maybe you stop getting messages from the server, and you have to restart the server or go and search for another server. Maybe you have to get a message from the server, informing you that it is shuting down and internal storage should be used.
I can image lots of things, and I dont know why I should restrict myself by design.
> I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.
CSP is what Go implments (or core.async library in clojure).
The concurrency issue is not mine to fix. Javascript provides native concurrency by Web Worker which (compared to Erlang processes is a very heavy-weight, no-shared code environment. LuvvieScript is just realising that (given those prior contraints) an OTP-ish Erlang dom-script language can be created.
The alternative (a light-weight process language) involves building a scheduler in Javascript - which is a very different beast to a transpiler with a message-consuming/emitting runtime built with existing JS libraries.
To be brutally honest, the later is beyond my competancies.
Fortunately somebody has already made a implementation and you could try to use it as a base layer for your own system. I don't how easy it is to interface with Clojures core.async, but I guess its probably possible.
It might be a interesting exercise to implement Erlang Actors on top of this and then expose it to a JS interface. This might be a good idea in general and not just for your OTP-ish langauge.
Also I want to say that I came a across as very negative, I just wanted to say that LuvvieScript is quite cool and useful. WebWorkers are a much better primitive for Erlang style stuff because its shard nothing even on the server (I think). In really the browser should really provide a API for either shard memory threads or proper Erlang/Go Style threads.
I expect an increasingly larger C/C++ codebase to be ported with emscripten and asm.js with decent enough performance (especially dev tools). Currently C++ code compiled with emscripten runs in Firefox only 1.5x slower than natively compiled code [1].
Notable ports can be found at emscripten wiki page [2].
From my experience, CoffeeScript seems to be running away from the pack. ClojureScript, Dart and TypeScript all are probably leaders of the second tier, which is far and away more popular than the rest.
CoffeeScript showed up in 2009. GWT has been around since 2006 and got widespread publicity when it launched. A number of the other options also came out well before CoffeeScript - Python's Pyjamas came out in 2007.
What CoffeeScript did introduce people to was the idea of a language that compiled to only Javascript. And as such, it didn't have a pre-existing language community to point out the shortcomings of the JS implementation. The problem with most compile-to-JS languages is that you never get the semantics exactly right; things like float semantics, string encodings, prototype chains etc. usually make the JS version just different enough to hold surprises for programmers used to the server-side implementation, which defeats the purpose of using the same language for both (Rhino had the same problem, which is why it took V8 before Node could really catch on). CoffeeScripters have no such preconceptions, though - it's a completely new language, so it's adopted on its own merits as a browser-side language by those who like what it provides.
> programmers used to the server-side implementation, which defeats the purpose of using the same language for both
I would actually disagree. In the Clojure world, we try to embrace the platform, meaning that we do not try to make all source compatible.
The goal is to have the basic comparable and then make all the more algorithmic library work everywhere. I think this has worked out pretty well so far.
Things like core.logic, core.match, core.typed and so on work on both sides with relatively small adjustments.
Clojure is odd in this way. Java was created as a cohesive, self-sufficient platform. Clojure was always envisioned as sort of a passenger — something to be grafted on to an existing platform. From the very early days, it already lived in two different environments simultaneously (the JVM and CLR), so the culture and the practices were already there, and it wasn't too jarring when they added JavaScript.
While by no means a definitive system, the order in which they're listed within each section tends to reflect their maturity to a degree (at least amongst the top few in each section).
This seems to be a "gave up on website, replaced with GitHub" version of altjs.org (which now rediects here). (This website used to have Cycript listed, but now doesn't.)
How is async.js a language extension? If it's a "language extension", then isn't it arguable that every library is a "language extension"?
At the very least I'm unsatisfied with the rationale provided in the page. Other items generally explain what makes them worthy of this list, but async.js is just, "Async utilities for node and the browser" which is, while immensely useful, doesn't change JavaScript in a way that is shared by other items on the list.
I'm torn between CoffeeScript and TypeScript. If there was a language that had the syntax sugar of CoffeeScript plus static typing, I would be in heaven.
I think the reason so many languages compile to JS, is that you essentially get to play with and learn a new language, and it's guilt free. Usually you need to choose between technologies - JVM or .NET, Python or Ruby, HTML5/Canvas or Flash, etc... With compile to JS languages, you're never forced to make that choice, if you ever get bored of a language you just compile it into JS and continue with your life.
Right now I'm having a lot of fun playing with Haxe and OpenFL/Lime (formerly NME). Being able to create an app with the Flash-like API and compile it, without modifications for HTML5/Flash/Windows/Linux/Mac/Android/iOS/Tizen natively (!!) feels like some sort of unholy hack. Not to mention it's other abilities (compile to everything from JS to Java, C# and C++).
I've had this discussion in other threads; but, how wise it is to use these instead of vanilla JS in a project you want contributed to?
I personally find CoffeeScript very useful, and believe it's sufficiently widespread and mature as to be viable. All of these others though, I can only see it as increasing the learning curve on a project. I want to use IcedCoffeeScript (Oh, am I tired of Promises) and some of the JS extensions but I can't justify it. It's like a cake that I know I can't eat.
> instead of vanilla JS in a project you want contributed to
Not sure what this means? If there is a existing project, it would probably be better to do JS. If you start a new project, or you want to change the language then you move forward with the new language and slowly replace or just keep using the old JS.
> (Oh, am I tired of Promises)
Insted of just adding Await and Defer, when you switch to ClojureScript, you will get full CSP semantics, full first class channels, essentially what Go offers on the server.
Check out this blog, it mostly talks about the difference between different ways of front end programming, callbacks, CSP and so on: http://swannodette.github.io/
The one limitation I see with using await-defer or generators for async code, instead of promises, is that you lose the ability to specify multiple continuations to your async call. With a promise, you can always continue your synchronous work after setting your `then` handler.
Nice. I am currently working on providing primitives in JavaScript for writing async code without callbacks or chained functions. Added a link (http://jspipe.org) to that page.
More like: "This shows us how desirable it is to try and circumvent writing JavaScript, despite how important the Web is."
I'm not saying JavaScript is good or bad. Just saying that there is certainly a strong desire to not write it, as evidenced by this long list of transpile languages.
That's the glass-half-empty look at it. I look at it the opposite: it's rather easy to write a web application in any language you want. Unlike the native platforms (especially on mobile). In fact, the web community puts a lot of effort into making it easy for you to use an altjs language.
My main gripe isn't Javascript (though I agree, argh), it's the DOM. So yeah, I could choose to write X instead of Javascript, but I still have the most painful of the pain points to deal with.
What's wrong with the DOM? I feel like jQuery abstracts away most of the pain. Do you mean the API itself, or in the abstract sense of laying out web apps like documents?
