Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

medium.freecodecamp.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#21

Post by dleslie »

Cynddl wrote: post #2

Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…

Old last commit isn't a good metric for health; particularly for projects that don't go anywhere near hardware. There's plenty of time-tested and popular C libraries that only _very_ rarely see a patch suggestion, let alone a commit.

Check the mailing lists and forums; and look around for projects that depend on it.

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#22

Post by yorwba »

c8g wrote: post #19
Retr0spectrum wrote: post #14

Earlier quoted context omitted.

Apparently, around $325 for 1500 stars: hxxp://githubstars.com/

http://githubstars.com this a really helpful site. curl project got 5k stars from it :p

I believe your parent comment censored censored the link to avoid boosting the site's page rank. You may want to edit your comment (or not).

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#24

Post by spraak »

yorwba wrote: post #22
c8g wrote: post #19

Earlier quoted context omitted.

http://githubstars.com this a really helpful site. curl project got 5k stars from it :p

I believe your parent comment censored censored the link to avoid boosting the site's page rank. You may want to edit your comment (or not).

Can you explain what that means/what happens?

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#25

Post by mattbrewsbytes »

insulanian wrote: post #4
Cynddl wrote: post #2

Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…

Old last commit date could mean two things: 1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it. 2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future. I thin…

This used to be indicated by version numbers:

- 0.x = version in some beta/alpha/unstable state

- 1.x = version in somewhat stable/complete state

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#26

Post by nerdponx »

spraak wrote: post #24
yorwba wrote: post #22

Earlier quoted context omitted.

I believe your parent comment censored censored the link to avoid boosting the site's page rank. You may want to edit your comment (or not).

Can you explain what that means/what happens?

Search engines rank sites (in part) according to the number of other sites that link to them. Wikipedia is ranked very highly in Google largely because many, many sites link to Wikipedia.

The PageRank algorithm to compute these kinds of rankings was one of Google's early innovations, and was the secret to its initial dominance over the early-2000s search engine market.

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#27

Post by colinbartlett »

nerdponx wrote: post #26
spraak wrote: post #24

Earlier quoted context omitted.

Can you explain what that means/what happens?

Search engines rank sites (in part) according to the number of other sites that link to them. Wikipedia is ranked very highly in Google largely because many, many sites link to Wikipedia. The PageRank algorithm to compute these kinds of rankings was one of Google's early innovations, and was the secret to its initial dominance over the early-2000s search engine market.

But the links all have rel="nofollow"

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#28

Post by nsmith7979 »

Hey, I'm the author of the "GraphQL Visualizer" tool (http://nathanrandal.com/graphql-visualizer/) that they mention in the article as inspiration for their project.

This new project is quite nice and definitely a step up from mine.

Also wanted to mention that there is a CLI version of the visualizer at https://github.com/sheerun/graphqlviz for when you want to quickly visualize a GraphQL endpoint for documentation purposes, etc. Keep up the good work!

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#29

Post by nfriedly »

yorwba wrote: post #22
c8g wrote: post #19

Earlier quoted context omitted.

http://githubstars.com this a really helpful site. curl project got 5k stars from it :p

I believe your parent comment censored censored the link to avoid boosting the site's page rank. You may want to edit your comment (or not).

FWIW, it looks like HN now adds rel="nofollow" to links in comments. So, it shouldn't matter either way.

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#30

Post by ryandrake »

nerdponx wrote: post #17

But after looking at the source code we found a fatal flaw in this tool: it used Graphviz — a decades old tool written in plain C and compiled to unreadable JavaScript using Emscripten. Are the "decades old" and "plain C" aspects supposed to be bad things? It seems like the real problem is "compiled to unreadable JavaScript". Graphviz is a great example of "if it ain't broke, don't fix it".

"Decades old" often means that it is mature, has relatively few bugs, and is not going to soon go through some major API-breaking re-architecture just because the maintainer wants to experiment with a new framework-of-the-week. "Written in plain C" means I will likely be able to call/integrate it into my project with little fuss. These are both things to actively look for when browsing for open source libraries.
Post reply on HN