W dniu 21.08.2013 01:43, Ramon pisze:
I agree with those who are against it.

For a variety of reasons, one of them being that, yes, anything that
produces javasc*t does a) recognize js and b) embold and support it.

Web pages are/should be about *content* not about eye candy and gadgets.
Furthermore, increasingly many (like myself) have js filters, often in
"brutal" mode (cutting out *all* js and enabling it expressly if
needed/wished).

It's not about simple web pages with fancy gadgets. It's about RIAs.

The real solution isn't to add one more way to the existing 3 gazillion
ways for js but to create a real alternative.

This is unreal. Consider a business case: your employer wants some dynamic behavior on a web page (and it must work on IE6).

Seen from D's perspective a D interpreter would be a start. Although,
frankly, most web hackers won't like it; it's too unfriendly and hard,
they want some kind of web basic (which js happens to be).

They will still use JS. I don't want to replace JS, because I want to support existing browsers.

And why and what for? HTML5 is rich enough. If I want to put serious
computing work on the client I'd rather put it in a web server (written
in D). And if I just want to put fancy blabla into a browser I can chose
from 2,5 gazillion toys.

What about Facebook?

But I rather have RIAs in mind. For example: http://www.smartclient.com/#showcaseApp . Among the others are ExtJS, GWT, qooxdoo, etc.

In this case code doesn't need to be very fast. It just need to be reliable and _maintainable_. All I currently want is using those RIA libraries from D code. This should give me huge productivity boost when writing _complex_ web applications.

Another case is WebGL and online games. I'd rather go to hell than write and maintain 100k lines of code in JS.

Even if you do not see a reason for it, there _is_ a demand for it. And money behind it.

Reply via email to