Revitalizing Beem - Call for feedback

I'm planning to fork Beem and maintain it with proper documentation and unit-test coverage. I'll also address current known bugs, and update the library as HIVE RPC APIs progress and release more updates in the future.

However, I want to understand the current problems users having. I see a lot of complaints that it's not maintained. It's understandable, but there is no exact definition of the problems about what did you try, what went south, and so on.

So, if you're using Beem, please let me know in the comments. And if you're using Beem and having bugs, or have feature requests, also include in the comment.

Before working on that, I want to learn if there is still a user base trying to work with it. I personally use Beem in a couple of scripts, and they're working fine in general, however, my use case is limited, as %90 of my work flow is handled by Lighthive.

You might wonder what will happen to Lighthive? It will stay the same. By design it's a simple library and don't have much encapsulation, classes, helpers like Beem.

It's a trade-off between usability and complexity, so Lighthive will stay there and maintained as is for power-users, while Beem will be more user-friendly starting point for less experienced people in the programming.

Also open to any collabration for maintaining it, but this is a topic brought before - it seems we need one person to take the first step for active maintenance, then the contributions will follow.

TL;DR:

  1. Please reply in the comments if you're using Beem
  2. Please explain the current problems you have with Beem.
  3. Please explain the feature ideas for Beem.
H2
H3
H4
3 columns
2 columns
1 column
58 Comments
Ecency