View mode: basic / threaded / horizontal-split · Log in · Help
April 21, 2010
Re: JavaScript is the "VM" to target for D
On Tue, Apr 20, 2010 at 11:16:12PM -0400, Eric Poggel wrote:
> 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.

I've been finding D can do small things really effectively too; you
can even write it in a pretty javascriptish style, using closures
returning functions and associative arrays all over the place.

I wrote an implementation of the Javascript DOM in D2 as well:
http://arsdnet.net/dcode/dom.d

To use:
	auto document = new Document(std.file.readText("file.html"));

	auto e = document.getElementById("blah");
	e.attribute = "name";

And you have the whole innerHTML, outerHTML, innerText, etc. etc. too.

Run it through ddoc for more info.


My original idea with it was just have a similar API so I can copy/paste
code between D and JS with minimal modification between the two, but I've
been going wild with it on the server side too, parsing custom extensions
to html to make my output, or stripping useless junk out of html fetched
off the web. Infinitely more useful to me than std.xml, even though I
cared more about looking like the browser than following the standard.


-- 
Adam D. Ruppe
http://arsdnet.net
April 21, 2010
Re: JavaScript is the "VM" to target for D
Nick Sabalausky:
> Does that answer your question?

Yes, thank you,
bearophile
April 22, 2010
Re: JavaScript is the "VM" to target for D
I don't think javascript is suited for this purpose, but perhaps silverlight 
/ moonlight is. A D compiler targetting the CoreCLR could be big, depending 
on how this platform takes off.
April 22, 2010
Re: JavaScript is the "VM" to target for D
Justin Johansson wrote:

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

CoffeeScript looks quite interesting : 
http://jashkenas.github.com/coffee-script/ and based on a similar idea to yours.

Regards
Alex
April 22, 2010
Re: JavaScript is the "VM" to target for D
On Apr 22, 10 14:52, Lutger wrote:
> I don't think javascript is suited for this purpose, but perhaps silverlight
> / moonlight is. A D compiler targetting the CoreCLR could be big, depending
> on how this platform takes off.

D.NET?
April 23, 2010
Re: JavaScript is the "VM" to target for D
Tue, 20 Apr 2010 21:35:03 -0400, bearophile wrote:

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

Well, it would be slow if it was run in an interpreter written in those 
languages, but it's compiled. People run interpreteres on top of 
javascript these days without any complaints.
April 23, 2010
Re: JavaScript is the "VM" to target for D
Tue, 20 Apr 2010 21:38:57 -0400, Nick Sabalausky wrote:

> "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?).

The problem is, even if you come up with a superior alternative, there's 
a lots of politics in the way. Some (all?) enterprises expect to make 
profits from their old technology and push it further in all possible 
ways. It would take years or decades to replace anything without a killer 
application or two.

They only recently started to improve Javascript performance. It's not 
that bad actually. And the code can be distributed in cross-platform way 
across the network. They have low loading times unlike applets - a big 
win. E.g. I've started to use google docs, the UI is nice and doesn't 
crash unlike buggy native office applications.
April 24, 2010
Re: JavaScript is the "VM" to target for D
"retard" <re@tard.com.invalid> wrote in message 
news:hqt9pa$2sgv$5@digitalmars.com...
> Tue, 20 Apr 2010 21:35:03 -0400, bearophile wrote:
>
>> 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.
>
> Well, it would be slow if it was run in an interpreter written in those
> languages, but it's compiled. People run interpreteres on top of
> javascript these days without any complaints.

No wonder the web's become so absurdly slow.

-------------------------------
Not sent from an iPhone.
April 24, 2010
Re: JavaScript is the "VM" to target for D
"retard" <re@tard.com.invalid> wrote in message 
news:hqtaa3$307r$1@digitalmars.com...
> Tue, 20 Apr 2010 21:38:57 -0400, Nick Sabalausky wrote:
>
>> "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?).
>
> The problem is, even if you come up with a superior alternative, there's
> a lots of politics in the way. Some (all?) enterprises expect to make
> profits from their old technology and push it further in all possible
> ways. It would take years or decades to replace anything without a killer
> application or two.
>

If some idiot wants to cling onto a piece of crap tech that never should 
have taken off to begin with, I see no good reason to help enable them by 
staying on the bandwagon.

> They only recently started to improve Javascript performance. It's not
> that bad actually. And the code can be distributed in cross-platform way
> across the network. They have low loading times unlike applets - a big
> win. E.g. I've started to use google docs, the UI is nice and doesn't
> crash unlike buggy native office applications.

For anything non-trivial, JS loading times are terrible. Better than 
applets, yes, but compared to non-JS sites? Yes, it's *that* bad. And by 
"that" bad, I mean bad enough to qualify as a bad approach. And even if you 
really did need client-scripting (and the vast majority of the time, you 
don't), there are better ways to distribute cross-platform code across a 
network.

-------------------------------
Not sent from an iPhone.
April 24, 2010
Re: JavaScript is the "VM" to target for D
KennyTM~ wrote:
> On Apr 22, 10 14:52, Lutger wrote:
>> I don't think javascript is suited for this purpose, but perhaps 
>> silverlight
>> / moonlight is. A D compiler targetting the CoreCLR could be big, 
>> depending
>> on how this platform takes off.
> 
> D.NET?

D.NET (D.CLR), D.JVM, D.ECMAScript, anything except D.assembler would 
have a lot of market appeal.  I would hesitate at D.LLVM though as 
that's not where the "money" is, sadly (imho).

Thanks everybody for commenting; this thread could have some really good 
suggestions/outcomes if only these could be put into effect.

Justin Johansson
1 2 3 4 5
Top | Discussion index | About this forum | D home