D For A Web Developer

[Nick Sabalausky via Digitalmars-d]

On 4/30/2014 9:47 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky wrote:
>> FWIW, IMO the big selling point of D is it's fairly unique knack for
>> letting you eat your cake and still have it. I rather like to think we
>> can manage merging the "full stacks" with the "lightweights".
>
> Ugh, avoid the full stacks like the plague. They tend to be lockin
> solutions. Reminds me of Tango in D1 where you risked pulling in all
> kinds of dependencies.
>
> You might dislike this, but I think nimble servers and clean separation
> with javascript heavy clients are the future.
>

That definitely is the direction things are moving right now. Granted, I 
don't like it, but you're right it's undoubtedly the popular direction 
and it's unlikely to slow or reverse anytime soon.

That said, I don't have an issue with fat clients in general. I usually 
tend to prefer them (ex: desktop email client). Just not when the "fat 
client" happens to be inside a web browser, because that tends to not be 
"fat" client so much as "needlessly bloated" client with an awkward, 
temperamental UI (example: MS Word and OpenOffice have never lost one 
keystroke for me from a network hiccup or anything equally trivial).

> What I don't want:
>
> - I have started to avoid server processing of forms, javascript/ajax
> gives better user experience.
>

JS can definitely help improve the UX of form validation, no doubt about 
that, but it's important to remember that server-side validation is 
still necessary anyway, regardless of what you do on the client.

> - I avoid advanced routing, it adds little and leads to harder to
> maintain code, give me a regexp based routing table in one location
> binding request-handlers.
>

Same here. I don't like having my available HTTP interfaces scattered 
across my codebade, and I definitely don't like having them implicit 
based on member-function visibility (I've used such frameworks before. 
Not personally my cup of tea).

What I *do* love is having a canonical table defining my entire HTTP 
interface in one easy location. The extra typing or non-DRYness of that 
is a mere triviality in my experience (and I'm normally a huge DRY buff).

> - Server side generation should be kept minimal, prevents caching.
>

Ehh, yes and no. Server side generation is usually fine, just not when 
it's done more often than necessary. And traditional server-side web 
technologies definitely tend to do it more than necessary,

For example, consider a page containing a blog post with (non-Disqus) 
user comments:

It's a complete waste for the server to regenerate such a page upon 
every request, PHP/ASP-style. That's because it doesn't *change* upon 
every viewing - it only changes on every post and edit (and not even 
every one of those, if there's enough comments to trigger paging).

So unless the page's rate of comment "submissions/edits" approaches the 
rate of comment "views" (unlikely...except maybe on YouTube ;) ), then 
it's best to re-generate upon posts/edits and then cache that. So you 
still get caching benefits, but with no need to make *all* the clients 
duplicate the exact same page-generating effort as each other upon every 
viewing.

Supporting login stuff (ex: "Hello, [your name here]! Logout?") doesn't 
really mess this up either. The vast majority of the page can still be 
cached by the server. Then, "generating" it for each user doesn't need 
to be anything more resource-intensive than this:

void loginUser(string name)
{
     session.user.loggedIn = true;
     session.user.name = name;

     // Whatever template engine you want:
     session.user.loggedInUI =
       `Hello <b>`~name~`</b>! <a href="/logout">Logout</a>`;
}

enum commonLoggedOutUI =
     `Login: <form>Username:<input...> Pass:<input...></form>`;

void showMyPage(OutRange response, User user)
{
     // myPage was automatically split into parts A and B
     // last time it was updated:

     response.put(myPagePartA);

     if(session.user.loggedIn)
         response.put(session.user.loggedInUI);
     else
         response.put(commonLoggedOutUI);

     response.put(myPagePartB);
}


> - Would never consider using serverside javascript generation.
>

Heh, I've actually done that on old-style ASP (ages ago). It was both 
confusing and interesting.

> What I do want:
>
> - Transparent fast distributed in-memory database with logging to a
> exchangable backing store and with consistency guarantees.
>
> - No filesystem dependencies.

I'll take those, plus a large vanilla latte, please. :) "Thank you, come 
again!"