critique of vibe.d (page 2)

On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote: > On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: >> "has anyone ever tied a real webservice to vibe.d?" > > Yes and see no problems with it. Looks like author has very specific expectations of "webservice" concept and can't do a thing with 100% .. coverage of all utilities in the library. Sad he does not provide some sample of missing bits. Most likely he has expected vibe.d to be exclusively web framework while it is generic networking / async framework.

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 Ironically I find pure vibe.d solutions much more clean and easy to maintain than any enhancements built on top so far (including Cmsed). I don't do any frontend stuff though.

On Wednesday, 9 July 2014 at 01:35:49 UTC, Puming wrote: > That commenter is probably a web developer that wants all batteries included. Yep. He mistook vibe.d for a complete web development framework, I suppose. It's quite common that people are put off because they expect too much or do not understand what the technology is really about. While we may not win this particular user back, it is important to clarify where s/he was mistaken, so that myths based on false assumptions are not propagated.

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. Huh. I guess it depends what your goal is. For the kind of work I do, vibe.d is in the right ballpark. The services I create basically respond to AJAX calls (JSON-RPC is the best, though REST is okay too) and do other back-end work. I've never had a need to do any HTML handling or anything like that. I might take issue with the specifics of how some of the APIs are designed, but not with the feature set.

Am 09.07.2014 03:54, schrieb luminousone: > There is lots of missing little bits here and their, password hashing > functions that use crypt_(C) formated hashes. I was hoping for dauth [1] to fill that gap. It doesn't use the same format, but one with the same goal. I didn't actually try it out yet, though. > > There are diet/jade template bugs still, specific major problem being > that use of single quotes inside of double quotes when i need to pass > strings to js functions inside of js events such as onclick inside a > html tag, seems to be broken. Do you have a concrete example where this goes wrong? I've tested both, nesting ' inside " and vice versa. Both seemed to work fine for <body onLoad=...>. > > There is not common database interface for sql databases(forgivable > actually), but many of the specific database libraries are messy(ddb for > example) and they are not any where near api "stable". > > Support for mongo is... cute?!, don't get me wrong it has a place, for > most apps it would be fine, it is however unusable for the apps i am > involved in. Yeah, I kind of like it for its flexibility, but it's definitely not the right choice for million user web services. I'm currently looking at NouDB as another potential SQL based target. [1]: http://code.dlang.org/packages/dauth

On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: > 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. On a related note, one thing vibe.d is really missing from my perspective is a good way to handle unstable processes and perform seamless code upgrades (this is where Erlang really shines IMO). It would be cool if there were a process monitor at least. The system I work with does some fancy stuff with UDS, but that probably isn't necessary. I'll admit that the ball is probably kind of in my court here, since IPC would be a handy way of communicating process health, but something simpler using pipes or whatever would work as well.

On Wednesday, 9 July 2014 at 09:48:32 UTC, Dicebot wrote: > On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote: >> On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: >>> "has anyone ever tied a real webservice to vibe.d?" >> >> Yes and see no problems with it. Looks like author has very specific expectations of "webservice" concept and can't do a thing with 100% > > .. coverage of all utilities in the library. Sad he does not > provide some sample of missing bits. Most likely he has expected vibe.d to be exclusively web framework while it is generic networking / async framework. Yeah, connection-based protocols are where UDS really shines for supporting seamless upgrades. Transaction-based protocols like HTTP are much easier to deal with in this respect.

Am 09.07.2014 17:17, schrieb Sean Kelly: > I might take issue with the specifics > of how some of the APIs are designed, but not with the feature set. Please be vocal about such design issues :) I think most parts are in a pretty good shape, but there is of course almost always room for improvement (the Json/Bson types come to mind).

Am 09.07.2014 17:26, schrieb Sean Kelly: > On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: >> 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. > > On a related note, one thing vibe.d is really missing from my > perspective is a good way to handle unstable processes and perform > seamless code upgrades (this is where Erlang really shines IMO). It > would be cool if there were a process monitor at least. The system I > work with does some fancy stuff with UDS, but that probably isn't > necessary. I'll admit that the ball is probably kind of in my court > here, since IPC would be a handy way of communicating process health, > but something simpler using pipes or whatever would work as well. This is what vibedist [1] was/is intended for, but unfortunately I never found the time to really finish it so far. [1]: https://github.com/rejectedsoftware/vibedist

July 09, 2014

Re: critique of vibe.d

Posted by Johannes Pfau
in reply to Sönke Ludwig

Permalink

Johannes Pfau

Posted in reply to Sönke Ludwig

Permalink

Am Wed, 09 Jul 2014 18:16:49 +0200
schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:

> Am 09.07.2014 17:26, schrieb Sean Kelly:
> > On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:
> >> 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.
> >
> > On a related note, one thing vibe.d is really missing from my perspective is a good way to handle unstable processes and perform seamless code upgrades (this is where Erlang really shines IMO).  It would be cool if there were a process monitor at least.  The system I work with does some fancy stuff with UDS, but that probably isn't necessary.  I'll admit that the ball is probably kind of in my court here, since IPC would be a handy way of communicating process health, but something simpler using pipes or whatever would work as well.
> 
> This is what vibedist [1] was/is intended for, but unfortunately I never found the time to really finish it so far.
> 
> [1]: https://github.com/rejectedsoftware/vibedist


Completely off-topic, but:

Have you considered making vibe http-backend independent?
So that it could provide a fcgi interface or be included in an nginx
plugin?

Also as D plugins now seem to work more or less have you considered loading webpages dynamically from .so files?

Then we could invent some file extension - like .dpage - and have one
vibe fcgi process handle all .dpage files. The process then simply
loads the .dpage shared library, calls some function (extern(C) IWebSite
vibe_get_site()) etc.

Basically the way asp.net works, IIRC.

Forums