I currently do most of my web development in PHP, with some work in Ruby with RoR. Right now I'm starting to think about building my own stack for web dev (I already use my own MVC framework and libs in PHP), but I'd really like to move to something faster and more powerful. Java or ASP.NET are two obvious choices, but I'm currently researching other alternatives (like D).

So first I was wondering if there has been any web development using D, and if there are many (or any) libraries/frameworks/other resources already available for this?

Second, from your own experience using D do think it would make a good or bad choice for a web development language?

Have a look at the recent thread titled 'How To Dynamic Web Rendering?'
Adam Ruppe has created a package for web development with D and it seems to work like a charm.

Yea, the Dynamic Web Rendering thread just went over this, so shouldn't be hard to find that thread.

It went into discussing my method and got a little long, but the summary is:

You can write web apps in D using the standard CGI interface or a long lived process (embedded http server or whatever.)

My code works best with standard CGI, cgi.d in here: http://arsdnet.net/dcode/

I also have an httpd.d (requires netman.d) that lets the cgi interface work with an embedded server, but it's single threaded so that can be a problem. It's not production ready.

Regular cgi though works with other existing web servers, is easy to use, and actually performs quite well.

(You'll find a lot of people complaining on the internet that CGI is slow, but check the date on those articles and see if they are using Perl or native compiled binaries.

Usually they are very old and using an interpreter - that's why it is slow. A native binary over cgi is quite fast.)



The stuff you build on top of cgi can be whatever you want. I personally use my dom.d and web.d modules for templating and some automatic code generation, but you can spin your own libs too.

"joe" <joe@studiofortress.com> wrote in message news:ir8frr$ait$1@digitalmars.com...
>
> Second, from your own experience using D do think it would make a good or
> bad
> choice for a web development language?

I'd really say that a good choice for a web development language is whatever you find to be a good choice for a language. Personally, I love D. It's my favorite language, and out of all the languages I've used (many over the years) it's really the only one I'm overall happy with (but then, I'm notoriously picky ;) ). So I find D to be an excellent choice for a web development language since I personally find D to be an excellect language. OTOH, if someone happened to absolutely hate D, then D probably wouldn't be a very good choice for them for a web development language.

There is one other factor to consider, though: You need to think about what server or servers it will need to run on:

If, for example, you need it to be able to run on pretty much any shared web host out there, then you're pretty much stuck with either PHP or something like Haxe that compiles down to PHP. And that defintiely won't help you with performance, and it'll only help alleviate *some* of PHP's probelms, not all of them. That's the unfortunate state of shared web hosting :/

If, OTOH, you only need it to run on one specific server and you don't have complete control over it (for example, if it's a shared web host, or if it's run by some separate IT department thet you're not part of), then naturally you'll need to see what the server supports and make your choice from those. But keep in mind one thing I've learned the hard way: Just because they say they support CGI does *not* necessarily mean they support CGI from a natively compiled langauge (which D is). So make sure to get clarification on that.

And, of course, if you have total control over the server, then naturally you can choose whatever you want.

Oh, but unless you do have direct access to the server and total control over it, I would recommend against ASP.NET. Not because I really have anything against ASP.NET, Windows or MS, per se. It's just that ASP.NET typically requires a Windows server, and shared Windows hosts usually don't provide any way to set up things like file permissions and internal URL rewriting. And not being able to do those things can often be a problem.

joe wrote:

> I currently do most of my web development in PHP, with some work in Ruby with RoR. Right now I'm starting to think about building my own stack for web dev (I already use my own MVC framework and libs in PHP), but I'd really like to move to something faster and more powerful. Java or ASP.NET are two obvious choices, but I'm currently researching other alternatives (like D).
> 
> So first I was wondering if there has been any web development using D, and if there are many (or any) libraries/frameworks/other resources already available for this?

As mentioned Adam D. Ruppe has nice libs for web development, he managed to make a living out of it too so he must be doing something right :)

There is one other web framework for D2 called serenity, I'm not sure how far it is but you can check it out here:

https://github.com/mrmonday/serenity

Perhaps this is unnecessary to mention, but would you choose ASP.NET, I'd recommend against webforms and look into ASP.NET mvc. If haven't used the latter myself but I didn't like webforms too much and heard good things about the mvc framework.

Good luck!

On Sat, 21 May 2011 19:18:39 +0300, Adam D. Ruppe <destructionator@gmail.com> wrote:

> (You'll find a lot of people complaining on the internet that
> CGI is slow, but check the date on those articles and see if they
> are using Perl or native compiled binaries.
>
> Usually they are very old and using an interpreter - that's why
> it is slow. A native binary over cgi is quite fast.)

Regular CGI still has the overhead of starting a new process for every request. PHP without CGI is likely to be faster than D with CGI.

OP is looking for best performance, so CGI is not a good recommendation - FastCGI/webserver module/built-in webserver are the way to go.

I've had great experience with using an HTML/jQuery frontend with a D backend (built-in HTTP server which only serves static files and AJAX requests).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

Vladimir Panteleev wrote:
> Regular CGI still has the overhead of starting a new process for every request.

That's a very small cost - between 1 and 5 milliseconds, depending on your hardware.

Next to the network latency involved in making a request, that's literally nothing - it's less than random network variation, so it has no impact on the end user experience.

It also disappears quickly if your program does any processing, since it's like a line: y = mx + b. The startup cost is b, and the speed of the language is m.

If x is even slightly big, reducing m means you'll get better end results than reducing b. (unless b is *huge*... like network latency. Adding an "Expires:" header to your responses gives the biggest gains of all.)

My work application runs about 40% faster on CGI than the fastest comparable product we've found in mod_php, on average, with certain CPU intensive portions being up to 5x faster.

That said, an embedded webserver /is/ even faster, but it's also harder to use.

The end result depends on your app. Only actually benchmarking it can tell for sure what matters. My cgi.d provides the same interface regardless of how it is called - switching to built in httpd is easy if needed.


> I've had great experience with using an HTML/jQuery frontend with a D backend

From what I've seen in my benchmarks, you would probably get
a bigger usability boost by ditching jQuery than by ditching CGI.
Even when cached, jQuery takes a while for the browser to parse -
comparable to starting up a native process on the server.

I've never done any CGI stuff before, but can't you employ some kind of messaging mechanism with an already running process? Maybe use memory-mapped files or some other technique to communicate with the process?

> I've never done any CGI stuff before, but can't you employ some kind of messaging mechanism with an already running process?

Yes. I find it's quite useful when you want instant notifications on something, like a web chat application, but it could do some speed boosts too.

I'm working on a post showing some of my benchmarks too on built-in vs cgi. Some of them are over 20x faster with a built in webserver! (I wonder if this is cgi's fault or if Apache is just not optimized for it... I'm changing the i/o code too so we can make sure it's not just stdio being slow.)

I wrote:
> That said, an embedded webserver /is/ even faster

I measured this using one of my in-development apps recompiled to use the built in server I have, picking a page with moderate processing requirements.

CGI:
Time per request:       17.375 [ms] (mean)

built in webserver:
Time per request:       8.727 [ms] (mean)

I wonder why the difference is bigger than the startup I measured when isolated? I think I/O contributes to slowdown a little too. My startup cost was based on hello world, no significant output. This outputs several kilobytes of data.

That's without any optimization. Let's try that again, making the mysql and reflection objects static so they needn't be recreated on every request when embedded....

Cgi:
Time per request:       17.178 [ms] (mean)

Built-in:
Time per request:       5.079 [ms] (mean)


Very nice.


Those are all pretty small numbers, but we do see a clear speedup with the built in webserver.


Since my webserver is single threaded, I don't think this is really fit for production use. If one user's request went too long - which it shouldn't, but could - it'd slow everyone down. It also can't serve up staticish files while waiting on something else to process.

Another worry I have with a long lived process is what if it dies? With CGI, you can trust Apache to start a fresh copy for you.

That's why I call the cgi one easier to use. You just drop it in there, no need to worry about it dying, no need to start or restart the process for updates, etc.


For fun, let's run it on some simpler pages too

Serving the auto-generated Javascript api file:

CGI:
Time per request:       13.678 [ms] (mean)

Built in:
Time per request:       1.070 [ms] (mean)


Big multiplier, but since it's a trivial program, we can see it's about the same difference as we saw above - a constant ~10-13 ms savings.

I also serve the stylesheet through it, because then it's deployed all as one file. This is done before the database and reflection objects are created anyway, so that optimization shouldn't have an effect here.

CGI:
Time per request:       10.493 [ms] (mean)

Built in:
Time per request:       0.774 [ms] (mean)

And indeed, it didn't - the 10 ms constant cost is all we see.

I wonder if I can do anything to improve the I/O performance.... nope, changing to the syscall from stdio made no significant difference.

Doing
 time PATH_INFO=/style.css ./cgi-app > /dev/null

averages to ~10 ms too, so I can't blame Apache either.


So startup + object construction + I/O overhead for a real world page gives CGI about a 10ms penalty. This ranges from a small to a very big multiplier of total time, depending on what the program is.

Next to real world network conditions, this is consistently
a small number in the big picture - the end user is unlikely to
notice it.