How To Dynamic Web Rendering?

[Nick Sabalausky]

"Adam D. Ruppe" <destructionator at gmail.com> wrote in message 
news:iqji6m$1se1$1 at digitalmars.com...
> Jacob Carlborg wrote:
>> How is it working out with a static type system, compared to a
>> dynamic, for web development?
>
> It's *much* better, especially for rapid development. The compiler
> will tell me if my changes anywhere break things anywhere else,
> so I can modify with confidence.
>
> I can't tell you how many times I've made a minor mistake in PHP,
> Ruby, or Visual Basic and had it slip through to production because
> the code path was obscure enough to evade testing.
>

Yea, it all just comes from dynamic being sloppy and overly-permissive.

Before I switched my web development to Haxe (not remotely as good as D, but 
it beats the hell out of straight PHP/ActionScript), I had to do some stuff 
in ActionScript2. Anytime anything would go wrong (other than a syntax 
error), the compiler would accept it, and the *runtime* would accept it and 
just simply ignore it and move on. Not even an exception or log notice or 
anything. That alone turned development into an absolute nightmare. Nothing 
ever worked, you never had the slightest clue why, and it took forever to 
track the problem down to something that, invariably, would turn out to be 
something D would have caught immediately, usually at compile-time. And that 
was all in the name of being "forgiving". Blech. Bottom line, whether 
dynamically-typing or anything else: being overly-permissive sucks. What D 
permits you to do is tighten the damn leash.

>
> The to!() template in Phobos makes this pretty easy, or if you
> want default value and get/post combined, my cgi class has a request
> template:
>

to!() is absolutely awesome. OTOH, thanks to to!(), the conversion functions 
in every other language out there seem irritatingly poorly designed. ;) 
Anytime I have to do a conversion in Haxe, I always end up needing to reach 
for the std API reference. And even Haxe's API for conversions is pretty 
good compared to some other langauges.

> int a = cgi.request!int("a");
>
> That's similar to this in PHP:
>
> $a = 0;
> if(isset($_POST['a']))
>  $a = (int) $_POST['a'];
> else
> if(isset($_GET['a']))
>  $a = (int) $_GET['a'];
>
>
> PHP is so outrageously verbose. And the PHP is buggy compared to
> the D... if you do cgi.request!int("a", 10) and the user does a=txt,
> the PHP result is wrong. It's not quite fair to compare a function
> to a code collection though. A php function could do it right too.
>

Be glad it's not VB6, or worse, VBScript. I've had to do a lot of web dev in 
those languages in the past, and as horrible as PHP is overall, for outright 
verbosity it doesn't even compare to VB6/VBScript.

auto myVar = "foo";
$myVar = "foo";

vs:

Dim myVar As String
myVar = "foo"

Seriously?!

And don't get me started on VB's million-and-one different things you have 
to check for to see whether or not a string actually contains anything.

And then there's its arrays, which wouldn't be *too* bad if they didn't 
allow the staring index to be chosen completely at random. So, wanna find 
the length of an array? In D it's:

myArray.length

In PHP it's probably about the same as D. In VBScript, if you want to do it 
correctly, it's:

(UBound(myArray) - LBound(myArray))+1

Or you can do UBound(myArray)+1 and just pray that some stupid jackass 
doesn't actually try to use the "choose your array's lower bound", ahem, 
"feature".

I can just feel my sanity fading...

>
> auto table = cast(Table) document.getElementById("data-table");
> assert(table !is null); // fails if it isn't a <table> tag
>
> // use the table class's special functions
>
>
> Forms, Links, and other types of nodes are handled similarly. The
> Element base class though does most the simple operations. Being
> plain old inheritance, the virtual functions act dynamically
> enough.
>

You know, I used to absolutely love doing the rails-like thing of using HTML 
templates. And Terence Parr's StringTemplate even managed to convince me for 
awhile that such templates shouldn't have imperative logic.

But the more I watch your DOM approach and then continue using HTML 
templates (very mercifully, one that thankfully *does* allow imperative 
logic), the more fed up I'm starting to get with the template approach. 
Granted, I haven't used it yet, but I think you've got the right approach 
with your DOM stuff.

>
> And more stuff is packed in there too. Best of all: D, through
> CGI, consistently does well or better than mod_php in my speed
> benchmarks. I've barely tried to optimize too; there's a lot of
> untapped potential.
>

One of the things I've noticed never even seems to get mentioned is that 
even though CGI has had a stigma of high startup costs, *MANY* php 
installations, even on commercial shared hosting, have php set up to run as 
CGI. So even if php interpretation wasn't much slower than good compiled 
code, it *still* wouldn't usually have the speed advantage people have 
attributed to it.

>
> If your host doesn't suck, dive into D on the web. You won't want
> to go back.)

Won't want to go back to dynamic web scripting? Hell, I haven't even done 
any D CGI beyond a trivial hello world (for which I had to jump through 
*enormous* hoops to get working with my damn shared web hosts - and one of 
them, turns out, won't even support compiled CGI at all), and yet, I just 
plain don't want to *remain* with dynamic web scripting. :)

Another thing, too, that's really good about D being faster is that you can 
do a lot more before Apache/PHP/whatever decides to kill you off for taking 
too long. And you can realistically try to anticipate it, finish up any 
atomic operations, and die gracefully instead of risking corruption from 
broken atomicity.

That's getting to be a problem in my Haxe/PHP stuff. I have my code set up 
so that when there's an unhandled exception, it automatically tries to log 
it to three separate places: a logfile, the DB, and email. (And if any one 
of those fails, it still attempts the others and then tries to notify the 
others that the one failed. I'm really proud of the whole system :)) And, of 
course, a stack trace is included. But the problem is, this all takes 
(noticable) time, especially on PHP, so I risk loosing all the info that 
anything even went wrong at all just because the server killed it off for 
taking too long. And that's actually happened a few times on my local dev 
system (I *hope* it hasn't happened on the server...) Heck, I can usually 
tell when it's crashed even before I get the error page just because it'll 
take noticably longer than usual.

But what makes all that really bad is there seems to be a bug in either Haxe 
or PHP that causes stack traces to include *all* the functions called...ie, 
even the ones that have returned, instead of just the current call stack. So 
the *ahem* "call stack" ends up huge (and hard to use). And there's two 
things that make it far bigger than it even needs to be:

1. There's a big data structure I sometimes need (data that doesn't actually 
change - so it's converted automatically at build-time from a raw datafile 
to a direct hard-coded Haxe source file). But Haxe, and presumably PHP, 
doesn't allow compex literals. And even if it did, there's no such thing as 
pre-compiled PHP, so there's no such thing as a statically-initialized data 
segment. So the generated Haxe code has to actually build up the data 
structure at runtime. And the structure is somewhat large...and there's a 
limit on function size (don't recall if it's a Haxe or PHP limit)...so each 
piece of the data-building has to be put into it's own function. And there's 
currently hundreds of these little functions. So that makes the "broken 
stack trace" that much bigger and slower to build.

2. Haxe has runtime reflection, which is needed for it's, rather good, 
object database API. But the reflection works by keeping the info stored 
as...get this...XML...and then the XML is parsed to retrieve the actual 
data. Which is incredibly stupid, of course, but that's how it's done. And, 
of course, there's recursion involved in that XML parsing, so that bloats 
the big slow broken stack trace even more.

Although, all that reminds me, servers (especially shared hosts) can also 
have memory limits on scripts and CGI. But D's GC likes to just keep 
grabbing system RAM and only release back to the OS when really necessary, 
or when you tell it to. And even that can be blocked by false pointers. Have 
you had any problems with server memory caps and D's memory behavior?