On Saturday, 19 September 2020 at 19:27:40 UTC, Steven
Schveighoffer wrote:
[...]
This used to be the expected way to set up vibe (using module
constructors). And vibe would provide its own main function.
I *think* the idea was to allow registration of different
handlers in their respective modules.
A reasonable decision if you assume that's the only thing you
want to do.
Vibe and dub share this philosophy. The author(s) assumed those
are the only use cases and nothing else flies.
Like for e.g. you can build a D application that uses a C library
with D glue code and compile the files together in 1 go with GCC,
maybe with LDC, too, but I haven't tried.
something like: gcc main.d dglue.d clib.c clib.h
But this doesn't work with dub, or at least it didn't work the
last time I tried a year or so ago.
I'm not a fan of the "The one true way" philosophy.
[...]
I used Kai's book, and yeah, you have to do things the vibe
way. But most web frameworks are that way I think.
I recommend getting the book if you plan on doing a lot with
vibe.d
I forgot that I got it some time ago, never really got around to
take a look however. Thanks for the reminder :)
Where vibe really shines are the diet templates and the web
interface stuff. To not have to handle anything from forms, or
query parameters, and just write normal D functions is really
great. You can even do a lot of authentication and stuff using
UDAs. It helps you write consistent web applications.
And I LOVE diet templates. So much less verbose than actual
HTML. I have a hard time writing actual HTML now.
Those are the only reason why I didn't throw it out, yet. Maybe
it will make up for some of the initial frustration :)
When you want to do stuff manually, I think it's not as well
supported.
-Steve
