Hacker News new | comments | show | ask | jobs | submit login
Ask HN: How can I better market my JavaScript library
3 points by CuriouslyC on June 3, 2016 | hide | past | web | favorite | 6 comments
I'm a big fan of building web apps with React/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've gotten it to a point where it provides pretty major time/code savings.

I've presented it a few times for groups at my workplace, and I'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'm not communicating quickly enough how much of a time and energy saver the framework is.

I would greatly appreciate if anyone who has had success promoting their library/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't bother me much, but I think it could make people's lives a little easier.

Links:

http://www.nathan-rice.net/projects/radical/ http://www.github.com/nathan-rice/radical/




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.


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 :)


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.


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

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

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

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

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

[5] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[6] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

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


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


[ 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 ;-)




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: