www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - JavaScript is the "VM" to target for D

reply Justin Johansson <no spam.com> writes:
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 

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
Apr 20 2010
next sibling parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
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

 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.
Apr 20 2010
parent reply Justin Johansson <no spam.com> writes:
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
Apr 20 2010
parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
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.
Apr 20 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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
Apr 20 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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


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 


- 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? ;)
Apr 20 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Apr 20 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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?
Apr 20 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 Does that answer your question?


Yes, thank you,
bearophile
Apr 21 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
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.
Apr 23 2010
parent "Nick Sabalausky" <a a.a> writes:
"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.
Apr 23 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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?).
Apr 20 2010
parent reply retard <re tard.com.invalid> writes:
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.
Apr 23 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Apr 23 2010
parent reply retard <re tard.com.invalid> writes:
Fri, 23 Apr 2010 23:26:18 -0400, Nick Sabalausky wrote:


 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.


Really, such as? The largest problem by far has been to increase the 
global user base of these better technologies. The most widely used side 
virtual machines are for Flash and Javascript. Java had a good position, 
but now its dying away (on the client side). Silverlight has patent 
issues. What else do we have? You can't just run python or ruby in a 
windows box -- it doesn't have any runtime support.
Apr 24 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:

 What else do we have?


If I had my way, I'd just be rid of the virtual machine altogether. Simply run
native programs as a restricted user. (Indeed, I'd run the browser itself
with that restricted user, then let it create whatever processes it
wants, possibly stripping the child processes of more privileges.) The
operating system keeps it from doing anything evil.

We could define a new header in the HTTP request that lists the kind
of code you'd accept, from highest priority to lowest. For example, a
linux box with Wine might say:

X-Accept-Code: linux64; linux; win32

Meaning it'd prefer 64 bit linux apps, but if you don't offer that, it'll
settle for a generic 32 bit linux binary, or a Windows one if that fails.
The application is responsible for getting its own dependencies resolved -
if a dll load fails, download it from your site automatically.

A statically built standard library could simplify this for the programmer.


This gives the programmers huge freedom by taking the code
execution out of the browser's hands. Want to use a different language? Just
compile it, or bundle an interpreter for it. The accept-code header could
list various VMs the system has installed too.


If the browser didn't send the accept-code header, you have two options:
offer the binary as a download in a link or fallback on javascript. The
only problem with the former is users without the right security setup
probably shouldn't get used to approving binary downloads.


But, fixing the browser's create process powers are the direction I'd take
instead of adding more and more to their javascript interpreters. If they
can create the appropriately restricted token (which they should be running
under themselves anyway!), you're in business.

Seems like a lot less work than what they've put in the javascript, and
gives a lot more flexibility.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 24 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 24 Apr 2010 11:27:27 -0400, Adam D. Ruppe wrote:


 On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:

 What else do we have?


 
 If I had my way, I'd just be rid of the virtual machine altogether.
 Simply run native programs as a restricted user. (Indeed, I'd run the
 browser itself with that restricted user, then let it create whatever
 processes it wants, possibly stripping the child processes of more
 privileges.) The operating system keeps it from doing anything evil.
 
 We could define a new header in the HTTP request that lists the kind of
 code you'd accept, from highest priority to lowest. For example, a linux
 box with Wine might say:
 
 X-Accept-Code: linux64; linux; win32
 
 Meaning it'd prefer 64 bit linux apps, but if you don't offer that,
 it'll settle for a generic 32 bit linux binary, or a Windows one if that
 fails. The application is responsible for getting its own dependencies
 resolved - if a dll load fails, download it from your site
 automatically.
 
 A statically built standard library could simplify this for the
 programmer.
 
 
 This gives the programmers huge freedom by taking the code execution out
 of the browser's hands. Want to use a different language? Just compile
 it, or bundle an interpreter for it. The accept-code header could list
 various VMs the system has installed too.
 
 
 If the browser didn't send the accept-code header, you have two options:
 offer the binary as a download in a link or fallback on javascript. The
 only problem with the former is users without the right security setup
 probably shouldn't get used to approving binary downloads.
 
 
 But, fixing the browser's create process powers are the direction I'd
 take instead of adding more and more to their javascript interpreters.
 If they can create the appropriately restricted token (which they should
 be running under themselves anyway!), you're in business.
 
 Seems like a lot less work than what they've put in the javascript, and
 gives a lot more flexibility.


It gives different kinds of flexibility. The advantage of Javascript is 
easy interfacing with the DOM, the html document and all kinds of powers 
the browser is providing. The hypertext widget is actually pretty good at 
modelling user interfaces even though it's not optimal by modern 
standards.

The web applications have many contradicting goals and as a systems 
programmer you only have a narrow view which is from the pov of the 
traditional local applications. It's true that you can restrict 
privileges on operating system level. However, there is no cross-platform 
way of controlling this system manually on a proper abstraction level. If 
you fail to see the advantages of a middleware layer, you need to think 
more about it.
Apr 24 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 05:36:30PM +0000, retard wrote:

 It gives different kinds of flexibility. The advantage of Javascript is 
 easy interfacing with the DOM, the html document and all kinds of powers 
 the browser is providing.


Yeah, this came to mind only after I made the last post. The best solution
would probably be exposing the DOM objects to the child process somehow,
probably in a process similar to how browser plug-ins work.

Dynamically linking the DOM API to the application and passing opaque
pointers to and from it should do the trick, while insulating the downloaded
code from different browser implementations. Hopefully.

An alternative is interpreting Javascript through a pipe to manipulate
the webpage, but then the native code is kinda pointless.


 However, there is no cross-platform 
 way of controlling this system manually on a proper abstraction level. 


I don't know what you mean here... for security, there are no controls
on Javascript, you just get what the browser offers you and nothing more.
An OS level security restriction would be the same thing.
Apr 24 2010
parent retard <re tard.com.invalid> writes:
Sat, 24 Apr 2010 14:06:19 -0400, Adam D. Ruppe wrote:


 On Sat, Apr 24, 2010 at 05:36:30PM +0000, retard wrote:

 It gives different kinds of flexibility. The advantage of Javascript is
 easy interfacing with the DOM, the html document and all kinds of
 powers the browser is providing.


 
 Yeah, this came to mind only after I made the last post. The best
 solution would probably be exposing the DOM objects to the child process
 somehow, probably in a process similar to how browser plug-ins work.


The problem is, the most common object code interfaces on top of the OS 
have been optimized for C/C++ and that won't change anytime soon. The 
layer isn't really language agnostic. If favors C/C++ compatible 
languages.


 However, there is no cross-platform
 way of controlling this system manually on a proper abstraction level.


 
 I don't know what you mean here... for security, there are no controls
 on Javascript, you just get what the browser offers you and nothing
 more. An OS level security restriction would be the same thing.


The Javascript world is a bit naive today, but the middleware layer will 
likely become more complex later. You can see some security features in 
most browser plugins. Javascript will eventually replace these.
Apr 24 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 4/24/2010 09:27, Adam D. Ruppe wrote:

 If I had my way, I'd just be rid of the virtual machine altogether. Simply run
 native programs as a restricted user. (Indeed, I'd run the browser itself
 with that restricted user, then let it create whatever processes it
 wants, possibly stripping the child processes of more privileges.) The
 operating system keeps it from doing anything evil.


Congratulations, you just invented ActiveX.  I hope you like your
platform lockdown and your security vulnerabilities.


 X-Accept-Code: linux64; linux; win32


99% of web pages will offer just the win32 version.


-- 
Rainer Deyke - rainerd eldwood.com
Apr 24 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:

 Congratulations, you just invented ActiveX.  I hope you like your
 platform lockdown and your security vulnerabilities.


ActiveX controls don't run as a limited user account. That's the key here:
the entire browser should be running as a restricted user, and it creates
processes even more restricted than itself.

(When Google did this in Chrome, it was hailed as brilliant and innovative.
 I saw it as them finally doing what they should have been doing from the
 beginning.)


 99% of web pages will offer just the win32 version.


Meh, works for 91% of users.
Apr 24 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 24 Apr 2010 16:29:55 -0400, Adam D. Ruppe wrote:


 On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:

 Congratulations, you just invented ActiveX.  I hope you like your
 platform lockdown and your security vulnerabilities.


 
 ActiveX controls don't run as a limited user account. That's the key
 here: the entire browser should be running as a restricted user, and it
 creates processes even more restricted than itself.


How does this prevent platform lockdown?


 (When Google did this in Chrome, it was hailed as brilliant and
 innovative.
  I saw it as them finally doing what they should have been doing from
  the beginning.)


I haven't really seen the native client system used in any crucial real 
world site.


 

 99% of web pages will offer just the win32 version.


 
 Meh, works for 91% of users.


So, what technologies should the minority use then? Nothing? You're 
suggesting a cross-platform solution but you don't even believe yourself 
that it really should be cross-platform. That's pretty dishonest.
Apr 24 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 08:41:07PM +0000, retard wrote:

 How does this prevent platform lockdown?


It doesn't. I don't particularly care.


 I haven't really seen the native client system used in any crucial real 
 world site.


I'm referring to how they run browser components all as separate processes
with restricted tokens to improve stability and security, not the native
client, which I find completely useless.


 So, what technologies should the minority use then? Nothing? You're 
 suggesting a cross-platform solution but you don't even believe yourself 
 that it really should be cross-platform. That's pretty dishonest.


The websites that want to cater to them can offer alternative methods, and/or
gracefully degrade.

The websites that don't care about them lose out on that market opportunity.

Web 2.0 works like this now, but instead of operating systems, it is
browsers. If you don't use IE7+ or Firefox (which require two separate code
paths in a number of cases), you're pretty much on your own. Nobody cares
when their website doesn't work in Lynx.
Apr 24 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.71.1272140482.3522.digitalmars-d puremagic.com...

 On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:

 Congratulations, you just invented ActiveX.  I hope you like your
 platform lockdown and your security vulnerabilities.


 ActiveX controls don't run as a limited user account. That's the key here:
 the entire browser should be running as a restricted user, and it creates
 processes even more restricted than itself.

 (When Google did this in Chrome, it was hailed as brilliant and 
 innovative.
 I saw it as them finally doing what they should have been doing from the
 beginning.)


I remember reading an online comic explaining all of Chrome's wonderous 
advances and thinking much the same thing.


 99% of web pages will offer just the win32 version.


 Meh, works for 91% of users.


Maybe I'm just naive about this, but it would seem to me that it should be 
possible to have a single compiled-native-code format that could be "framed" 
by the client to work on the whatever the client's OS is. I mean, x86 is x86 
regardless of OS. Of course, that still leaves a need for a CPU architecture 
request header, and 99% of sites would ignore anything but x86, but it'd be 
an improvement over needing both CPU and OS.

Also, a web server could be set up to automatically convert or cross-compile 
to whatever CPU or OS was requested by the client (and then internally 
cached, of course). Probably involving LLVM or something. Having standard 
plugins like that even for just for Apache and IIS would fix the issue for 
99% of sites and 99% of users. And there could certainly still be fallbacks 
for the oddball servers and clients.

Plus, there's still other VM-bytecode possiblities besides just JVM. There's 
LLVM. Or you could transmit a standardized precompiled JS bytecode (even 
though JS may be quick to parse, I've still thought it was a bit silly to 
have the clients do the JS compilation since 99% of it is all the same code 
being sent out to all the different clients). Etc.

-------------------------------
Not sent from an iPhone.
Apr 24 2010
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 04:54:17PM -0400, Nick Sabalausky wrote:

 Maybe I'm just naive about this, but it would seem to me that it should be 
 possible to have a single compiled-native-code format that could be "framed" 
 by the client to work on the whatever the client's OS is.


It probably could be done, especially if all calls were done through
a dynamically linked interface.

But it seems simpler to just recompile the source for the other platforms.


 Also, a web server could be set up to automatically convert or cross-compile 
 to whatever CPU or OS was requested by the client (and then internally 
 cached, of course).


Yes, this should work excellently. The cross-platform aspect is the easiest
thing to solve to me.


 I've still thought it was a bit silly to 
 have the clients do the JS compilation since 99% of it is all the same code 
 being sent out to all the different clients). Etc.


The biggest problem there is each browser would surely insist on having
their own separate bytecode.
Apr 24 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 Also, a web server could be set up to automatically convert or cross-compile 
 to whatever CPU or OS was requested by the client (and then internally 
 cached, of course). Probably involving LLVM or something.


It's called pNaCl (PDF file):
http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

Bye,
bearophile
Apr 24 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 4/24/2010 14:29, Adam D. Ruppe wrote:

 On Sat, Apr 24, 2010 at 01:53:10PM -0600, Rainer Deyke wrote:

 Congratulations, you just invented ActiveX.  I hope you like your
 platform lockdown and your security vulnerabilities.


 
 ActiveX controls don't run as a limited user account. That's the key here:
 the entire browser should be running as a restricted user, and it creates
 processes even more restricted than itself.


Running the browser as a restricted user is good (and indeed necessary),
but when you're running native code, you're only as secure your OS and
CPU allow.  Running on a VM provides an additional layer of insulation.

I like native code, but only for applications that I choose to install.


-- 
Rainer Deyke - rainerd eldwood.com
Apr 24 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 04:29:17PM -0600, Rainer Deyke wrote:

 Running the browser as a restricted user is good (and indeed necessary),
 but when you're running native code, you're only as secure your OS and
 CPU allow.  Running on a VM provides an additional layer of insulation.


Sure, that's reasonable. I'll point out that if the VM is compromised, you're
back to depending on the OS, but you'll be right to counter that it is
one more hurdle for the bad guys.
Apr 24 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
I keep posting this link here, and it keeps being ignored, despite I think it
can become one important usage of D:
http://code.google.com/p/nativeclient/

Bye,
bearophile
Apr 24 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 04:26:55PM -0400, bearophile wrote:

 I keep posting this link here, and it keeps being ignored, despite I think it
can become one important usage of D:
 http://code.google.com/p/nativeclient/


It is absolutely useless; it has no market penetration and since it forces you
to use their tool chain the whole way, it will never get any.

Any time spent getting D to run on it would be a complete waste of time.
At least compiling to javascript would have a potential user base.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 24 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.72.1272141444.3522.digitalmars-d puremagic.com...

 On Sat, Apr 24, 2010 at 04:26:55PM -0400, bearophile wrote:

 I keep posting this link here, and it keeps being ignored, despite I 
 think it can become one important usage of D:
 http://code.google.com/p/nativeclient/


 It is absolutely useless; it has no market penetration and since it forces 
 you
 to use their tool chain the whole way, it will never get any.

 Any time spent getting D to run on it would be a complete waste of time.
 At least compiling to javascript would have a potential user base.


"it forces you to use their tool chain the whole way"

Can you elaborate on that or post links?

-------------------------------
Not sent from an iPhone.
Apr 24 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 06:17:25PM -0400, Nick Sabalausky wrote:

 "it forces you to use their tool chain the whole way"


Check out the README:

http://nativeclient.googlecode.com/svn/trunk/src/native_client/README.html

Notice how the instructions don't say to use gcc and gdb, but instead
nacl-gcc and nacl-gdb. The downloads say "source and toolchain".

Wikipedia says that it is simply because the code have 32 byte alignment:

http://en.wikipedia.org/wiki/Google_Native_Client

(second paragraph) but nevertheless, an out of the box compiler isn't going
to work for it.


Then, once the code is written, you can't execute it without the Google
browser plugin, integrated with Chrome and offered for Firefox, but not
available for Internet Explorer. Maybe they'll offer one once it goes live,
but I wouldn't count on it. Even so, odds are good that users won't have
it installed anyway.
Apr 24 2010
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.76.1272148468.3522.digitalmars-d puremagic.com...

 On Sat, Apr 24, 2010 at 06:17:25PM -0400, Nick Sabalausky wrote:

 "it forces you to use their tool chain the whole way"


 Check out the README:

 http://nativeclient.googlecode.com/svn/trunk/src/native_client/README.html

 Notice how the instructions don't say to use gcc and gdb, but instead
 nacl-gcc and nacl-gdb. The downloads say "source and toolchain".

 Wikipedia says that it is simply because the code have 32 byte alignment:

 http://en.wikipedia.org/wiki/Google_Native_Client

 (second paragraph) but nevertheless, an out of the box compiler isn't 
 going
 to work for it.


It looks like that's something that's necessary for the sandboxing and 
shouldn't be difficult for compilers to provide their own options for. Maybe 
Walter could add options to DMC to do that (or someone could do it to DMD or 
LDC) and we could see if that would be enough to get things to work on NaCL. 
I suspect the only reason they didn't just simply submit a patch to GCC may 
have just been because of GCC's (IMHO) slow and nearly impenetrable 
submission/acceptance process (There was a modification I once made to GCC 
and thought about submitting a patch, but after hours of digging through 
their site I couldn't figure out the process. The one thing I did learn 
about it is that there are periods during which patches aren't accepted).


 Then, once the code is written, you can't execute it without the Google
 browser plugin,


Any sort of natively-compiled-web-client technology is going to need either 
a plugin or explicit browser support.


 integrated with Chrome and offered for Firefox, but not
 available for Internet Explorer. Maybe they'll offer one once it goes 
 live,
 but I wouldn't count on it.


Isn't it open-source? I'd imagine someone could just port it to IE.


Even so, odds are good that users won't have
 it installed anyway.


Well, that would be an issue anyway with anything along the lines of what 
we've been talking about. Either getting a plugin installed in people's 
browsers, or getting it built into browsers and then getting people to 
upgrade to that new browser version.
Apr 24 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Sat, 24 Apr 2010 13:53:10 -0600, Rainer Deyke wrote:


 On 4/24/2010 09:27, Adam D. Ruppe wrote:

 If I had my way, I'd just be rid of the virtual machine altogether.
 Simply run native programs as a restricted user. (Indeed, I'd run the
 browser itself with that restricted user, then let it create whatever
 processes it wants, possibly stripping the child processes of more
 privileges.) The operating system keeps it from doing anything evil.


 
 Congratulations, you just invented ActiveX.  I hope you like your
 platform lockdown and your security vulnerabilities.
 

 X-Accept-Code: linux64; linux; win32


 
 99% of web pages will offer just the win32 version.


Indeed, it's hard to believe that a "web 3.0" application vendor would 
suddenly support several platforms after 25+ years of Microsoft 
dominance. The second platform might increase the development costs 
10..50% and bring 4% more money. It doesn't make sense to support other 
platforms unless enforced by the law. This problem won't go away in the 
long run, on the contrary, as new (mobile/htpc/whatnot) platforms emerge.

A middleware is about building the infrastructure. Later (ideally) there 
are no platform specific costs involved. A history lesson might help 
Adam. Both Apple and Microsoft are afraid of middleware solutions. That's 
why Microsoft corrupted Java & Javascript and Apple recently banned all 
non-Apple middleware tools on iPhone. The web 2.0 apps were built because 
people got tired of Microsoft monoculture. Web 2.0 is a crappy 
technology, but we haven't got anything better.
Apr 24 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 24, 2010 at 08:32:25PM +0000, retard wrote:

 A middleware is about building the infrastructure. Later (ideally) there 
 are no platform specific costs involved.


We have that already. I write programs for Linux and release them on
Windows by expending no effort beyond typing "make windows".


 The web 2.0 apps were built because 
 people got tired of Microsoft monoculture. Web 2.0 is a crappy 
 technology, but we haven't got anything better.


Web 2.0 emerged due to two things:

a) Developers are grossly incompetent. They are too damn stupid to
   even recognize a correct solution when they see it, much less to
   use one.

b) Ease of deployment. The existing web platform could be used to
   distribute applications without expending much effort.

c) Centralized control.

Being tired of Microsoft has nothing whatsoever to do with it.


-- 
Adam D. Ruppe
http://arsdnet.net
Apr 24 2010
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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
Apr 20 2010
parent "Nick Sabalausky" <a a.a> writes:
"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.
Apr 20 2010
prev sibling parent reply Adrian <nospam veith-system.de> writes:
Am 21.04.2010 03:18, schrieb Nick Sabalausky:

 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!


[snip]

 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:


[snip]


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


[snip]

aha - ok where is the logic ?

haXe is better than nothing - nothing is better than D => ....

never seen any post from you on the haXe newsgroup.

cheers, Adrian.
May 02 2010
parent "Nick Sabalausky" <a a.a> writes:
"Adrian" <nospam veith-system.de> wrote in message 
news:hrkgek$2ijb$1 digitalmars.com...

 Am 21.04.2010 03:18, schrieb Nick Sabalausky:

 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!


 [snip]

 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:


 [snip]


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


 [snip]

 aha - ok where is the logic ?

 haXe is better than nothing - nothing is better than D => ....


I'm not quite sure what you're asking here.


 never seen any post from you on the haXe newsgroup.


I've posted a number of times on the haxe message board.

http://haxe.org/forum/search?search=Abscissa
May 03 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Apr 21 2010
parent reply KennyTM~ <kennytm gmail.com> writes:
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?
Apr 22 2010
parent reply Justin Johansson <no spam.com> writes:
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
Apr 24 2010
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Apr 24, 10 18:04, Justin Johansson wrote:

 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


Er, I mean D.NET (http://dnet.codeplex.com/).
Apr 24 2010
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:


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


llvm has vmkit though, which can target both .net and java runtimes, I have 
no idea how mature that is. It could be a route to silverlight, meaning 
webapps in D. SafeD might be important here for interop.

http://vmkit.llvm.org/
Apr 24 2010
prev sibling parent Alex Strickland <sscc mweb.co.za> writes:
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
Apr 22 2010