Where will D sit in the web service space?

[Sönke Ludwig via Digitalmars-d]

Am 13.07.2015 um 06:29 schrieb ChangLong:
> I has use vibe.d for a small project recently,  after finish that I
> think the follow fact will
> prevent many programmers use vibe.d in commercial projects:
>
> 1) Lack of successful open source project for real product
I don't know of any big front-end product, but it's used for a variety 
of smaller building blocks. Probably it would be a good idea to start 
collecting projects using vibe.d on a sub-page on vibed.org to get some 
mutual marketing boost.

> 2) Multi thread performance is poor, scalability is not suit for big
> project
My guess is that this was caused by the GC. In the benchmarks I did, it 
scaled up more or less perfectly, but I was careful to not perform any 
per-request GC allocations there.

Using multi-process scaling may be a viable alternative if your project 
relies on the GC. Or, if the project partially performs CPU intensive 
computations, it may make sense to offload only those computations to 
worker thread, relying purely on async I/O concurrency in the main 
thread for network scaling.

> 3) No Inversion of Control (aka: Dependency Injection) Concept
Since this is a broad term, on which level do you miss an explicit 
concept for this? Any concrete example?

> 4) No mature ORM/ODM components
This can indeed be an issue. But, even if this isn't a full ORM, at 
least the MongoDB and Redis drivers in vibe.d support direct mapping to 
D types using the serialization module.

> 5) No Form/Validator/Translation/Locale Components
See vibe.web.web: http://vibed.org/docs#web-interface-generator

There are still missing bits, but a lot is already there. Please let me 
know of anything particularly useful that is missing.

> 6) No modernize framework
I've not heard of that term. Can you explain?