I have written an open source JS lib named Adze that I believe blows away all of the competition. It is a logging library that runs natively in both the browser and node without any special considerations. It also offers every feature you could want for formatting and annotating your logs as well as a convenient interface for processing your logging data without requiring silly plugin API's.
The API for Adze is also chainable, fully wraps the standard console API's, is TypeScript native, supports mapped diagnostic context and micro-frontends.
My question is, what tips would you give me for marketing the library and making people more aware of it?
I'm also very open to constructive criticism on the library and codebase and would love any feedback that I could be provided.
One good thing would be to show some details without needing to open the dev tools. Lots of people use mobile devices, especially when reading the channels you are likely to market this on.
Yes, I need to refocus the homepage content to show the parts that are better. I think I need to separate the API reference from the Getting Started guide (it's kind of mixed).
It looks overly complicated compared to other logging libraries. There's too much going on and there are concepts that you need to understand to grasp how the API works before being able to use it.
The front page has "everything is configurable", but that doesn't mean much to me since lots of loggers are also configurable.
I actually don't know why I would need or want a global store for logs. Usually shipping logs goes to a third party via something like fluentd, unless I'm missing something here.
Maybe first understand what problems people are encountering and think about how your library addresses that and convey that on the front page as a start?
I can tell you put a lot of love into it, and hope you solve your marketing issues!
I've also written my own logging library with a fluid API that does what I feel are common use-cases:
- standard logging levels
- ability to record metadata
- ability to ingest errors
- flexible hooks that allow you to add in your own functionality
- is meant to be used with your existing loggers (including console.log) and can easily swap to another logger library (like yours if support was implemented)
I built it because my workplace was having the issues mentioned at the top of my library and we now use it everywhere at work because of the consistency it provides and the ability to swap out the underlying logging libraries easily.
For example, we use pino and roarr logging libraries between our services, and our devs don't interact with them directly, they use loglayer instead which uses them under the hood.
We've had some employees leave the company over time and have told me they use it in their workplace too, so I think part of it is get it popular at your job and hope it can spread to others through word of mouth.
Didn't realize adze().log() was overly complicated. If your use case is that basic then that's literally all the code you need from Adze to do your task. It also does alert, error, warn, info, success, fail, debug, and verbose out of the box.
Sorry for the dumb question; but what is the purpose of marketing an open-source library? The more popular a library becomes, the heavier the burden on the maintainer. Why would a maintainer go out of their way to increase the popularity of a library?
First, the entire "Open the dev console for a demo" is cute, but I missed it on the first two views. Just include a regular screenshot.
Second, it isn't even remotely clear what it actually does. It just makes `console.log` a bit prettier? Why should I care?
Third, things like "works in both environments", "chainable API", and "configurable" aren't features. Those are at best implementation details. Again, why should I care?
If you want me to care, show me what problem it solves. If I can't see within 15 seconds how it makes my life better, I'll have already closed the browser tab.
Good point. I should make it more clear what advantages it has over other libraries. The main one you likely won't find great support in other libraries is node and browser. Most only do one or the other.
I agree with other commenters. The pitch didn't do a great job of explaining what problem this solves, so I went to the demo video to find the answer. There's no logging problem big enough in my life to require a tool that takes 48 minutes to explain, so that's when you lost me completely. Even the console demo did more harm than good. It provided no real-world examples of logging (complex objects, multi-stage processes, etc), and some of the fancy bits were worse than vanilla console.log (e.g., the "debug" badge that is dark gray text on a dark gray background).
On my phone so the whole “open the dev console” thing doesnt bode well for me. Code samples look nice though. I would definitely add a demo video / gif.
What are the competitors? Have you used the competitors in the past and encountered pain points that motivated this?
( I have never really cared about logging with js. Console.log has been good enough for me. But I also don’t make monolithic apps in js/ typescript. Just vanilla web js. )
Ya, so when it comes to logging in the frontend, most folks just build an app and throw it out there, but when Joe/Suzy experience a bug, the frontend folks have no idea what it is. Console is really only useful before production. Ideally you would monitor your frontend application the same way you monitor your backend applications. People would find it insane to have no logging in backend apps in production, but people seem to not care about it in the frontend.
I have a very different set of problems/concerns in my current project and when I walk through the website most of it isn't mapping into my current problem+solution space.
The problem this is solving may be obvious from your perspective, but it isn't from mine, and maybe others.
I don't know I need your solution unless I see I have a problem.
Perhaps there are a few simple, general problem cases this solves.
If so you could characterize those in context+problem+solution brief narratives.
That could help others get on the same page as your solution.
The debug library https://www.npmjs.com/package/debug is incredibly popular for Javascript logging, and is also incredibly simple (just a few lines of code).
I have written an open source JS lib named Adze that I believe blows away all of the competition. It is a logging library that runs natively in both the browser and node without any special considerations. It also offers every feature you could want for formatting and annotating your logs as well as a convenient interface for processing your logging data without requiring silly plugin API's.
The API for Adze is also chainable, fully wraps the standard console API's, is TypeScript native, supports mapped diagnostic context and micro-frontends.
My question is, what tips would you give me for marketing the library and making people more aware of it?
I'm also very open to constructive criticism on the library and codebase and would love any feedback that I could be provided.