View mode: basic / threaded / horizontal-split · Log in · Help
April 20, 2010
JavaScript is the "VM" to target for D
A new moon (downunder) brings time for new D discussion topic :-)

Myself having a long time interest in "webapp" development and given 
that the web client platform is tied to having only JavaScript 
ubiquitously available (i.e. in the browser) and having tried a zillion 
OOP wrappers and frameworks for JavaScript that don't scale for 
significantly-sized apps,

my current thinking seems to be aligning with others that JavaScript 
should be seen as the new "binary", albeit in text form, that HLLs 
should be compiling down to for "webapp" development.

Accordingly I would like to promote a discussion on the suitability of 
D, perhaps even D1, as a HLL that could possibly compile down to 
JavaScript as a better candidate language compared to some of the other 
contenders.

To set some context for this discussion consider that GWT (Google Web 
Toolkit) is basically Java transmutated into JavaScript "object code" 
which is ultimately deployed on the client though development is 
facilitated via a Java IDE.

Also there is Haxe, http://haxe.org/ , which reminds me of D1, it being 
small and concise, and, well, rather than my words, let me copy what the 
intro page says:

haXe (pronounced as hex) is an open source programming language.

While most other languages are bound to their own platform (Java to the 
JVM, C# to .Net, ActionScript to the Flash Player), haXe is a 
multiplatform language.

It means that you can use haXe to target the following platforms :

    * Javascript : You can compile a haXe program to a single .js file. 
You can access the typed browser DOM APIs with autocompletion support, 
and all the dependencies are resolved at compilation time.
    * Flash : You can compile a haXe program to a .swf file. haXe can 
compile for Flash Players 6 to 10, with either "old" Flash<8 API or 
newest AS3/Flash9+ API. haXe offers very good performance and language 
features to develop Flash content.
    * NekoVM : You can compile a haXe program to NekoVM bytecode. This 
can be used for server-side programming such as dynamic webpages (using 
mod_neko for Apache) and also for commandline or desktop applications, 
since the NekoVM can be embedded and extended with some other DLL.
    * PHP : You can compile a haXe program to .php files. This enable 
you to use a high level strictly-typed language such as haXe while 
keeping full compatibility with your existing server platform and libraries.
    * C++ : You can now generate C++ code from your haXe source code, 
with the required Makefiles. This is very useful for creating native 
applications, for instance in iPhone development.

The idea behind haXe is to let the developer choose the best platform to 
do a given job. In general, this is not easy to do because every new 
platform comes with its own programming language. What haXe provides to 
you is :

    * a standardized language with many good features
    * a standard library (including Date, Xml, Math...) that works the 
same on all platforms
    * platform-specific libraries : the full APIs for a given platform 
are accessible from haXe


So I guess the thrust of my topic tonight is, could D somehow reinvent 
itself to fame and fortune in the high-level-language-for-JavaScript space?

Cheers and beers as usual,

Justin Johansson
April 20, 2010
Re: JavaScript is the "VM" to target for D
On 4/20/2010 8:50 AM, Justin Johansson wrote:
> A new moon (downunder) brings time for new D discussion topic :-)
>
> Myself having a long time interest in "webapp" development and given
> that the web client platform is tied to having only JavaScript
> ubiquitously available (i.e. in the browser) and having tried a zillion
> OOP wrappers and frameworks for JavaScript that don't scale for
> significantly-sized apps,
>
> my current thinking seems to be aligning with others that JavaScript
> should be seen as the new "binary", albeit in text form, that HLLs
> should be compiling down to for "webapp" development.
>
> Accordingly I would like to promote a discussion on the suitability of
> D, perhaps even D1, as a HLL that could possibly compile down to
> JavaScript as a better candidate language compared to some of the other
> contenders.
>
> To set some context for this discussion consider that GWT (Google Web
> Toolkit) is basically Java transmutated into JavaScript "object code"
> which is ultimately deployed on the client though development is
> facilitated via a Java IDE.
>
> Also there is Haxe, http://haxe.org/ , which reminds me of D1, it being
> small and concise, and, well, rather than my words, let me copy what the
> intro page says:
>
> haXe (pronounced as hex) is an open source programming language.
>
> While most other languages are bound to their own platform (Java to the
> JVM, C# to .Net, ActionScript to the Flash Player), haXe is a
> multiplatform language.
>
> It means that you can use haXe to target the following platforms :
>
> * Javascript : You can compile a haXe program to a single .js file. You
> can access the typed browser DOM APIs with autocompletion support, and
> all the dependencies are resolved at compilation time.
> * Flash : You can compile a haXe program to a .swf file. haXe can
> compile for Flash Players 6 to 10, with either "old" Flash<8 API or
> newest AS3/Flash9+ API. haXe offers very good performance and language
> features to develop Flash content.
> * NekoVM : You can compile a haXe program to NekoVM bytecode. This can
> be used for server-side programming such as dynamic webpages (using
> mod_neko for Apache) and also for commandline or desktop applications,
> since the NekoVM can be embedded and extended with some other DLL.
> * PHP : You can compile a haXe program to .php files. This enable you to
> use a high level strictly-typed language such as haXe while keeping full
> compatibility with your existing server platform and libraries.
> * C++ : You can now generate C++ code from your haXe source code, with
> the required Makefiles. This is very useful for creating native
> applications, for instance in iPhone development.
>
> The idea behind haXe is to let the developer choose the best platform to
> do a given job. In general, this is not easy to do because every new
> platform comes with its own programming language. What haXe provides to
> you is :
>
> * a standardized language with many good features
> * a standard library (including Date, Xml, Math...) that works the same
> on all platforms
> * platform-specific libraries : the full APIs for a given platform are
> accessible from haXe
>
>
> So I guess the thrust of my topic tonight is, could D somehow reinvent
> itself to fame and fortune in the high-level-language-for-JavaScript space?
>
> Cheers and beers as usual,
>
> Justin Johansson

I've done a significant amount of web-app development myself, but to me 
this seems like a bad idea.  If I want to sit down and write something 
quickly and don't care about performance, JavaScript or Haxe are great 
languages to do it in and can be more productive than D.  However, even 
the best JavaScript vm's (like V8) are on average 10x slower than C++/D. 
 So if performance matters, I always chose D.

If I write D to run on a JavaScript VM, I lose both the productivity of 
JavaScript and the speed of D.
April 20, 2010
Re: JavaScript is the "VM" to target for D
Eric Poggel wrote:
>>
>>
>> So I guess the thrust of my topic tonight is, could D somehow reinvent
>> itself to fame and fortune in the high-level-language-for-JavaScript 
>> space?
>>
>> Justin Johansson
> 
> I've done a significant amount of web-app development myself, but to me 
> this seems like a bad idea.  If I want to sit down and write something 
> quickly and don't care about performance, JavaScript or Haxe are great 
> languages to do it in and can be more productive than D.  However, even 
> the best JavaScript vm's (like V8) are on average 10x slower than C++/D. 
>  So if performance matters, I always chose D.
> 
> If I write D to run on a JavaScript VM, I lose both the productivity of 
> JavaScript and the speed of D.

Thanks for the reality check; probably it's a silly idea.  Nevertheless 
I'm glad to have inquired as, even though I like the idea of optional 
static typing in Haxe, I'll be reconsidering whether using Haxe in a new 
web project is a good idea also.  One thing I can't figure out is why 
Haxe is not as popular as it "should" be.  Maybe for similar reasons as 
you say?

Cheers
Justin
April 21, 2010
Re: JavaScript is the "VM" to target for D
"Justin Johansson" <no@spam.com> wrote in message 
news:hqk7ve$2ouj$1@digitalmars.com...
>
> my current thinking seems to be aligning with others that JavaScript 
> should be seen as the new "binary", albeit in text form, that HLLs should 
> be compiling down to for "webapp" development.
>
>
> Also there is Haxe, http://haxe.org/ , which reminds me of D1, it being 
> small and concise, and, well, rather than my words, let me copy what the 
> intro page says:
>

I believe *very* strongly in using a REAL language that then gets compiled 
down to worthless crap like PHP, ActionScript, etc., whenever such worthless 
crap platforms are necessary. Which is, of course, necessary FAR too often 
when you do web development, as I do.

I use Haxe for any and all PHP and Flash development and I will *never* go 
back to direct PHP or ActionScript. Never, ever, ever, ever, EVER! PHP in 
particular is by far the absolute worst, most pathetic language *and* 
platform (PHP's idiocy extends far beyond the language itself) ever 
conceived and actually used in the real world (Ok, I'm not counting old 
mainframes). ActionScript2 and the Flash8 API are barely any better (and 
unfortunately, if you want *real* compatibility, AS3/Flash9 aren't really as 
much of an option as all the kiddie trend-whores that have infected the 
programming world like the pretend.) So yea, count me as one person who does 
go the Haxe route (including HaxeIgniter), swears by it (quite literally, as 
you can see ;) ), and will *never* look back.

D, or at least something closer to D, would be FAR better than Haxe, though. 
In fact even though I just raved about Haxe, I actually hate Haxe. Yes, it's 
vastly superior to using direct PHP/AS, so much so that IMO there's no good 
reason ever to use PHP/AS directly. But Haxe is still crap anyway. Just off 
the top of my head, and I know I'm forgetting a lot:

- The documentation is god-awful.

- The allegedly-strong type system has one hell of a blatant and idiotic 
hole that probably won't get fixed: 
http://code.google.com/p/haxe/issues/detail?id=105

- Haxe has no real metaprogramming, and it's "generics" make C#'s gimped 
generics ( 
http://blog.dev-scene.com/abscissa/2008/03/10/i-want-my-iarithmetic/ ) look 
practically super-powered. (Granted, at least you can add two generic types 
in Haxe unlike C#, but in other ways they really are very, very limited.)

- The syntax for defining properties is absolutely horrid, and will cause 
severe optical hemorrhaging in anyone who values DRY. Although, Java-type 
people who enjoy seeing how many millions of lines of useless boilerplate 
garbage their IDE can spit out while still accomplishing practically nothing 
will probably love it.

- Everything must be in a class (or an enum)...for no apparent reason other 
than, apparently, to ape Java (and why anyone would ever want to ape Java is 
beyond me).

- There are a lot of PITA PHP idiosyncrasies that Haxe doesn't really shield 
you from. (Example: Some dumbass sysadmin decided your PHP5 installation 
should have magic quotes enabled by default? You, as the app developer, 
still have to work around it. Haxe theoretically could automatically add 
code that detects and reverses it as best as possible. But it doesn't.)

- I'm beginning to question the sanity of the guy in charge: 
http://code.google.com/p/haxe/issues/detail?id=106 (He blatantly breaks 
basic browser behavior for quite obviously no benefit whatsoever, he's 
spoon-fed a trivial fix, and...he passes it off as a user issue? WTF? 
Granted, it's not a major issue, but seriously, the lack of logic involved 
in coming to a conclusion like that just stuns me.)

But yea, while Haxe has its issues, I'm still a huge proponent of the idea 
of compiling real languages does to the garbage ones when you're forced to 
use a garbage one. In fact, my Goldie project ( 
www.dsource.org/projects/goldie ) has that sort of thing as one of it's 
original motivating factors and one of its ultimate goals.

However, I'm not convinced that compiling a full real language down to 
browser-client-JavaScript is a great idea...

For one thing, something like that is going to have overhead (and JS is 
sluggish enough already), unless it goes the Haxe route and actually designs 
the language around the idea of very easy/direct translation to the base 
language, which of course, limits how much of an improvement the new 
language can actually be.

The other issue I have with it is that I feel *VERY* strongly that 
JavaScript should *only be used sparingly*. Specifically, any web app 
*should* be designed and built from the start without any use of JavaScript 
whatsoever. This is possible 99.99% of the time (In fact, most of the times 
people think they need JS for something, they're full of crap. Like button 
rollover images, for instance: CSS handles rollover images FAR better than 
any JS engine ever will.) *Then* and *only* then, you can toss in little 
snippets of optional JS here and there to clean up various things for people 
who choose to have JS enabled. I know I'm in the minority on this, but I 
feel very strongly that that's the *only* good way to design a web app, 
anything else is just plain crap design. (Correction: there's no such thing 
as a good way to design a web app, because "good web app" is a blatant 
contradiction of terms since the web is an absolute shit platform for 
applications *period*. (/me waits for Adam Ruppe's DWS with baited breath 
:) ) So I guess I should have said that's the *closest* it can possibly get 
to being a "good" way to design a web app.)

Whew!
...
Can you tell I've been itching to get all that off my chest for quite some 
time? ;)
April 21, 2010
Re: JavaScript is the "VM" to target for D
Nick Sabalausky:
> I use Haxe for any and all PHP and Flash development

I have an OT question: Haxe and similar things add another layer between the code you write and the program that gets run. Isn't this extra distance (and the semantic adaptations it requires) cause of problems? For example when you put a bug in your Haxe code.

Bye,
bearophile
April 21, 2010
Re: JavaScript is the "VM" to target for D
"Nick Sabalausky" <a@a.a> wrote in message 
news:hqljod$cad$1@digitalmars.com...
> "Justin Johansson" <no@spam.com> wrote in message 
> news:hqk7ve$2ouj$1@digitalmars.com...
>>
>> my current thinking seems to be aligning with others that JavaScript 
>> should be seen as the new "binary", albeit in text form, that HLLs should 
>> be compiling down to for "webapp" development.
>>
>>
>
> I believe *very* strongly in using a REAL language that then gets compiled 
> down to worthless crap like PHP, ActionScript, etc., whenever such 
> worthless crap platforms are necessary. Which is, of course, necessary FAR 
> too often when you do web development, as I do.
>

Of course, I also believe very strongly that if a language or platform is 
crap (browser-JavaScript), then the *real* correct solution is to fix or 
replace it rather than just paint over it with another layer. But, hey! 
That's not how we do things here in the internet technology world! Just slap 
on another half-baked design to cover up last year's half-baked design! 
Repeat ad infinitum. (Am I the only one that learned anything from the old 
"There was an old lady who swallowed a..." nursery rhyme?).
April 21, 2010
Re: JavaScript is the "VM" to target for D
On Tue, Apr 20, 2010 at 09:18:45PM -0400, Nick Sabalausky wrote:
> I believe *very* strongly in using a REAL language that then gets compiled 
> down to worthless crap like PHP, ActionScript, etc., whenever such worthless 
> crap platforms are necessary. Which is, of course, necessary FAR too often 
> when you do web development, as I do.

If you are stuck in a situation where you need to do a web app, but are
allowed to use compiled CGI binaries, I've written cgi and mysql modules
for D2 over the last few weekends. (Have to do almost everything D related
purely on weekends to satisfy my contract's copyright assignment clause. Ugh.)

They are in here:
http://arsdnet.net/dcode/

The mysql module sucks, but it works and already beats the crap out of PHP.

If CGI is an option, D rocks for it. If not, I know your pain :( (Though
hopefully ending soon - I've been trying to sell my clients on D, and the
big one seems excited about it! With his dedicated server, using cgi is
easy. Very cool.)

> The other issue I have with it is that I feel *VERY* strongly that 
> JavaScript should *only be used sparingly*. Specifically, any web app 
> *should* be designed and built from the start without any use of JavaScript 
> whatsoever.

Amen!

> (/me waits for Adam Ruppe's DWS with baited breath :) )

Me too. I haven't been able to work on it for months now, but this big paying
project is about to launch, so maybe my time will finally free up soon.

-- 
Adam D. Ruppe
http://arsdnet.net
April 21, 2010
Re: JavaScript is the "VM" to target for D
"bearophile" <bearophileHUGS@lycos.com> wrote in message 
news:hqlko7$don$1@digitalmars.com...
> Nick Sabalausky:
>> I use Haxe for any and all PHP and Flash development
>
> I have an OT question: Haxe and similar things add another layer between 
> the code you write and the program that gets run. Isn't this extra 
> distance (and the semantic adaptations it requires) cause of problems? For 
> example when you put a bug in your Haxe code.
>

Sometimes I get errors from the haxe compiler, and sometimes I get errors 
from the PHP runtime. But if I weren't using Haxe then all the errors would 
be from the PHP runtime, so I count that as a net improvement.

About the only problem I've seen from the extra layer of abstraction is that 
the PHP runtime errors show the file/line of haxe's php output instead of 
the file/line in the original haxe source. So you have to go to the php file 
that haxe generated to see where the problem occurred. However:

1. At worst, that's only a minor inconvenience.

2. It's not a completely insurmountable problem. I can think of lots of ways 
that problem could be mitigated, if not outright eliminated. For instance, 
Haxe could output a file-by-file/line-by-line mapping from the php output to 
the haxe source and another program could take the that info and the error 
message and translate back. Or PHP could add some feature or features to 
help in that regard (ie, something comparable to how D's "#line" feature 
exists to make it easy for a theoretical D preprocessor to not screw up the 
line numbers output by DMD). Or, in some cases, Haxe could just tighten up 
it's static analysis and not let the issue get to the run-time stage.

Does that answer your question?
April 21, 2010
Re: JavaScript is the "VM" to target for D
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message 
news:mailman.54.1271813929.3522.digitalmars-d@puremagic.com...
> On Tue, Apr 20, 2010 at 09:18:45PM -0400, Nick Sabalausky wrote:
>> I believe *very* strongly in using a REAL language that then gets 
>> compiled
>> down to worthless crap like PHP, ActionScript, etc., whenever such 
>> worthless
>> crap platforms are necessary. Which is, of course, necessary FAR too 
>> often
>> when you do web development, as I do.
>
> If you are stuck in a situation where you need to do a web app, but are
> allowed to use compiled CGI binaries, I've written cgi and mysql modules
> for D2 over the last few weekends. (Have to do almost everything D related
> purely on weekends to satisfy my contract's copyright assignment clause. 
> Ugh.)
>
> They are in here:
> http://arsdnet.net/dcode/
>
> The mysql module sucks, but it works and already beats the crap out of 
> PHP.
>

Cool.

I just found out earlier today that my web host ( 100megswebhosting.com ) 
allows arbitrary CGI (ie this is the host *my* site is on, not any of my 
clients unfortunately...but I've been very happy with my host for a long 
time so I've been thinking about trying to go with either their reseller 
program, or at least affiliate program, for future clients, assuming the 
client will go for it. They seem to usually have their own hosting already 
though, and then I have to put up with whatever hosting idiots they decided 
to hire :/ ). But anyway, my host is x86 linux, so I probably won't have to 
deal with cross-compiling. Unfortunately, they don't do any sort of FastCGI, 
though :(

But I've been wanting to whip up my own blog^H^H^H^Hpersonal-site software 
for awhile now, so I'm deciding between D and Haxe. I love D, of course, but 
Haxe has HaxeIgniter, a rails-like framework that I'm already neck-deep into 
for one of my clients. I'd like to make a rails-like framework for D, but 
that would take time, so I think I'm leaning towards "Haxe for now, and 
re-write in D if I ever get a chance."

> If CGI is an option, D rocks for it. If not, I know your pain :( (Though
> hopefully ending soon - I've been trying to sell my clients on D, and the
> big one seems excited about it! With his dedicated server, using cgi is
> easy. Very cool.)
>

/me jealous ;)

>> The other issue I have with it is that I feel *VERY* strongly that
>> JavaScript should *only be used sparingly*. Specifically, any web app
>> *should* be designed and built from the start without any use of 
>> JavaScript
>> whatsoever.
>
> Amen!
>

You might be interested in this. Maybe you've already known but I just came 
across it a few weeks ago:
http://www.anybrowser.org/campaign/

The FAQ is pretty old, and although it seems to frowns on mandatory JS it's 
not particularly clear about that point (it mainly focuses on 
browser-choice), but I thought it was pretty cool. Yet another of of my 
"5,000,000 projects that I want to do, if I ever have the time" is to start 
an updated version of that which, among other things, emphasizes not trying 
to cram unnecessary JS down people's throats.

>> (/me waits for Adam Ruppe's DWS with baited breath :) )
>
> Me too. I haven't been able to work on it for months now, but this big 
> paying
> project is about to launch, so maybe my time will finally free up soon.
>

I have to say, I've always been slightly jealous that you beat me to the 
proof-of-concept ;)  I swear, we both came to the same general design idea 
independently. I keep spreading myself too thin though.
April 21, 2010
Re: JavaScript is the "VM" to target for D
On 4/20/2010 6:26 PM, Justin Johansson wrote:
> Eric Poggel wrote:
>>>
>>>
>>> So I guess the thrust of my topic tonight is, could D somehow reinvent
>>> itself to fame and fortune in the high-level-language-for-JavaScript
>>> space?
>>>
>>> Justin Johansson
>>
>> I've done a significant amount of web-app development myself, but to
>> me this seems like a bad idea. If I want to sit down and write
>> something quickly and don't care about performance, JavaScript or Haxe
>> are great languages to do it in and can be more productive than D.
>> However, even the best JavaScript vm's (like V8) are on average 10x
>> slower than C++/D. So if performance matters, I always chose D.
>>
>> If I write D to run on a JavaScript VM, I lose both the productivity
>> of JavaScript and the speed of D.
>
> Thanks for the reality check; probably it's a silly idea. Nevertheless
> I'm glad to have inquired as, even though I like the idea of optional
> static typing in Haxe, I'll be reconsidering whether using Haxe in a new
> web project is a good idea also. One thing I can't figure out is why
> Haxe is not as popular as it "should" be. Maybe for similar reasons as
> you say?
>
> Cheers
> Justin

I haven't used Haxe, but why reconsider using it?

I should've also clarified that I'm usually more productive in 
JavaScript for small projects because it usually takes less code for the 
same thing, but more so in D for large ones due to the benefits of 
static typing.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home