On 4/30/2014 9:47 AM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@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!"
