
Ask HN: How can I better market my JavaScript library - CuriouslyC
I&#x27;m a big fan of building web apps with React&#x2F;Redux, but I found a number of issues with that paradigm, including excessive boilerplate, indirection and difficulty with code re-use.  I wrote an API framework that solves these problems, and I&#x27;ve gotten it to a point where it provides pretty major time&#x2F;code savings.<p>I&#x27;ve presented it a few times for groups at my workplace, and I&#x27;ve always gotten a very enthusiastic response.  Unfortunately, when I try to promote it online, typically my bounce rate is extremely high (~93%) and the time on page averages about 12 seconds.  I get the feeling I&#x27;m not communicating quickly enough how much of a time and energy saver the framework is.<p>I would greatly appreciate if anyone who has had success promoting their library&#x2F;etc online could take a look at my pitch and give me some feedback for improvement.  Ultimately, I wrote it to scratch my own itch so lack of uptake doesn&#x27;t bother me much, but I think it could make people&#x27;s lives a little easier.<p>Links:<p>http:&#x2F;&#x2F;www.nathan-rice.net&#x2F;projects&#x2F;radical&#x2F;
http:&#x2F;&#x2F;www.github.com&#x2F;nathan-rice&#x2F;radical&#x2F;
======
ramtatatam
Hey, had a look into the description and my subjective feeling is first two
sentences should be really high level. What direct benefit would I get? 50%
less time spent on development (making things up now).

My general understanding (not being a javascript expert) is you need really
good justification for adding something on top of stuff like react.

Oh forgot to mention, I'm consumer of these things, not creator.

------
bagelsfromnyc
the only real way to market it is to engage with the core react guy and gals,
and big players in the community. Get them on board. If they like it, they
will tweet about it and spread it. Case studies/real world demos are also
helpful.

------
robwormald
As an aside, angular2 is just coming online and there's a big interest from
our community on redux, so you might share into that community too. The fact
radical is written in TS means it's a great fit :)

------
acemarke
Hey. I think I'm in a pretty good position to give you some feedback. As
background, I maintain a well-received list of high-quality React and Redux
tutorials and articles [0], and a catalog of Redux-related libraries, addons,
and utilities [1]. I also spend a lot of time hanging out in the Reactiflux
chat channels, and apparently currently have the messages posted in Reactiflux
since the service moved to Discord [2]. Finally, I wrote the official Redux
FAQ page from scratch [3]. So, while I'm not a public name in the React
community like Dan Abramov, I'm pretty in tune with what's going on in the
ecosystem.

The first thing to consider is that the size of the target market for any
"addon", "mod", or "extension" for any technology is, by definition, limited
to the size of the user base for the original technology. While Redux is
certainly popular, and basically the winner of the "Flux Wars", you're limited
to a subset of the JS dev community.

A second factor is idiomatic usage. Any framework ecosystem is going to have
an idiomatic way of doing things. Tutorials will teach those same idioms,
training classes will teach those idioms, people will write apps using those
idioms, and the vast majority of the userbase is going to share those idioms.
When you start going outside those idioms, fewer people will understand your
approach, and fewer people will be interested in something that's not "the
normal way".

Redux is fairly minimal, so similar to Backbone, there _is_ a fairly active
ecosystem with people adding numerous different spins in usage, and additional
layers on top, like yours. However, only a few of those have gained particular
traction (like redux-saga). Idiomatic Redux tends towards explicit and
functional, rather than implicit and object-oriented.

Third, there are a number of overlapping approaches and implementations being
developed by different people, as you can see by browsing my addons catalog.
Two dozen libraries implementing "local/component state" in various ways, a
dozen more for "subscribe to changes in a slice of state", and I don't know
HOW many approaches to handling "side effects". Not sure how much of that is
people not knowing what else is out there, how much is "Not Invented Here"
syndrome, and how much is people just trying to scratch an itch. So, any one
addon in a given category is somewhat competing for mindshare, and only a few
will really get attention.

Fourth, honestly, a lot of it really is actually getting the attention of the
"thought leaders and influencers". I signed up for Twitter just so I could
actually reply to some of the conversations I saw going on, and when Dan saw
that, he tweeted out that I'd just joined. Five minutes later I had 30
followers, and 100 by the end of the day. Small potates as Twitter goes,
obviously, but the point is that people followed me just because Dan said I
was interesting. (I'm not, really :) ) The "Doing Whatever Dan Abramov Tells
Me To Do" fake book cover has a bit of truth to it [4]. Now, I'm not saying go
harass Dan, or Ryan Florence, or Christopher Chedeau, but when core members of
the React/Redux community point at stuff, other people look. And, that said,
Dan does tweet out anything that looks vaguely interesting, so tweeting him a
link is a valid approach.

So, Radical. I _do_ actually have Radical listed in my addons catalog, but I
have it listed on the "Variations" page [5], which is where I list libraries
that are distinctly deviating from the idiomatic Redux approach (and, as
you'll note, there's quite a few of those). Looking at it, there's good points
and bad points.

Good:

\- "Reducing boilerplate" is certainly a viable selling point. One of Redux's
core principles is that things are explicit rather than implicit, but
obviously many people dislike much of the verbosity. So, that's a good focus.

\- Radical has documentation. Like, _real_ documentation. An actual
description that tries to give a motivation and explanation, some meaningful
code samples, and API docs. The average JS lib on Github has a short repo one-
liner, maybe a couple paragraphs in the README, and a five-line code snippet
with very little explanation for where it fits in. This is decidedly a good
thing.

Mixed:

\- Focus on grouping actions and reducers. Again, there's numerous opinions
and ideas, and putting those together _is_ one semi-popular approach (per the
"Ducks" concept), so it's not unheard of. On the other hand, Dan encourages
arbitrary reducers responding to arbitrary actions to prevent coupling, and
that's considered the idiomatic approach.

\- Use of Typescript in the lib and the samples. There are certainly
Typescript users in the Redux community, but ES6 is the common approach.

Bad:

\- Use of an OOP approach to managing things. I know it's still dispatching
actions and such and updating its own slice of the store, but the Redux
community is heavily influenced by Functional Programming, and as such an OOP
approach is less likely to gain interest.

\- The fact that you do need to hook the generated reducer into the store
isn't as clearly called out as I'd like to see.

\- Lack of a full-blown example written using Radical. Again, the fact that
you have actual code samples is good, but if this is such a big improvement, a
"real" app example would go a long way to show that.

\- Both the docs and the source are in single files. Both might be easier to
read through if they were split into smaller pieces.

\- There's a number of libraries that look like they do something fairly
similar. The list at [6] has many that are more component-oriented, but
there's some overlap. The list at [5] also has some similar options.

Overall, it looks like a well-written library, with a valid use case, but the
fact that it's a non-idiomatic approach means there won't be as much interest,
and therefore fewer users _and_ fewer people willing to pass it along.

For what it's worth, I hang out in the Reactiflux chat channels [7] evenings
EST if you'd like to drop in and talk about it.

[0] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

[1] [https://github.com/markerikson/redux-ecosystem-
links](https://github.com/markerikson/redux-ecosystem-links)

[2] [http://pipend.github.io/reactiflux-
dashboard/#/fame?ago=1+ye...](http://pipend.github.io/reactiflux-
dashboard/#/fame?ago=1+year)

[3] [http://redux.js.org/docs/FAQ.html](http://redux.js.org/docs/FAQ.html)

[4]
[https://twitter.com/ThePracticalDev/status/71846227233570406...](https://twitter.com/ThePracticalDev/status/718462272335704064)

[5] [https://github.com/markerikson/redux-ecosystem-
links/blob/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/variations.md)

[6] [https://github.com/markerikson/redux-ecosystem-
links/blob/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/component-state.md)

[7] [https://www.reactiflux.com](https://www.reactiflux.com)

~~~
hohohoho
for the record, I didn't follow you because of Dan's tweet. I followed you
because your links are excellent! You answered my question in reactiflux in
detail. love love. kbye

------
joao_arau
[ Disclaimer: I have no OS libs to my own name, but I: (a) do enjoy using a
good bunch of them ;-) and (b) I hold a degree in Advertising, if that helps
on anything :-P ]

So here's a couple of things that I was able to notice right upfront that can
help you improve:

Improvement 1: Your long textual diatribes are most definitely scaring people
away (including myself!). Seriously, even inside your code samples has long,
+10 line comments, what's up with that? No wonder you're having such a high
bounce rate!

What you have to understand is that developers don't want to be _told_ why
they should use our library. Instead, they want to just "get it". In other
words, they want to be invited into the discovery process and reach that
conclusion by themselves - usually by seeing some practical application (aka
code samples) and deciding by themselves if they like what they see and if it
looks like something that works for them ... this discovery process is a big
part of the fun of picking up new tools for ourselves and should not be
underestimated.

So, to put it on more practical terms, make sure you use a code-first approach
to your ReadMe file and begin with commented code samples, not explanations,
and make sure the code comments are no longer than 2 lines, too. Also look
around at the ReadMe of the some of the most successful libs out there and
with ideas above in mind and I'm sure you will quickly recognize some best
practices and nifty tricks that you can emulate in your own ReadMe file.

Improvement 2: Another thing you can do is put a gitter/discord/slack button
up there and also make sure you're making yourself available as much as
possible for quick feedback. This is not 1999 anymore and with all the
hundreds libs out there fighting for developer mind-share, people tend to
favor solutions which have some sort of community/ecosystem they can rely on
for those though moments.

Improvement 3: Finally, a video tutorial is something that a lot of people out
there are linking to on their ReadMe, as it's a great way to show that you
really "means business" when it comes to getting people up to speed with your
lib. The reasoning for them is that -- "Hey if someone went to all the trouble
of investing his/her time to make a video just to show me how to use this
thing, maybe I should really invest some __my own time __to take a closer look
at this ". If you don't feel like you can make a good job of doing the video,
just find someone to do it for you - but make sure it has: a) nice, clear
audio b) large, visible text; c) 5 min or less of duration d) A hands-on
approach to it (aka less talking, more coding).

Hope these suggestions help a bit and good luck conquering the World with your
lib ;-)

