On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
> Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions.
>
> However, our current use-case is that we want to get a job done, and not creating a web-framework.
>
> 1. For many things the docs are missing, or inconsistent, or wrong. So, it's pretty hard to make your way through it. Or you just start reading the code and reverse engineer vibe. => We are waisting a lot of time.
>
> 2. There are many inconsistencies / half-done implementations in vibe. Again, this makes it hard to find out what works, what doesn't or which parts behave differently. => Costs a lot of time.
>
> 3. Vibe can't handle GET & POST on the same URL... and the bad thing is, the later route will just be ignored, so you don't get any hint or crash. The docs don't mention this clearly. => We waisted a lot of time to find out, that this doesn't work.
>
> 4. Vide uses an own JSON type, not the standard one. We don't understand why, this just makes things much more complicated and one has to mess around with this.
>
> 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary.
>
> So, overall... compared to other web-frameworks we know, there are many pitfalls which just cost a lot of time... We think it's a good base, but there needs to be much less magic, much better docs, much less complexity.

I concur with 1 and 2. We waste lot of time trying to understand vibe code instead of working on the business logic.

Never had issues with 3.

I've found vibe JSON to be a relative of nlohmann::json https://github.com/nlohmann/json
Similar API, seamless code reusability (copy paste). I never really cared about std.json as the usability is not good.

5. is definitely possible with readAll. Never had issues with this. Just dig more into the code ☺️

On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
> Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions.
>
> However, our current use-case is that we want to get a job done, and not creating a web-framework.
> ...
> So, overall... compared to other web-frameworks we know, there are many pitfalls which just cost a lot of time... We think it's a good base, but there needs to be much less magic, much better docs, much less complexity.

Hi Robert,

I found myself in a similar situation recently, and I can't help but ask you: What technology do you use regularly? What drives/draws you to try dlang/vibe.d? Do you have other alternatives to dlang/vibe.d for your project?
In my case we usually work in Node+js/ts (previously Scala+Play) and I wanted to jump to something really performant for a new project without losing code expressiveness and development speed. Dlang seemed a good alternative (I like it much more than Go or Rust).

For a framework to be successful you need at least a minimum of sample code in public domain.
For vibe it is none existent.
I could not even find demo code doing a redirect which is the most basic stuff.
The number of books on a framework is also an indication of the success after a few years.
Compare for instance to Flask or rails.
Also a framework must concentrate on one task.
A web framework should not care about sql. Neither a GUI framework.

On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
> Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions.
>
> [...]

Have you tried Diamond?

https://code.dlang.org/packages/diamond

On Saturday, 10 October 2020 at 16:00:47 UTC, Alaindevos wrote:
> For a framework to be successful you need at least a minimum of sample code in public domain.
> For vibe it is none existent.
> I could not even find demo code doing a redirect which is the most basic stuff.
> The number of books on a framework is also an indication of the success after a few years.
> Compare for instance to Flask or rails.
> Also a framework must concentrate on one task.
> A web framework should not care about sql. Neither a GUI framework.

For samples of redirect please see here
https://github.com/vibe-d/vibe.d/search?q=redirect&type=

But yes, I got your point. Vibe.d and a lot other projects in the D ecosystem are currently at the point where each community member could help to make a little improvement here and there (including documentation/ sample coding / blog posts ,...).

Kind regards
Andre

On 6 Oct 2020 at 10:07:56 CEST, "ddcovery" <antoniocabreraperez@gmail.com> wrote:

> I found myself in a similar situation recently, and I can't help but ask you: What technology do you use regularly?

Hi, well we use a couple of different things. Scripting languages, C, Lua, ..

> What drives/draws you to try dlang/vibe.d?

A prototype we wanted to build while evaluating D as our next tech stack foundation.

> Do you have other alternatives to dlang/vibe.d for your project?

Yes. We are currently looking into Go as well.

> In my case we usually work in Node+js/ts (previously Scala+Play) and I wanted to jump to something really performant for a new project without losing code expressiveness and development speed. Dlang seemed a good alternative (I like it much more than Go or Rust).

Well, for us it's getting more and more clear, that a decision what to use in the future will be based on less and less technical aspects.

The interesting thing about Go is, that their main focus is thinking from an enterprise perspective, not only from a technical one. So, their focus is getting stuff done, keeping maintainability in big, constantly changing teams and stripping everything away, that reduces productivity in such an environment... I don't know about any other language which puts all these non-technical aspects on the top of the agenda.

Viele Grüsse.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:
> environment... I don't know about any other language which puts all these non-technical aspects on the top of the agenda.

Ada, Java, Eiffel are supposed to.

I'm not sure if Go is a success in that department either. I suspect it tanks when programs get large.

thank you for sharing this information with us...

On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:
> On 6 Oct 2020 at 10:07:56 CEST, "ddcovery" <antoniocabreraperez@gmail.com> wrote:
>
>> I found myself in a similar situation recently, and I can't help but ask you: What technology do you use regularly?
>
> Hi, well we use a couple of different things. Scripting languages, C, Lua, ..
>
>> What drives/draws you to try dlang/vibe.d?
>
> A prototype we wanted to build while evaluating D as our next tech stack foundation.
>
>> Do you have other alternatives to dlang/vibe.d for your project?
>
> Yes. We are currently looking into Go as well.
>
>> In my case we usually work in Node+js/ts (previously Scala+Play) and I wanted to jump to something really performant for a new project without losing code expressiveness and development speed. Dlang seemed a good alternative (I like it much more than Go or Rust).
>
> Well, for us it's getting more and more clear, that a decision what to use in the future will be based on less and less technical aspects.
>
> The interesting thing about Go is, that their main focus is thinking from an enterprise perspective, not only from a technical one. So, their focus is getting stuff done, keeping maintainability in big, constantly changing teams and stripping everything away, that reduces productivity in such an environment... I don't know about any other language which puts all these non-technical aspects on the top of the agenda.
>
> Viele Grüsse.

And I feel like you guys will just pick Go because it will get stuff done.


I am in a philosophical mood today so here it goes...

When I just started learning about D ecosystem, vibe frequently popped up as one of the popular frameworks available for the language AND also a reason for ppl to jump in and try out D. However, as time goes, I also pick up many complaints about vibe, its performance and ease of use compared to competitors. This post just solidifies the impression. Bad documentation is the worst thing that can happen to a project which gets promoted as a one of the jems of the language ecosystem and actually hurts the language image much more than does good. Sigh... I will never advice vibe to anyone because I know that better alternatives exist. People will use Go, Python, Ruby, Rust whatever has better docs to get it running fast and not risk wasting time.

Sadly, this is how some languages grow and some don't. And it's not all about the corporate support, hype, GC or random luck, it's about cases like the above.

On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:
> Well, for us it's getting more and more clear, that a decision what to use in the future will be based on less and less technical aspects.
>
> The interesting thing about Go is, that their main focus is thinking from an enterprise perspective, not only from a technical one. So, their focus is getting stuff done, keeping maintainability in big, constantly changing teams and stripping everything away, that reduces productivity in such an environment... I don't know about any other language which puts all these non-technical aspects on the top of the agenda.

Thanks for being so clear, Robert.