Experiments with emscripten and D

[Piotr Szturmaj]

W dniu 17.08.2013 23:05, Gambler pisze:
> On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:
>> W dniu 17.08.2013 16:42, Gambler pisze:
>>> On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
>>>> bearophile:
>>>>> Piotr Szturmaj:
>>>>> I have found some related activity from Rust people:
>>>>> https://github.com/mozilla/rust/issues/2235
>>>>> https://github.com/Yoric/Mozilla-Student-Projects/issues/33
>>>>> https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
>>>>>
>>>>> Once your work is more more completed, the dlang site could show (in a
>>>>> sub-page) the compiler that compiles the online examples of the docs
>>>>> that's able to produce html+JS on the fly from the D code written in
>>>>> the
>>>>> browser.
>>>>
>>>> Yes, and it could be used to write rich web applications (which is the
>>>> reason I'm working on it). JavaScript certainly wasn't created for big
>>>> codebases...
>>>
>>> Never understood the excitement about things like these. Yes, it's
>>> somewhat interesting and technically impressive, but in the end, the
>>> only language that benefits here *is* JavaScript. And it's already
>>> spreading like cancer. Why help it if you don't like it?
>>>
>>> If even 1/10th of the effort spent on compile-everything-to-JS projects
>>> was directed towards properly bringing other languages into the browser
>>> land, the web would be a much better place now.
>>
>> It's not about helping JavaScript. It's about using another language to
>> do client side scripting. I hate JS, I really don't like to write bigger
>> applications in it.
>>
>> What happens when you forget a semicolon or a comma? Or make some typos?
>> It silently breaks. I don't care if there are tools to help with it.
>> It's still a mess. Did you see WAT
>> (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here
>> are some examples of JS "additions" which WAT demonstrated:
>>
>> [] + [] // yields empty string
>> [] + {} // [object Object]
>> {} + [] // 0
>> {} + {} // NaN
>>
>> Seriously, WTF!
>
> WAT is one of my favorite language talks of all times. So we're on the
> same page here. But I don't think compiling D to JavaScript is a viable
> long-term solution.
>
> 1. The more languages compile to JS, the more powerful it becomes and
> the harder it will be to replace JS with something better. People will
> spend more money on optimizing its (not D's) performance, developing its
> (not D's) APIs for stuff like sound and graphics. This is already
> happening. I recently interviewed a junior developer for a position that
> had nothing to do with JavaScript. At some point during the interview he
> said: "JavaScript is the future of everything". Yeah, it's the actual
> phrasing he used. That's what some people believe in.
>
> 2. Compiling things to an intermediate language creates a whole host of
> new problems you don't have originally. How do you debug? How do you
> print an accurate stack trace?  Etc.

This is known problem and many JS-like languages use "source maps" to 
solve it.

> 3. Even if the tool-chain is perfect, a lot of real work in the browser
> is done by calling APIs. If those APIs are designed for JavaScript,
> their usage will not be idiomatic inside translated code unless you
> manually create wrappers.

Yes, but we don't want to be strictly idiomatic. We just want to call JS 
code (modify the DOM, enable a button, or interface to JS widget 
toolkit). Idiomatic JS code more or less boils down to creating objects 
and calling functions. GWT is another example of such effort. It 
translates Java code to JS. "GWT is used by many products at Google, 
including AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, 
Blogger." - from GWT website.

> It would still be fine if the whole thing hand some kind of gradual
> upgrade path that led to using pure D, but I don't see such path.

There must be a first step :-)

>> And again, I don't want to write in it, but I _must_ use it. I just want
>> to use another language that translates to JS. There are many of them
>> already. Still, no one is even close to D in its usefulness.
>
> My personal strategy to mitigate the horrors of JavaScript is to use
> progressive enhancement and write small, targeted JS libraries that are
> invoked declaratively (i.e. you include them, but then it's all about
> HTML markup and there is no application-specific JS). Contrary to
> popular opinion, this approach is capable of creating very efficient and
> very dynamic websites.

This approach is limiting in some scenarios. Think about RIAs and 
interfacing to existing JS libraries.

>> The whole problem is that you need to write a web applications _now_,
>> when the only supported languages for the web is JS. You really don't
>> have a choice. Even if other languages could be widely supported from
>> today, you'd still have to support older browsers. This means JS will
>> stay in for another couple of years.
>
> If things don't change trajectory, I'm afraid JS will not just "stay for
> a couple of years". It will become de-facto standard for server-side web
> computing and displace all other languages in that domain. In the
> company I work for, there is already a number of people calling to
> rewrite all the web app for Node. I don't see a single tangible benefit
> coming out of it if, though. It would be a maintainability nightmare.

Yes it would be a mess. But, IMHO even if great number of people talk 
about "JS everywhere" it's not going to happen. Nobody wants to rewrite 
tens of thousands lines of code if it already works. Why create the same 
product multiple times? I understand rewriting JS to other lang, but not 
the other way.

>>>> The other big advantage would having one codebase shared between server,
>>>> browser (including mobile) and desktop apps.
>>>
>>> Yes, in theory. In practice, this is just something Node.JS people came
>>> up with for advocacy of their platform. It's false. In-browser
>>> JavaScript has so many constraints imposed on it that it will never
>>> behave exactly like server-side code. (For example, your gist doesn't
>>> work in IE. Not that I use IE normally, but you get my point.)
>>
>> Obviously, you can't share every possible code. It's about sharing the
>> cross cutting parts. Imagine an application with a server, web frontend
>> and desktop frontend. With shared codebases, you could write one client
>> code. Just use the same abstractions for the web and for the desktop.
>> Then you can create similar interfaces from the same codebase. It's a
>> huge win. Duplicating efforts is tiresome, error prone and obviously
>> takes time.
>
> This is another reason why I try to design everything using progressive
> enhancement. It results in very little duplication between client-side
> and server-side code. Each side has a clearly designated purpose and
> they rarely overlap. I wish there were more JS libraries that encourages
> this kind of development style, though.

For client/server this is a regular approach if you don't take a desktop 
frontend into account. Otherwise you'd have two client-side frontends, 
desktop and the web and they must overlap.

>>> Worse, no one took time to actually design a sensible model of
>>> interaction between server and the client for a "shared" codebase. It's
>>> all a jumbled mess of ad-hoc implementations and subverted web
>>> technologies that were originally meant for an entirely different
>>> purpose. I sometimes see JS examples like this:
>>>
>>> if (imOnTheServer){
>>>       //do one thing
>>> } eles {
>>>       //do another thing
>>> } //Yay, "shared" code!!!
>>>
>>> Every time I do, I get the urge to abandon programming and change my
>>> occupation.
>>
>> This is not a new idea. Morfik is a webdev tool that automatically
>> splits your code to the server and JS. I remember it was available in
>> 2005. Also, there is Opa language.
>>
>> I don't see anything wrong with cross platform code. For D example, I'd
>> imagine it could look like this:
>>
>> void showMsg(string s) {
>>      version (JS)
>>          js.alert(s);
>>      else
>>          YourDesktopWidgetToolkit.showMessageDialog(s);
>> }
>>
>> void main() {
>>      showMsg("hello world");
>> }
>>
>> Compiled with a regular compiler and GTK, will show a dialog.
>> Compiled with emscripten-like compiler will show a message in the browser.
>
> What you're talking about is compiling the same code to run in the
> browser and as a standalone client. But that's not the same as running
> the same code on the client and server side, because in that case there
> would be message sender code (on the server) and message receiver code
> (on the client). They would need to communicate in some manner. That's
> not a trivial problem to solve.

I don't know, but you probably meant automatic splitting a single 
function to client and server code. This is not what I want (yet ;-)). 
Communication would be done regular way such as this:

ran in the web browser:

version(JS)
string getData(string id) {
     // this would need async to blocking code transform
     return js.ajaxRequest("/getData", id);
}

ran on the server:

void handleRequest(Request req) {
     if (req.relativeUrl == "/getData") {
	auto data = db.getData(req.requestData /* id */);
         req.respond(data);
     }
}

Nothing magical here.