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:
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 :).
The full query joining both result sets gets more interesting:
#standardSQL
SELECT *, real_rank-rank diff_rank FROM (
SELECT a.id, a.name, a.num_stars, b.num_stars removing_dups, b.num_stars-a.num_stars diff,
ROW_NUMBER() OVER(ORDER BY a.num_stars DESC) rank, ROW_NUMBER() OVER(ORDER BY b.num_stars DESC) real_rank
FROM (
SELECT repo.id, STRING_AGG(DISTINCT 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
) a
JOIN (
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
) b
ON a.id=b.repo_id
ORDER BY num_stars DESC
)
ORDER BY real_rank-rank
Since some projects change their name, but not their id, I used STRING_AGG(DISTINCT repo.name) to get all of their different names throughout the year :).
It's just a handy way of referring to starring activity that doesn't represent how many GitHub users have intentionally starred the repository; for instance, repeatedly starring and unstarring a repo will register them as an event and therefore be counted in the these results.
The most popular "disclaimer:" was "Disclaimer: This user cannot verify whether or not this comment has been edited by /u/spez", as /r/the_donald reacted to /u/spez revelation of editing comments.
October had more regular disclaimers, like "I am not ..." (most popular, 181), "I'm not a" (88), "I have no" (69), "I do not" (52). Further down, 7th place, "I work for" (30).
There were less "disclosures", but when used they said "I am a" (31), "I work for" (29), "I'm not a" (25).
So in an absolute count for "I work for" there were virtually the same number for both, but "I work for" is less relevant in the "disclaimer" space than the "disclosure" one.
(thanks for the tip)
SELECT COUNT(*) c, word, word1, word2, word3
FROM (
SELECT id, offset, word,
LEAD(word) OVER(PARTITION BY id ORDER BY offset) word1,
LEAD(word, 2) OVER(PARTITION BY id ORDER BY offset) word2,
LEAD(word, 3) OVER(PARTITION BY id ORDER BY offset) word3
FROM (
SELECT id, SPLIT(REGEXP_REPLACE(LOWER(body), r'\s', ',')) words
FROM `fh-bigquery.reddit_comments.2016_11`
WHERE LOWER(body) LIKE '%disclaimer%'
) a, a.words AS word WITH OFFSET offset
)
WHERE word='disclaimer:'
GROUP BY 2,3,4,5
ORDER BY c DESC
LIMIT 30
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.
Stars are useful to gauge interest. At StackShare, we rank most everything by number of stacks- meaning usage (https://stackshare.io/javascript-ui-libraries). Worth noting that we just added GitHub stats to OSS pages (not our rankings), mostly because many new tools aren't actually being used in production yet, but there's a lot of interest in them.
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.
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/. 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!
> 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.
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.
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)
> 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.
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 . 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 :)
No, only if you plan on writing any reusable components. Which is sort of the point of any framework.
Well, unless you plan on writing all your code in one file (likely painful), or using an async loader (either slow, or painful because of manually managing dependencies and load order).
Depends on what you see by "largely unique". Do you have a spinner while you wait for data to show up on each page? Then you might have a common spinner component.
Of course, you could also re-code the spinner every single time. Or you could use an existing library of components and then you don't have to deal with modules, only that library does.
Easily done by including the component server side, either in the master page (for common things that are used everywhere) or the page itself. SPA's do literally nothing to componentize sites/apps that we couldn't do before.
How about components that you need twice on the page? Are you going to just include them and their JS twice? Or perhaps build an elaborate server-side module system, one in which components required multiple times are only included once at the end of the page with a script.
You don't have typescript's typechecking for templates.
You don't have higher-order components or first class components. Scoped slots are almost there, but not quite.
Also, "scoped slots" show that vue's simplicity is a bit of an illusion. There is a lot of reinventing the wheel happening underneath to get templates to the basic level of modularity / encapsulation / features of plain old JS.
It was similar with Angular. "Look how simple it is!" - yeah, until you actually need to build something serious with it... then you need to learn 3 times as much as React and all its tooling.
Here is an exercise: Write a spinner component in vue that renders either a spinner, an error message, or any other component (must be passed to the spinner component as a parameter) to which you can pass the data of the fulfilled promise.
You just write a component where you pass two props: a promise to monitor, and a function that will take the data of the fulfulled promise and use it to render anything.
How do you do that in Vue? Is it simpler than the React implementation?
Nobody responded to you, so I took on your challenge :) I'm still pretty new to Vue, but after a while of fiddling I came to a pretty simple solution: https://jsfiddle.net/jsfiddle4ephi/6xLwgqxk/1/
IMO, this is more readable than React, especially if extracted to their own .vue components.
1. Upon a successful resolve, you can make it render props/data to a custom component.
Nice try, but I expect that the template is contained within the app template (or really any other template), i.e. `<spinner promise=promise> <inner template parameterized on data here></spinner>`. I don't want to be passing raw html strings around.
I'm sure vue has some scoped slot template transclusion thing to solve it... actually scratch that, I'm not sure if the equivalent of plain old first class functions exist in its template language :)
Its not just about raw HTML: this might need to be a totally custom template with data bindings to other data. Here is an example, the spinner's promise provides the data for a dropdown component which in turn is bound to a member of the parent component's data.
The challenge does need some more work to make it more realistic :)
No, React beginner tutorial implies learning JSX , then you need to compile JSX into JS. Vue.js does none of that. You just write Javascript and HTML. And yes, Vue.js also supports server-side rendering.
The argument is passing your source code through a REPL makes it significantly more difficult to learn? Learning JSX isn't any more difficult than learning Vue's template binding syntax.
You're completely ignoring the argument. React doesn't really tell you that you can just grab that file but even so you still need to get JSX processed.
It's all about the friction. Vue currently offers significantly less friction to jump into than React.
One wouldn't normally use babel as a REPL. I don't think it even has one (asides from node's own REPL, which isn't normally part of using Babel). Have you ever interactively typed commands into Babel?
> React is ... functionally equivalent to Vue if all you include is react.min.js
Not really, you also need react-dom.min.js ;) But even then, Vue is sporting automatic reactive dependencies, computed properties, watchers, conditional class names, and other things without requiring a trip to some random NPM package. And it's still a smaller payload than react/react-dom
Right. You need inferno-compat as a drop-in replacement for react, as well as mobx for all the other vue features.
The payload for that would be similar to vue: 15KB min+gzip for mobx + 7kB for inferno-compat + 4kb for mobx-react = 26KB min+gzip. Latest vue is also 26KB min+gzip
I started using vue because of the webpack integration and the wonderful single file html/es6/css components. Maybe I'm in the minority? It takes a while (and some guessing) to get it all set up, but it's incredibly productive afterwards (vue-router is a must).
Vue is an alternative for those who did not buy a ticket for the npm/node.js circus but have previous HTML/JS experience.
With vue.js you can write the good old HTML you are used to and enrich it with vue's magic, just like you could do with the original Angular. Anyone who comes from a jQuery or angular 1 background will be able to immediately pick it up. The only thing you will be missing are single file components.
Can you do proper react without studying a node.js Package manager, bundler, compiler, JSX?
One example why vue.js is easy and react is hard I just found: Google "vue two way binding input" and "react two way input binding". React's solution reads like a bad joke.
Uh... what solution, and in what way? React doesn't use "two-way binding", at least not in the sense that other frameworks do.
If you're talking about the idea of "controlled inputs", it fits with the rest of the React philosophy. Driving input values from state keeps the data flow predictable, and makes it easier to implement things like validation.
I've got a number of articles on React form management in my React/Redux links list ([0]). In particular, Gosha Arinich's article on the basics of controlled inputs is excellent ([1]), as is Loren Stewart's article ([2]).
Three unofficial links with each containing more content than the whole official vue.js guide on input binding. And we are talking about a very common feature a lot of users desire.
I guess I just don't fancy the "react philosophy", which is perfectly fine: I am happy we each got what we want.
My guess based on a few minutes of googling to explain the popularity of Vue: unhappy Angular 1 users (with Angular 2 being too different/complex/...?).
As I'm currently very happy with React I know too little about them, so correct me please.
This is just anecdotal, but I've never used Angular. I tried using React a few times but kept stopping since I didn't have enough time to get all the toolchain pieces installed and working together. Then I started hearing about vue so I tried learning it by dropping the vue.js file into the html page and it just worked.
We're sitting on several hundreds (yes, hundreds) "real world" apps and you can bet your butt that some of them do just that.
The more advanced ones use the whole tool chain. Simple ones are just a silly 1 liner script like that. Some don't use JSX at all and just straight up stick React on a page. It all works just peachy.
Superficially angular 1 and vue are very similar, so you might be on to something. But that's something great: There is a reason why angular 1 was widely adopted insanely fast. It's great to have a high performance replacement for it that is still under active development.
> Can you do proper react without studying a node.js Package manager, bundler, compiler, JSX?
Yes. React is just a view rendering library. All those tools are just to make your life easier (including JSX) and don't have any inherent connection to React.
> Google "vue two way binding input" and "react two way input binding". React's solution reads like a bad joke."
Sure, but that's because "two way binding" isn't really Reactive. I guess it depends on what your past experience is, but as far as API surface area React and Vue seem to have similar complexity.
Is React without JSX really something anyone would use though? All the examples are in JSX. Do you have the same first class experience?
> isn't really Reactive.
The go to response of react users when confronted with "I want to do X, why can't I do X?". It might makes sense for you but it pushes a lot of developers away.
I use React without JSX. With CoffeeScript it the render function is nice an concise, and I can use all the regular goodies of a proper programming language.
Granted most of the components/UIs are simple, but it works.
I think it's possible, but at the moment the vue.js usage share is still FAR to small. One of my countries job search platform offers 89 jQuery jobs, 46 angular (1+2), 28 angular2, 28 for react. 1 (one) for vue. (To put this in perspective, 643 Java jobs).
I don't know React but, since I know Vue, I'm confident that I could pick up React fairly quickly.
The reason Vue was easier for me to learn is because it feels like regular JS + HTML, and single file components only strengthen that initial confidence when learning the framework.
Vue just feels relatively normal and was an easier transition for me into the SPA world. React feels like an entirely new thing, even though they are extremely similar at the core.
But the complexity is layered in my experience. You can get very far by reading the guide and changing the names in the DSL to make your app/dashboard/etc and then ship that same day, without really learning any new concepts. Of course when you have to do something new or make a maintainable app you still have your reading ahead of you, but the 0-1 I got my app to do what it needs is really easy-going (again, in my experience for my limited use cases)
Vue is definitely much more approachable. I did not have this experience when using Angular not long ago.
To each their own, but I find the Vue API small and simple enough for me to keep it all in my head at once. Reasoning about things has become it a lot easier because of this.
in short, you write way less lines of code in vue, as opposed to react. its a pretty liberating feeling especially coming from monolithic angular and react code bases. this looks to me like the result of what happens when someone tries to create simple easy to use frameworks as their core philosophy.
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
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!)
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. You can add your email here to get notified when I launch this book and also get access to the early release.
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.
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.
This is anecdotal, but I believe this is due to the steep learning curve of ember.js. As someone who is just trying to pick up this framework, I feel like a complete outsider who is left to fumble around for months until it "clicks" and only then can I understand what is actually going on.
I have been playing with it for the past 4 weeks, and I still feel more in the dark than I did after about a week of React JS/redux.
The tutorial in the ember guides has you use mirage, a client-side mock-server, which is great for learning how to use ember.js in a vacuum. You are completely on your own in figuring out to serve it real data.
Also, if you want to follow ember.js recommended conventions you need to learn how to serialize/deserialize your API into the JSON API specification. Something that is proving to be a pain in the ass when trying to work with rails strong parameters. It is causing me to relearn basic CRUD operations. Most of my time learning ember has been spent rummaging through GitHub issues for active model serializers or jsonapi resources.
Everyone in the ember community swears by the "Data down, Actions Up" philosophy, and yet it isn't mentioned or explained anywhere in their documentation. As someone who is brand new to the community, how am I supposed to understand the proper way of doing things?
Should I be creating actions in my routes, controllers, or components?
Do I even need to use controllers since the apparent trend is moving toward components?
Is ember-data capable of requesting data from the API based on the relationships I build within ember models?
I was able to install a single gem, serve standard rails JSON, and I was up and running with reactjs/redux. Maybe I will be more productive in ember.js with the loveliness that is ember-cli, but learning ember.js is a much more expensive initial investment in my opinion.
It seems like user satisfaction for Ember is lagging behind anything but Angular 1 and Backbone. Presumably Angular 1 and Backbone don't get repeat customers because Angular 2 is out now and Backbone is pretty old. Source: http://stateofjs.com/2016/frontend/
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?
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!
Two factors why VueJS is popular: 1. It is adopted by PHP Laravel communities as the goto framework for frontend 2. It is adopted as underlying for Weex framework (similar to React Native) by Alibaba. Which makes it adopted fast by developers in China.
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).
I was surprised also, the number of stars it has should put it into 3rd place, so I guess it had a bunch before 2016 started already, even though it only went out of beta in late 2016.
Keep in mind that this isn't absolute stars, but stars received last year. Many people who are happily using Angular might have already starred it earlier.
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?
> 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.
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.
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.
It sounds like you're describing Marko.js. Once v4 is released, I predict server-side rendering will become popular again. It's like a vue.js + server-side rendering + client-side rendering + a built-in automatic webpack, yet everything is easy to learn and use. Too good to pass up.
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.
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.
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.
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.
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.
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)
The React part is especially intersting, since Inferno, Preact and React share the React-API, which basically means React blew every other framework away.
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...
Naive query:
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:
If we put all together, these are the real results:* https://docs.google.com/spreadsheets/d/1aDlXrk3U1z5s0-1Is8KH...
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