Just being brief here, but something web.d can actually do right now that might be cool is plugging in modules to build your site.
==== import arsd.web; import some_blog_module; import some_forum_module; class MySite : ApiProvider { alias SomeBlogModule blog; alias SomeForumModule forum; alias _sitemap sitemap; Document _defaultPage() { redirect("sitemap"); return new Document; } } mixin FancyMain!MySite; ==== If some_x_module existed, that would compile and run a site with: / -> redirect to /sitemap -> which is an automatically generate tree of links of all site functions. /forum -> the Forum object /blog -> the Blog object Those sub-objects can be completely independent, and still integrate into your site with ease! I actually fairly hate web services. The whole idea strikes me as rather blarghy; my data is mine, and I really don't want you to have it. But, the main alternative is downloading some app then spending hours trying to integrate it into the rest of your site. Ever tried to build a coherent site out of WordPress, PHPBB, some other thing and custom code on top of it? I have. Pain in my ass, even if I'm willing to take some shortcuts. Each one has their own login function. Each has their own styles and template systems. Each has their own user database. And, of course, each has their own code that can't be brought together. Try including a Wordpress file in phpbb. You'll wanna slit your wrists. The beauty of the web.d approach here is that those modules are now brought into your class, with the magic of alias. That means they share a number of fundamental functions! Providing a _getGenericContainer on the outer level can apply to those inner classes. Your _postProcess is run even on the inner class methods. What that means is styling them is fairly trivial - it automatically puts the content inside the skeleton you provide, and your modifications after-the-fact are still done. (_postProcess() can be thought of a way of a server side alternative unobstructive javascript - it presents you with the final DOM tree and you can modify it as you see fit before the output is written. _getGenericContainer is the starting point - when building a final document, it calls that to get a reference to a specific place in your HTML template as to where to put the main content.) If that isn't enough, you can still use inheritance to override methods in the provided classes, or to add more. Or, you can call their methods directly. No need to mess with some php plugin to auto post to the forum, just call forum.makePost() directly. One question comes to mind: what if you need to add configuration to those modules? Can't do that with alias.... or can you? If the modules were templates... alias SomeBlogModule!(config, info) blog; that should work right now. One point of power might be to pass typeof(this) as a template arg, so it can access your top level class' special methods. Using template constraints, it can let you know what you need to implement for best results. Some good interfaces might be getLoggedInUser() and getDatabaseHandle() to make integration that much easier. Some questions remain: what about stylesheets? If you write websites like I do, the .css file is a necessity. Adding it in the postProcess section could work. Or, something I've really liked doing recently is this: ====== void _catchAll(string path) { if(path == "/style.css") { cgi.setResponseContentType("text/css"); cgi.setCache(true); // unlimited client side caching cgi.write(import("style.css")); return; } super._catchAll(path); } ==== That is - serve up the css file from inside the application. It makes deployment slightly easier, and I can concatenate data on the server if need be: string style = import("style.css"); version(special) style ~= import("other-style.css"); cgi.write(style); This concatenation is what you can do with child objects. If ApiProvider had a style() method, you could call it for each child. Then, of course, overriding it or providing another stylesheet later on or with greater specificity gives you full control, along with sensible defaults. I think I'll add this as a standard thing soon. (like how "functions.js" is built in to web.d to provide the JS api. Just link to that name from your template html and you can use all your D functions via AJAX type calls.) All we've gotta do is write up some of these modules and see if the idea works as well in practice as I hope!