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?
Top comments (74)
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
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.
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.
Well, it's actually the first (and only) Back-End and web Front-End language
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!
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
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.
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.
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.
Yeah, backenders need to up their game
Well, the numbers here only represent quantities and not qualities, they don't mean much out of that context.
agreed
These are rookie numbers, I gotta pump these numbers up! Challenge accepted.
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 😐😐😐😐😐
Maybe everyone should just stop mixing up "correlation" and "causation" ;-)
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!
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.
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.