Experiments with emscripten and D

Gambler fake at feather.org.ru
Sat Aug 17 14:05:02 PDT 2013


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.

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.

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.

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

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

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

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


More information about the Digitalmars-d mailing list