📊 Languages' Popularity on DEV

Publish Date: Oct 31 '18

128 82

Today, while writing an article on PHP resources on DEV, I found myself comparing the number of articles of the most popular language tags out there (PHP, JS, Go, ...).

Finally, I searched a bit and I did it for every languages.

Before today, I just had the feeling that many posts were about Javascript or related stuff. The fact is that the results are amazing: 56% of the posts related to programming languages are about Javascript! 😲

Language	Framework or related	#	%
Ada		1	0.01%
Julia		1	0.01%
Cobol		2	0.02%
Smalltalk		2	0.02%
Objective-C		5	0.04%
Lua		11	0.09%
Erlang		14	0.12%
R		22	0.19%
Haskell		22	0.19%
Lisp		24	0.20%
	incl Scheme	5	0.04%
Crystal		26	0.22%
Dart		34	0.29%
Perl		35	0.30%
Clojure		42	0.35%
Scala		49	0.41%
Elm		75	0.63%
C++		88	0.74%
Rust		121	1.02%
C		154	1.30%
Kotlin		156	1.32%
.NET		156	1.32%
Elixir		167	1.41%
Swift		169	1.43%
C#		200	1.69%
Android		374	3.15%
Java		383	3.23%
Go		393	3.31%
PHP		725	6.11%
	incl Symfony	14	0.12%
	incl Laravel	182	1.53%
Ruby		859	7.24%
	incl Rails	324	2.73%
Python		865	7.29%
	incl Django	95	0.80%
Javascript		6684	56.36%
	incl jQuery	38	0.32%
	incl Express	78	0.66%
	incl Redux	128	1.08%
	incl Typescript	188	1.59%
	incl Angular	260	2.19%
	incl Vue.js	368	3.10%
	incl React Native	382	3.22%
	incl Node.js	782	6.59%
	incl React	1066	8.99%
TOTAL		11859	100.00%

I included frameworks, libraries and variants in their related languages (e.g. jQuery in Javascript.

More than Javascript, the statistics show that frontend languages, frameworks and libraries are massively tagged unlike backend ones that are under-represented.

A language like Go only has 3.3% of the language tags, which is very low compared to the real popularity of the language.

Haskell is almost inexistent whereas it's very popular in functional programming.

I don't know what to think about this 🤔. And you?

Comments 82 total

Ben HalpernNov 1, 2018

It looks like JavaScript is the most complicated and error-prone language, that's why so many people need to talk about it on DEV

I think this is somewhat true. JS has lots of issues and a complicated history, but it’s still practical as hell given its popularity.

JavaScript: Famous for being famous.

And yeah, the site is pretty web-centric.
- rhymesNov 1, 2018
  
  JavaScript: Famous for being famous.
  
  An instagram influencer basically
  - KNov 1, 2018
    
    Pf
    - kaelscionNov 1, 2018
      
      Or a member of the Kardashian family
      - Ben HalpernNov 1, 2018
        
        This definitely calls for a listicle post mapping JS libs/frameworks to members of the Kardashian family.
        
        Kris is jQuery
- Jesse M. HolmesNov 1, 2018
  
  I love JavaScript’s story, how it was this hastily created, incredibly flawed plaything that has grown into one of the most utilized tools in existence. It was an underdog—actually, it wasn’t even in the same fight—but it has allowed so many other underdogs to break into this industry. For better or worse, I love a good backstory.
- Yaser Al-NajjarNov 1, 2018
  
  I wish one day we would have a modern ES1 removing all the previous crap, and keeping the clean simple parts of the language... ooh, it's just a wish!
- Nathanael DemaconNov 1, 2018
  
  JavaScript: Famous for being famous.
  
  Well, it's actually the first (and only) Back-End and web Front-End language
- Ryan NewtonJun 11, 2019
  
  It seems good for building network effects that DEV is starting with a concentrated topic area.
  However, I now feel a bit mislead by this HeavyBit article, which was pushing DEV.to as already a destination for all developer topics, ready to immediately replace Hacker News and Reddit (and better because of better moderation / code of conduct / etc).
  
  I hope to see this community grow in areas like containers, OS, and systems programming.
Ben HalpernNov 1, 2018

I feel like it wouldn’t be quite like this without Node. JS didn’t explode like this until Node made teaching full-stack JS so practical.
Helen AndersonNov 1, 2018
There's 100 posts tagged with SQL. If you consider that a language in this case :)
- jess unreinNov 1, 2018
  
  Ooh good point. I know this site is very web focused right now, but I’d love to see more quality SQL and database content represented.
  - Helen AndersonNov 1, 2018
    
    Well in that case ...
    
    I highly recommend Randy (@randysims ), Mark (@booyaa ), and me :D
    - jess unreinNov 1, 2018
      
      Excellent. Thank you for the follow suggestions. There are just so many people! 😵
  - kaelscionNov 1, 2018
    
    Do tutorials on how to use ORMs count as db content?
    - jess unreinNov 1, 2018
      
      Yeah definitely!
      
      What's your poison: Django ORM or SQLAlchemy?
      - kaelscionNov 1, 2018
        
        I primarily use SQLAlchemy
        
        jess unreinNov 1, 2018
        
        I like SQLAlchemy a lot. Some of my friends think it doesn't look as nice as Django ORM, but you can do so much more with it!
        
        rhymesNov 1, 2018
        
        you can do so much more with it!
        
        That's the power of the data mapper pattern ✌🏾✌🏾
        
        SQLAlchemy is my favorite 🌞
        
        kaelscionNov 1, 2018
        
        I totally agree. I learned Python Web Development from, what I consider to be, the end all of Flask tutorials from Miguel Grinberg The Flask Mega Tutorial which exclusively uses SQLAlchemy.
        
        Since that time I've used others like PeeWee, but they just never had that special something that made SQLAlchemy so straightforward.
        
        The many-to-many relationships and pivot tables in SQLAlchemy just make so much more sense than in any other ORM I've used. Personally, I've never used Django so have never used its ORM, but I doubt its nearly as good a SQLAlchemy!
        
        I just...(sigh) love inheritance...so much. I remember not having classes way back when and it was so........so very sad. :P
        
        rhymesNov 2, 2018
        
        The many-to-many relationships and pivot tables in SQLAlchemy just make so much more sense than in any other ORM I've used. Personally, I've never used Django so have never used its ORM, but I doubt its nearly as good a SQLAlchemy!
        
        Django ORM is based on the Active Record pattern (the same as Rails's ActiveRecord). SQLAlchemy ORM is based on the Data Mapper pattern. ORMs (including the Flask-SQLAlchemy layer) tend to suffer from the object-relational impedence mismatch.
        
        @dmfay explained it well here:
        
        Dian Fay
        Jul 18 '18
        
        More fully, it's the "object-relational impedance mismatch". This refers to the central problem of using an object-relational mapper (O/RM) framework to handle data access and manipulation. O/RMs require you to implement a parallel data model in your application code: if you have a users table, you'll have to write a User class which represents records in that table, and so forth.
        
        The issue is that relational databases work in a fundamentally different manner from application code. A relational database cares about two things: records, and relationships between records as denoted by foreign key constraints. Application code works with all manner of more complicated data structures and techniques: hierarchies, iteration, graph traversal. So when you design a second, sort-of-but-not-completely parallel data model that works for your application code, it's not so easy to translate that into the existing data model expressed by your database schema.
        
        If your users table (and hence your User model) has a visits field and you realize that you'd been double-counting visits, you might want to amend the data you've collected so far. With SQL, you'd UPDATE users SET visits = visits / 2; -- fairly simple. However, if you're using an O/RM and don't want to write SQL, you'll likely have to load each User into memory, halve its visits, and persist it back. This takes much, much more time and makes two round-trips to the database for each record in the users table. It's much quicker to abandon the O/RM and go with the SQL query, and indeed most O/RMs offer the ability to run raw SQL because the impedance mismatch is not a problem you can beat head-on.
        
        The impedance mismatch is a problem characteristic of O/RMs specifically. There's nothing special about NoSQL databases which eliminates it, and in fact it's quite possible to work with a relational database without running into it: you just have to choose a data access framework which isn't an O/RM. Note that the opposite is also true: if you use an "O/RM" for a NoSQL database, like Mongoose for MongoDB, you can still run into the impedance mismatch. Look into data mappers if you still want to use a relational database -- I highly recommend at least investigating it unless you know that your data architecture requires specialized storage, since relational databases are much more generally useful than NoSQL stores.
        
        Ted Neward's blog post The Vietnam of Computer Science goes into more detail, and if you have a SkillsMatter account I talked about the impedance mismatch in the course of describing why my own project Massive.js isn't an O/RM at FullStack London last week.
        
        kaelscionNov 2, 2018
        
        So what I'm seeing is that there is a deep trade off with an ORM? Sacrificing scalability, performance, and efficiency for ease of use and convenience?
        
        That seems like a common trade off. The more abstracted we get from what we are doing, the more complex the plumbing becomes. I suppose that should be expected (although admittedly I didn't even think about that). Your doing everything twice. Invoking a class, which mirrors closely, but not exactly, a database table that handles data in a simpler, more straightforward way than the application layer code above it. The class then translates, to the best of its ability, SQL queries that relate to that table. But first, must connect to them, which could have been done much more quickly by straight-up SQL and much earlier in the process. Then, as with all processes that are meant to be easy-to-use, the SQLAlchemy class uses an over-generalized method of connecting, aggregating, and updating data from the db, before then reorganizing it into the form we expect when the round trip completes. Main issue being that in order to account for the large set of potential use cases, error handling, etc that all "convenience based" software code is designed to account for, a fairly straightforward SQL request becomes bloated, slow, and overly complex simply because it is, for lack of a better metaphor, a "Python-SQL Compiler" that takes Python code, translates it into the SQL that SQLite, MySQL, Postges, etc can understand, speaking "broken SQL" at best, then takes the response, translates it back to the code that the Python interpreter is expecting so that the application can use it. All when this could have been done with a standard SQL query that we don't know because ORMs are easier.
        
        Is that about what this is saying? I'm not trying to sound sarcastic, I've just never thought about what was going on under the hood with an ORM and want to make sure I understand what is being explained to me here :D.
        
        rhymesNov 2, 2018
        
        The class then translates, to the best of its ability, SQL queries that relate to that table. But first, must connect to them, which could have been done much more quickly by straight-up SQL and much earlier in the process.
        
        I feel this is not part of the impedence mismatch. ORMs are usually backed by connection pools and lazy connections are definitely a pro (most of the times you don't want your code to connect to the DB until the data is asked for)
        
        Then, as with all processes that are meant to be easy-to-use, the SQLAlchemy class uses an over-generalized method of connecting, aggregating, and updating data from the db, before then reorganizing it into the form we expect when the round trip completes
        
        Sure, there's some overhead, because data has to be translated and converted and objects have to be created and so on
        
        A common (and easily solvable) issue with ORMs is the N+1 which roughly translates to something like select all users, and for each user select their comments, this can be solved by what ORMs call eager loading which translates to something like select all users, join with the comments table and load the comments at the same time
        
        Another common issue with ORMs is the update example Dian gives. If you have to update a single column in bulk the naive and very slow way to do it is to load the objects in memory, iterate through them, change the column and save the object. A better way to do it, in SQLAlchemy, is through bulk methods which are much faster (but not as fast as using the core which basically generates a single SQL UPDATE). In Rails you probably have to use something like activerecord-import
        
        Same goes for the combination of the two issues above (N+1 update? don't know the name :D)
        
        I've just never thought about what was going on under the hood with an ORM and want to make sure I understand what is being explained to me here :D
        
        :-)
- Boris Jamot ✊ /Nov 1, 2018
  
  I only focused on programming languages and voluntarily excluded (no)SQL, although I think they could have raise (a bit) the server-side percentage.
  Maybe we could do the same analysis with data manipulation languages.
  - Helen AndersonNov 1, 2018
    
    No worries, I figured that was probably why.
    
    Interesting findings and comments, especially the proportion of JS posts. Thanks for doing all the hard work.
- Manda PutraNov 1, 2018
  
  and 200 post tagged noSQL if you consider it to be a language too
Evaldas BuinauskasNov 1, 2018

Should've listed .NET as part of C#
- Jakob ChristensenNov 1, 2018
  
  ... and F# is missing from the list.
  - Boris Jamot ✊ /Nov 5, 2018
    
    You're, right, I forgot fsharp that has 22 articles on DEV, which is not so much.
    I think you understood the big picture of this post which is: Javascript is ruling dev.to ! ;)
    - Jakob ChristensenNov 5, 2018
      
      Yes. I will have to post some F# stuff to make up for that 😁
      - Evaldas BuinauskasNov 5, 2018
        
        I surely did. 😉 This is very visible, but seeing aggregated numbers makes it more crystal clear ☺️
SagarNov 1, 2018

As per you're statistics, if dev.to written in React and Node then chances that open source contribution will grow drastically.

I known frontend built in React.

Ruby = 7.24%
JavaScript = 56.36%

What do you think ??
phoenixharozNov 1, 2018

Awesome.
William BrittonNov 1, 2018

I think this chart is awesome as someone who wants to get into blogging, this gives me some insight into topics I should probably focus on and it seems there is enough content for JavaScript here.
- JermaineNov 1, 2018
  
  it seems there is enough content for JavaScript here.
  
  I had a similar concern before getting into blogging earlier this year. Nothing should stop you from exploring other options. I did that by writing on Dart.
Nick CingerNov 1, 2018

I think it's interesting, but also there's some grouping going on.

When we talk about server-side programming paradigms, we likely won't mention the language, as it tends to apply to all of them (barring exceptions).

When talking about frontend programming paradigms, there is no other language to talk about besides Javascript.

That said, there is no doubt that JS is the most widespread, but I wouldn't read too much into it.
miku86Nov 1, 2018

Maybe everyone should just stop mixing up "correlation" and "causation" ;-)
Muhammed H. AlkanNov 1, 2018

Actually Elixir is more popular than Haskell, it's still functional.
Ali SpittelNov 1, 2018
I think JavaScript is often easier to write about too since the output is more visual. People also tend to read JavaScript stuff more too — My backend posts have next to no views compared to my front end ones.
- Boris Jamot ✊ /Nov 1, 2018
  I also think that many people come to development by the frontend door as it's more visual (as you said). And JS has a reputation for being cool, so they choose it to start.
Sandor DargoNov 1, 2018

Thanks for this article. Now it makes complete sense that although I follow #python, #java and #cpp, still my feed is full of JS, though I would even ban it from my feed given my interests.
Boris Jamot ✊ /Nov 1, 2018

You're totally right, I forget it, although I'm also a SpringBoot dev...

spring : 37

springboot : 22

It's just crazy compared to the popularity of SpringBoot in big production apps !
- Michiel HendriksNov 1, 2018
  
  I'm note sure if spring boot is popular in big production apps. I think most spring boot based production apps are small, maybe medium.
  - Boris Jamot ✊ /Nov 1, 2018
    
    I think that SpringBoot may be the new J2EE as we see many of J2EE app switching to it. But SpringBoot is also very well designed for medium app.
Jason SteinhauserNov 1, 2018

I hope to be adding some additional Elixir, F#, and Clojure articles to up those totals ;-)
- Jakob ChristensenNov 2, 2018
  
  Yes, please 😊
David WickesNov 1, 2018

Time to write that Algol post I guess...
Jaime RiosNov 1, 2018

JavaScript is the Língua Franca of the web so for me it makes sense and I'm relieved to know that this data reflects that.
Saran TanpituckpongNov 1, 2018

HTML is the best programming language.
Md Abu TaherNov 1, 2018

There will be nim soon.
Jeremy Ward 😎🤓Nov 1, 2018

No emberJS :`(
- Boris Jamot ✊ /Nov 1, 2018
  
  Ember.js : 23 posts
  - Jeremy Ward 😎🤓Nov 2, 2018
    
    Wow I may need to change that :)
kaelscionNov 1, 2018

I think that programming languages/frameworks don't follow a life cycle like other technology does. Some great languages never take off, other so-so languages refuse to die. From what I've seen this usually depends on who adopts a language and for what reason. COBOL, for instance, still runs strong because the right tech companies adopted it at the right time and are now too dependent on it to let it go 100%. If IBM never adopted it, or they move their old mainframes from it in the 70's, maybe COBOL dies soon after. Who knows?

I can say, though, that JS is huge because it's a niche language (hold your pitchforks and let me explain). Just because the niche is huge (the web's front end) doesn't make it any less so. If another language, like WebAssembly, gets the right endorsement or adoption at the right time, JS may become a marginal reference in a CS 101 book someday.

Really, we use the languages we like for as long as they prove useful to us. I remember when I found out cURL was written in Python 2.6, I thought it was pretty cool for a major tool to be so publicly written in the language I used (I know the first Google index bot was too). Now it's huge because it's so versatile and useful for data science. Ask most newcomers what Python is good for though and they will think data science is it. The landscape will look different in 5 years. The list above will have it's percentages change, and the top languages from industry lists will still probably be C, Java, JS, PHP, etc. But nobody can say that for certain. That's the fun of it I think!
- kaelscionNov 1, 2018
  
  On another note, I have always been frustrated as to why cURL has never been ported up to 2.7 (at the very least). It makes CentOS kinda useless for any meaningful Python development in cloud applications and/or web. I mean, Docker is my new addiction so using Alpine or IBM Clear images renders that moot, but for non-Docker folks, does anybody know the story behind porting cURL to 2.7? I figure if Dropbox can upgrade their entire infrastructure from Python 2 to Python 3, perhaps a linux package manager can go up one version within the same Python distro? Just curious.
kaelscionNov 1, 2018

Kourtney is Vanilla JS because she seems to be boring as all get out. And Kim is Node because she gets more famous all the time but, other than her rabid followers, none of us really understand why or what, exactly, she has contributed to the world. 😋😋😋
- kaelscionNov 1, 2018
  
  And before any of you ask, I'm married to a woman who watches the show occasionally so it's NOT creepy that I can map Kardashian sisters to JS frameworks this quickly 😐😐😐😐😐
Galdin RaphaelNov 1, 2018

We need more people on here!
deleteme deletemeNov 1, 2018

Elixir - 167 - 1.41%

These are rookie numbers, I gotta pump these numbers up! Challenge accepted.
LoopdeezNov 1, 2018

While I think everyone with eyes can admit that JavaScript/JS frameworks are highly popular- I unfortunately find myself reading less and less of Dev.to due to the lack of diversity
Chastina Li 👩🏻‍💻Nov 1, 2018

very interesting stats. I'd expect people to be eager to share their learnings in Golang considering Golang is relatively new...But not too odd since backend languages are underrepresented all together.
- rhymesNov 1, 2018
  
  Yeah, backenders need to up their game
  - Chastina Li 👩🏻‍💻Nov 2, 2018
    
    Well, the numbers here only represent quantities and not qualities, they don't mean much out of that context.
    - rhymesNov 2, 2018
      
      agreed
Valentin SilvestreNov 2, 2018

Too many JS :(
Templar++Nov 2, 2018
Not a big fan of JS myself, but you know there are two types of languages:
a) everyone complains about them
b) nobody is using them
- Henry 👨‍💻May 25, 2019
  
  Haha, that's a Bjarne Stroustrup quote right? Absolutely true though.
  - Templar++May 25, 2019
    
    Yup, that's right :)
Juan F Gonzalez Nov 3, 2018

For me is good because I was taught Back-end development all the time in my CS degree and I have grown to despise it, so everything I'm doing nowadays is Front-end development and I love JavaScript and everything related to it.
jmscavaleiroNov 5, 2018

Well, I'm pretty impressed that have has such a low number of articles!
David J EddyNov 16, 2018
PHP 725 6.11%
MarkApr 28, 2019

A language like Go only has 3.3% of the language tags, which is very low compared to the real popularity of the language.

And Java is only at 3.2% here! It's arguable whether Java is still the most commonly used language or not, but it's definitely used a lot more than Go or Ruby are!
Rafael AhronsAug 14, 2019

That numbers in # collumn is the count of total articles written in the # programming language or is something else? Because I've been watching #csharp and #dotnet and there is much more articles written.
- Boris Jamot ✊ /Aug 14, 2019
  
  Yes, it is the count of articles of the language, the 31 Oct 2018.
  Maybe .NET's popularity has grown since...

Add comment

Boris Jamot ✊ / @biros

📊 Languages' Popularity on DEV

Comments 82 total

spring : 37

springboot : 22