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

On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:
> I personally (and many others in the industry... judging by popularity of express (node.js) and the plentiful third-party libraries,..do prefer the router.get() design. Also having everything abstracted in a convenient and consistent way...is very desirable. vibe.d's web interface API is something I've always praised and thanks to how powerful D is compare to say JavaScript. Diet templates is also an example.

I'm not a professional web developer and I don't intend to become one.
My intention is to live a long and mentally healthy life and web development is a serious threat to that ;)

> However that power is not tapped in enough (yet) to favour using D conveniently over node (js). And web developers are interested in getting things done (at least my kind of web devs) rather than getting it our way...or squeezing every bit of efficiency out of it. Part of why v8 is fast by default (for us).

But joking aside, I'm going to use D over Javascript any day of the week no questions asked.
And despite my constant bickering, vibe is a huge accomplishment and improvement over what I used in the past. So kudos.

On Sunday, 20 September 2020 at 00:36:30 UTC, Adam D. Ruppe wrote:
> [...]
> That's it - all the html and javascript are all auto-generated.
>

Amazing :)
Would even be more awesome if it provided a function which could be called from a custom main on top of the FancyMain.
I find e.g. custom parsing of command line arguments incredibly useful.

On Sunday, 20 September 2020 at 01:51:22 UTC, wjoe wrote:
> Would even be more awesome if it provided a function which could be called from a custom main on top of the FancyMain.
> I find e.g. custom parsing of command line arguments incredibly useful.

Yea, the version 2.0 stuff inside cgi.d does that. You can call `cgiMainImpl` from your own main thing (that's all the mixin does anyway) and disaggregate it as much as you want.

I was improving that this week when the baby decided to come, so the rest will be coming a little later. But on my copy right now you can even break up cgiMainImpl because its implementation is:

---
void requestHandler(Cgi cgi) {
   // if you call cgi.dispatcher in here, it does basically
   // what the old FancyMain would do, going to a class.
}

void main(string[] args) {
        alias CustomCgi = Cgi; // just normal class w/o more custom
        if(tryAddonServers(args))
                return;

        if(trySimulatedRequest!(requestHandler, CustomCgi)(args))
                return;

        RequestServer rs;
        rs.listeningPort = 3000; // if you want to change default
        rs.configureFromCommandLineArguments(args);
        rs.handleRequests!(requestHandler, CustomCgi)(); // this may never return
}
---


But I haven't pushed this live yet. Probably will write about it in the blog next week or the week after depending on how everything else irl goes. Still not 100% happy with it, but a big goal with my version 2.0 implementation here is to make more pick-and-choose customization possible while still using the automation in the places you want that.

On Sunday, 20 September 2020 at 00:36:30 UTC, Adam D. Ruppe wrote:
> [...]

I browsed in your arsd docs a bit and I'll have a closer look at the CGI module a bit later.
Your http2 module piqued my interest as it could come in handy some time later :)

Looks like your modules cover everything I need and requiring only 2 or 3 modules that cover everything I would use from vibe beats fighting with dub and vibe's complexity - and I can use a simple makefile :) That alone will save a ton of time.