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 ☺️
