On Sunday, 12 July 2015 at 20:36:26 UTC, Etienne Cimom wrote:
For me at least, D has a lot more to offer because with the
recent developments in vibe.d
I don't think I'd even use vibe for your use case - you'd never
need to scale to 10,000 connections if it runs on localhost.
Perhaps a little-known part of my web.d is a few special parts
for localhost work, including a synchronous javascript bridge
back to your server side functions.
web.d's normal behavior is to provide web pages and async
javascript access to your class methods:
D:
class Foo : ApiProvider {
int add(int a, int b) { return a+b; }
}
Usage from javascript:
Foo.add(1, 2).get(function(sum) { alert(sum); } );
or in the browser, you can navigate to site/add and it presents a
form asking for a and b, and the submit shows the answer.
But it also has sync JS support:
var sum = Foo.add(1, 2).getSync();
Which is nice because then you have linear flow. The bridge also
translates D exceptions into JS exceptions here.
You wouldn't normally do that on the web since synchronous events
can freeze up the browser from network lag. But doing it on
localhost should be pretty reliable.
cgi.d's underlying threaded implementation is also fine here, as
it will trivially scale to the small handful of connections you
need for localhost.... and you can still use your ordinary other
libraries to handle requests, e.g. C libraries that block, with
no hassle (heck, you could even make a gui thread pop up a
regular window to control the server with ease).
We're already on top and we don't know it yet
I've felt that way for about five years now!
