critique of vibe.d

[Puming via Digitalmars-d]

Also, in playframework, vert.x and nodejs, they all have a 
plugin/module system, that people could easily compose plugins to 
make a website. (I call it plugin because that is what play used 
to call it, now they all call it a module but that name will 
easily conflict with D's sourcecode modules). This is a critical 
mechanism that actually allured developers to contribute to the 
eco-system.

Plugins are like dub packages in a way, but not exactly. Dub 
packages are an encapsulation of build packages, which is similar 
to Java's maven packages. But plugins are components of the web 
framework, built on top of build packages, but has more 
application related meaning. So both play and vert.x have 
separated plugin(in vert.x is called a module) concept from maven 
package. Vibe.d could have this plugin mechanizem, but Sonke said 
that it should be the responsibility of a framework on top of it 
(meaning in that framework, vibe.d would just be a plugin to the 
framework that web developers would choose to server http 
requests).

For example, if one designed a user/password plugin, with 
database access logic (in source folder), login page templates 
(in view folder) and static js/image/css (in public folder), and 
this plugin is used, then all resources are treated just as they 
are manually put into respective folders. While dub packages 
usually only deals with D code.

You can see playframework's plugin registery here: 
<http://www.playframework.com/documentation/2.3.x/Modules>

vert.x module's document here: 
<http://vertx.io/mods_manual.html>, vert.x has a more complicated 
module design (which not only is a way to group functionalities, 
but also a deployment node).
its registery here: <http://modulereg.vertx.io/>



On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:
> Vibe.d is more like a base library for async I/O, networking 
> and concurrency, a full stack WEB framework should be built on 
> top of it which focus on application development and ease of 
> use for newcomers. Sonke has said that too. Vibe.d should focus 
> on performance, networking, and other lowerlevel stuff that D 
> should be really good at. Sonke is already too busy doing his 
> gorgeous work on vibe.d and dub. I think that is what the guy 
> on reddit was complaining, he thought vibe.d should contain 
> everything from a web framework, but didn't find them, thus 
> getting the impression that vibe.d was not complete. Actually 
> vibe.d is just an edge of a triangle in web frameworks. We are 
> lacking the other two pieces.
>
> We need a MVC or whatever framework on top of it. Compared to 
> Java world, there is [Netty](http://netty.io) the networking 
> library and Web frameworks like playframework, vert.x built on 
> top of it.
>
> Currently the only work that is active IFAIK is Rikki's 
> [CMSED](https://github.com/rikkimax/Cmsed), which needs more 
> love.
>
> In [playframework](http://playframework.org), incoming request 
> are send to a cluster of actions in a [Akka](http://akka.io) 
> cluster for computing & business logic. The trio (play, netty & 
> akka) has shown to be very good combination for a web stack.
>
> We have actor models in std.concurrency but only with thread 
> granularity, vibe.d has got a fiber based concurrency model 
> which I think could go in to the standard library, or make its 
> own library. That front needs more manpower. Again, rikki has 
> initiated a port from akka -- 
> [dakka](https://github.com/rikkimax/dakka). I think it is a 
> right way to go.
>
>
> On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu 
> wrote:
>> There's been some discussion about vibe.d recently on reddit 
>> (e.g. 
>> http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) 
>> and I was wondering to what extent that's meaningful:
>>
>> "has anyone ever tied a real webservice to vibe.d? I actually 
>> tried. its nowhere near complete in any sense. you simply 
>> cannot compare it with go's standard http lib, sorry, I tried."
>>
>> If there's sheer work needed for completing vibe.d, I think it 
>> would be great if the domain-savvy part of the community would 
>> rally around it. Serving dlang.org and dconf.org off of vibe.d 
>> would be awesome dogfooding.
>>
>>
>> Andrei