April 21, 2010
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
Nick Sabalausky:
> Does that answer your question?

Yes, thank you,
bearophile
April 22, 2010
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
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
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
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
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
"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
"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
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