
2016 JavaScript Rising Stars - gulbrandr
https://risingstars2016.js.org/
======
fhoffa
Since they didn't publish their data source, let me add a useful note: How to
count the number of stars using GitHub Archive and BigQuery.

Naive query:

    
    
      #standardSQL
      SELECT repo.id, ANY_VALUE(repo.name) name, COUNT(*) as num_stars
      FROM `githubarchive.month.2016*`
      WHERE type = "WatchEvent"
      GROUP BY repo.id
      ORDER BY num_stars DESC
      LIMIT 1000
    

But let's fight "star fraud". There is an easy way to register "fake" stars -
if you star and unstar a project repeatedly, each time this will register as a
WatchEvent on the GitHub Archive log.

Better query, removes duplicates:

    
    
      #standardSQL
      SELECT repo_id, ANY_VALUE(name) name, COUNT(*) as num_stars
      FROM (
        SELECT repo.id repo_id, ANY_VALUE(repo.name) name, actor.id
        FROM `githubarchive.month.2016*`
        WHERE type = "WatchEvent"
        GROUP BY repo.id, actor.id
      ) 
      GROUP BY repo_id
      ORDER BY num_stars DESC
      LIMIT 1000
    

If we put all together, these are the real results:

* [https://docs.google.com/spreadsheets/d/1aDlXrk3U1z5s0-1Is8KH...](https://docs.google.com/spreadsheets/d/1aDlXrk3U1z5s0-1Is8KHOowJ_oSw79mzwAOPmK5LmeI/edit)

Projects like 'fivethirtyeight/data' lose -864 stars (23%), going down 230
places in the ranking, while projects like 'FormidableLabs/nodejs-dashboard'
lose less than 1% of their stars, going up 49 places.

When I said 'stars fraud' I'm not presuming malice, but with these star
rankings we do create an incentive :).

Disclaimer: I'm Felipe Hoffa, and I work for Google Cloud
[http://twitter.com/felipehoffa](http://twitter.com/felipehoffa)

~~~
BinaryIdiot
Nice work! You should create a web app to allow anyone to run this query so I
don't have to setup a SQL DB with the archive data :)

(Naturally I want to check how my own project faired against star fraud)

~~~
fhoffa
You can try it in the next 5 minutes!

[https://www.reddit.com/r/bigquery/comments/3dg9le/analyzing_...](https://www.reddit.com/r/bigquery/comments/3dg9le/analyzing_50_billion_wikipedia_pageviews_in_5/)

BigQuery is always ready for your queries. One free terabyte of analysis each
month. No credit card needed :)

~~~
BinaryIdiot
Nice sales pitch :)

I might take a look a little later. Good info!

------
wyuenho
I'll probably get downvoted for this, but I think counting github stars
probably only reflects visibility but not actual usage. To give you an
example, cf-ui is counted as one of the "best" React UI component out there in
bestof.js.org, but this project is not currently meant for general
consumption. This fact is reflected in npm stats.

I think we as a community should be very vary about these "scorecard" websites
and their methodologies. These things tend to be a self-fulfilled prophecy.
I'm not sure I want to see a couple of brand name companies start monopolizing
our eyeballs and technical conversation. I'm also very vary about people
making decisions based on these sites. While not everyone is completely
different from others, I'd like people to make their own decisions based on
their only thinking process rather than just jumping on the new and shiny from
the big names all the time. Not that this appears to be an issue right now,
just a few words of caution.

~~~
soneca
Why did you believe your very reasonable comment would probably be
downvoted???

~~~
wyuenho
My general pessimistic feeling for how human not learning from the past, but
I'm glad I'm wrong now :P

------
falloutx
Fascinating to see Vue.js and Inferno both doing so well last year. Vue is
definitely lot easier to learn than React, for new Developers, but I could be
wrong since I haven't tried it a lot. Don't know how it scales up for large
applications.

Preact is also another dark horse. This year we are going to see a few more
"react-like" UI libraries.

In node, really happy to see Feathers catching up with other more popular
frameworks like Express. First time I reached to feathers was by literally
searching "Firebase Alternative".

AVA the Test runner, really never heard of it at all. May be I am too behind
in the "Test Runners" category. I only use Mocha.

Also, they should have added a category for graphics libraries like Three.js,
Fabric.js, Paper.js etc.

~~~
ng12
> Vue is definitely lot easier to learn than React

How so? Vue actually has a lot to it -- lots of template directives, computed
properties, directives, etc.

~~~
spion
The perceived upfront cost is lower with Vue. You can just put it on the page
and voila, you have observables, computed properties, templates, everything.
No webpack, no transpiling, no modules, no npm.

This is also how angular got popular. The tutorial said: Just add this one JS
to the page and start making SPAs! Here is a 10 line example with everything
in it explained, and it works!

Same with mongodb - their 10 step interactive tutorial website was extremely
convincing

Not many people know you can get started the same with react by putting react,
mobx and mobx-react on the page
[https://jsfiddle.net/ugh2xhfg/](https://jsfiddle.net/ugh2xhfg/). Thats
because its not advertised. You will still need babel / compilation though.
JSX is still a major barrier to entry.

There is no easier way to make a project become popular than to offer an
unrealistic-for-production getting started page that will get you rolling by
doing almost nothing!

~~~
ng12
> You can just put it on the page and voila, you have observables, computed
> properties, templates, everything. No webpack, no transpiling, no modules,
> no npm.

This is a false dichotomy. React is a fully-featured, standalone library and
functionally equivalent to Vue if all you include is react.min.js. You don't
need webpack or npm, you don't need Redux or MobX. This attitude stems from
people learning React from create-react-app (which is geared towards a fully-
featured, multi-developer, production-ready application) without doing FB's
TodoMVC or even reading the React docs.

~~~
brilliantcode
I don't think you can ignore the relative less amount of pain associated with
Vue.js over React.js.

It's just easier to get started with Vue.js and I'm just tired of the constant
marketing campaign from Facebook...guess what 99.9% of companies out there
_aren 't facebook or google_.

The relative ease to get into Vue.js and it's fast growing popularity are
signs that it's hitting the right pain points with developers who don't work
at Facebook.

~~~
spion
The thing is, in any real project where you need a front-end framework, you
will need modules very soon. And once you need modules, you need a bundler,
which means you need a build process. While you are building, you might as
well take advantage of neat ES.next / TypeScript features such as decorators,
as well as maybe type-checking for JSX templates, and so on.

This is the reason why I always choose React.

(Well, that, and the huge existing ecosystem, and fact that components are
first class in the template language e.g. you can pass a component as a
parameter to a template and you can bring components into scope by importing
them. But those are fairly advanced features)

~~~
nailer
> The thing is, in any real project where you need a front-end framework, you
> will need modules very soon.

Sure, and modules are good even if you didn't need data binding at all. But
the data binding and the module system you use are orthogonal and CommonJS/npm
is still larger than any other module system by 10x, maybe 100x, maybe more.

~~~
spion
Right. CommonJS is great, I actually like it more than ES6 modules. But even
with CommonJS you still need the bundler and the build step.

You can get data binding in React with MobX, which pretty much gets you on par
with Vue: [https://mobx.js.org/getting-
started.html](https://mobx.js.org/getting-started.html) . If you don't like
how anemic setState is, and don't like the boilerplate / straightjacket of
Redux, MobX is the way to go.

Admittedly, React's simpler options are harder to find :)

------
dehef
It isn't a good indication for the framework value itself. A star in github
its like "meh I heard a lot about react-thing, that look complicated but can't
be that bad, I should take a look one day" Its a self-persuading buzz

------
insin
Where are the star counts from?

Create React App was created in 2016 and has more than 18k stars but is shown
as having gained 5.6k stars in 2016 (I think it got more than that in its
first week!)

~~~
mxstbr
I contacted the author and those numbers have been fixed.

------
silvaben
Excited to see Vue doing so well on this list. I have been using it for the
last few months at my day job, and I have been pleasantly surprised by it. I
have tinkered with React & Angular in the past and I can second that the fact
that compared to the other frameworks, getting started with Vue is a lot
easier.

The ecosystem around it also quite mature - VueRouter & Vuex are well-tested
solutions in case you have a use for it.

Another advantage that it has is its documentation & guides. It is quite
exhaustive and easy to follow. My only gripe was that it doesn't go into the
details of building a complete "single-page-app" that uses the accompanying
tools (vue-cli, vuerouter, vuex etc).

Based on my learnings over the past few months, I have started writing a small
ebook that goes over the process of building a full-fledged app.

I have created a small subscription form -
[http://eepurl.com/cvUk5D](http://eepurl.com/cvUk5D). You can add your email
here to get notified when I launch this book and also get access to the early
release.

~~~
jaequery
check out nuxt, it does exactly that. a full fledged vue cli starter. its
eloquently made, just like vue.

------
anm89
Really Sad to me that Ember.js gets so little love. It is hands above Angular
1 or 2 in my mind and the only JS front end framework that I feel productive
in.

~~~
petercooper
I run a JavaScript focused Twitter account with 235K followers and on
analyzing our 2016 stats this week, we found most of the Ember things we
linked ended up in the bottom quarter of tweets ranked by engagement :-( I
know Ember, know the (great) people involved, and try to promote it when I
can, but for some reason my audiences aren't keen on it in large numbers. Yet
whenever I do encounter an Ember user, they are always so full of praise, and
ThoughtWorks gave it a strong recommendation recently too.

------
lacker
Hmm, Create React App is listed as "+5.6k stars", but it was launched in 2016
and has over 18,000 stars right now. Perhaps an error in the data processing?

~~~
BinaryIdiot
Like fhoffa's example they may be attempting to account for star fraud (though
that's a pretty huge amount if that's the reason for the difference).

~~~
fhoffa
Numbers on the post are weird.

'facebookincubator/create-react-app' got 18187 stars in 2016 (17857 when
removing duplicates).

[https://docs.google.com/spreadsheets/d/1aDlXrk3U1z5s0-1Is8KH...](https://docs.google.com/spreadsheets/d/1aDlXrk3U1z5s0-1Is8KHOowJ_oSw79mzwAOPmK5LmeI/edit#gid=1674844484)

------
michaelrambeau
Hello there, this is Michael Rambeau, the writer of JavaScript Rising Stars.
Thank you, everyone, for your comments. It's very nice to see people talking
about things related to my project. As some people mentioned, after the
initial release, there was an issue about the count of stars, for some
projects. I'm sorry about that, it has been fixed during the following
releases. I will try to take into account the ideas discussed there, when
things calm down. Thank you a lot!

------
ArtDev
Who says that github "stars" are a quality indicator?

I use stars to mark projects I am interesting in but haven't tried yet. I am
sure many people do the same.

------
juice_bus
Honestly, I was surprised to see Vue at #1 and not React.

~~~
zumu
Stars per year is always going to favor newer technologies. Which is why I
believe this metric encourages framework churn.

~~~
amirmansour
True, but there are other frameworks that came around the same time and have
not reached the momentum of Vue.

------
cygned
Interesting that Angular 2 doesn't seem to be very popular - yet?

~~~
pfooti
I think there's a difference between usage and github stars. I generally don't
really star many Big projects like angular2 or react, since there's so much
notification spam on it. I star smaller things which are likely to have less-
frequent updates, but each update could well be a big deal (relative to the
size of the project).

------
tabeth
Somewhat off-topic, though it may be relevant.

Is it that much more difficult/complicated to have a server side rendered app
with pure JavaScript sprinkled in versus SPA vs. no JavaScript?

The situation I'm thinking about is the following:

firstApp.domain.com

secondApp.domain.com

If you have an SPA then you literally can just have separate SPAs for each sub
domain served statically. You could also have everything rendered server side
using whatever back-end you're using. Finally, you can have server-side
rendering and add JavaScript when necessary, but this seems to add complexity
as your team would now need to know whatever templating language your server-
side framework uses plus the front-end framework. Am I missing anything?

~~~
pyrophane
> but this seems to add complexity as your team would now need to know
> whatever templating language your server-side framework uses plus the front-
> end framework.

If you use server-rendered templates, the people responsible for your front-
end will have to know a few things about the backend and vice-versa, because
everything is a bit more integrated.

Using an SPA allows your front-end guys to just say "we need an API that
delivers this" and your backend guys can just publish a doc on that API.
Neither team really has to know that much about how the other makes their part
work, and both teams can create their own ideal environment without having it
dirtied by the other team's needs or constraints.

That being said, I wouldn't advocate for building an SPA purely for developer
convenience.

~~~
tabeth
Do you have any war stories to share? Given that ultimately producing value to
the business is the only thing that matters, wouldn't doing it, if it
conveniences them be the right thing to do?

I'm not super knowledgeable about this (<2 years experience), but I see little
downside. Of course, I don't know what I don't know.

~~~
pyrophane
I think the choice to adopt an SPA or not should be driven primarily by the
project requirements. Are you mostly going to be serving up long-form
documents or presenting users with tradition forms, or are you building
something that needs to feel more like an "app" that is highly responsive to
user interaction. I would choose an SPA only if the latter were true.

You essentially have two problems: 1) how to make common code available for
reuse across what is essentially two separate websites/apps and 2) how to make
it so that front-end focused developers and backend focused developers can
work effectively together.

I don't think that either problem is best solved by adopting an SPA if you
would not otherwise be driven to do so. Problem 1 can be solved in a lot of
ways. You can build a set of common services into a library used by both apps,
for example. This allows you to isolate and reuse common functionality without
the overhead of an HTTP service layer if you don't really need it.

Problem 2 I would say winds up being more about both teams getting things "the
way they want to do it" rather than strictly about difficulty learning. I've
yet to see a server template system that would present much of a problem to a
front-end focused person. The real problem is how can their toolchain, which
may include things like transpilation, sass compilation, and a separate test
runner, be integrated into the backend build process and framework. A lot of
backend frameworks are somewhat opinionated about how these things happen, but
there are ways to integrate just about anything with anything else.

Anyway, it really just boils down to understanding how your app would be best
served based on how it needs to work, and doing it that way. There is a good
bit on the trade-offs between the two linked below [1], although its author is
biased towards "shared" front-end/back-end frameworks like meteor, and I don't
agree with some of the conclusions.

[1] [https://www.quora.com/What-are-the-tradeoffs-of-client-
side-...](https://www.quora.com/What-are-the-tradeoffs-of-client-side-
rendering-vs-server-side-rendering)

------
minimaxir
[deleted]

~~~
fnovd
The numbers in the article and the numbers in your spreadsheet differ. The
article contains analysis and categorization that your spreadsheet lacks. The
data in your spreadsheet come from a public dataset, as I'm sure the data from
the article do. Github stars are not a novel metric. I don't see why the
author would need to cite you.

~~~
minimaxir
Huh, the numbers do differ, sometimes by thousands, which doesn't make any
sense at all, even if they are using internal metrics.

The reason I was suspicious is that the methodology for determining GitHub
stars by year is not trivial, and it is not described in the post, and other
comments in this thread questioned it. I removed the OP.

------
novaleaf
I don't understand why Hapi doesn't get much love these days. It's a
monolithic framework, which means it's extremely opinionated in how things are
done, but also it means you don't need to go hunt down 3rd party packages to
cover features that every server dev needs out of the box.

------
gcp
Looks similar to [http://stateofjs.com/](http://stateofjs.com/)

~~~
bertjk
State of JS was a survey with questions and answers, this page counts
"...stars added on Github, over the last 12 months".

State of JS would better reflect the popularity of tools within the
audience(s) that the survey was distributed in, this page really just shows
what has had buzz in the last 12 months.

------
franciscop
I love that this made it to the report in the "React Boilerplates":
[https://github.com/tj/frontend-boilerplate](https://github.com/tj/frontend-
boilerplate)

> A boilerplate of things that mostly shouldn't exist.

~~~
k__
I never understood the boilerplate hype.

My co worker used one four our app and it was horrible, it used Flummox and
which was discontinued and we had to rewire everything for Redux later, since
we didn't write the Flummox wiring in the first place, this was madness.

~~~
shados
boilerplates are nice when you want to test out a quick Hello World while
having access to a full toolchain.

No one in their right mind would use that for production though (but
unfortunately they do...so many people pushing huge, complex webpack configs
that they don't need or understand)

~~~
k__
totally.

It let's you show something fast.

------
the_wheel
Meteor should be on the list of Node.js frameworks (absent a more appropriate
category).

------
paulddraper
#4 in TOC is _React Boilerplates_.

Perhaps Javascript is catching up to its big brother.

~~~
k__
At least FB tries to work against this with create-react-app

------
k__
The React part is especially intersting, since Inferno, Preact and React share
the React-API, which basically means React blew every other framework away.

~~~
brlewis
Mithril components are also in the same family. JSX works with Mithril out of
the box.

------
Mizza
This is awesome, somebody please make one for Python!

------
Raphmedia
Happy to see Aurelia in that list. It's my discovery of the year. I have a lot
of fun with it!

------
andrethegiant
Sublime Text not on the list of notable IDEs?

~~~
pfooti
It's github stars, right? ST isn't open source, so it's not hosted on github.
But it is notable. That said, where's vim?

~~~
achairapart
I think the list is about IDEs built with JavaScript, ie Node.js/Electron.

~~~
pfooti
ah, that makes sense.

------
carsongross
On the front end, intercooler.js[1] actually gained more stars in 2016
(~3000)[2] than Mithril (which I like, this is not to take anything away from
the Mithril guys!) This was in large part due to a big HN bump in November.

I know it's too contrarian and idiosyncratic to get a mention on a JS survey,
but I have to get he word out somehow...

[1] - [https://github.com/LeadDyno/intercooler-
js](https://github.com/LeadDyno/intercooler-js)

[2] - [http://www.timqian.com/star-history/#LeadDyno/intercooler-
js...](http://www.timqian.com/star-history/#LeadDyno/intercooler-
js&lhorie/mithril.js)

