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.
jQueryinJavascript.
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?
Oldest comments (77)
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. ;-)
Maybe everyone should just stop mixing up "language quality" and "language popularity"; furthermore, DEV is quite web-centric. Although I'm actively working on changing that, most articles here revolve around how to reinvent the wheel in $some_js_framework.
Have I mentioned that COBOL is an excellent web language too? ;-)
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.
An instagram influencer basically
Pf
Or a member of the Kardashian family
This definitely calls for a listicle post mapping JS libs/frameworks to members of the Kardashian family.
Kris is jQuery
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. 😋😋😋
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 😐😐😐😐😐
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.
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!
Well, it's actually the first (and only) Back-End and web Front-End language
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.
Maybe everyone should just stop mixing up "correlation" and "causation" ;-)
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
And I'm perfectly happy with proving b) wrong. ;-)
Haha, that's a Bjarne Stroustrup quote right? Absolutely true though.
Yup, that's right :)
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.
There's 100 posts tagged with SQL. If you consider that a language in this case :)
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.
Well in that case ...
I highly recommend Randy (@randysims ), Mark (@booyaa ), and me :D
Excellent. Thank you for the follow suggestions. There are just so many people! 😵
Do tutorials on how to use ORMs count as db content?
Yeah definitely!
What's your poison: Django ORM or SQLAlchemy?
I primarily use SQLAlchemy
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!
That's the power of the data mapper pattern ✌🏾✌🏾
SQLAlchemy is my favorite 🌞
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
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:
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
userstable, you'll have to write aUserclass 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
userstable (and hence yourUsermodel) has avisitsfield 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'dUPDATE 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 eachUserinto memory, halve itsvisits, and persist it back. This takes much, much more time and makes two round-trips to the database for each record in theuserstable. 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.
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.
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)
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 loadingwhich translates to something like select all users, join with the comments table and load the comments at the same timeAnother 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 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.
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.
and 200 post tagged noSQL if you consider it to be a language too
Should've listed .NET as part of C#
... and F# is missing from the list.
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 ! ;)
Yes. I will have to post some F# stuff to make up for that 😁
I surely did. 😉 This is very visible, but seeing aggregated numbers makes it more crystal clear ☺️
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 ??
Awesome.
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.
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.
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.
Actually Elixir is more popular than Haskell, it's still functional.
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.
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.
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.
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 !
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.
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.
I hope to be adding some additional Elixir, F#, and Clojure articles to up those totals ;-)
Yes, please 😊
Time to write that Algol post I guess...
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.