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 ther...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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
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
Haha, that's a Bjarne Stroustrup quote right? Absolutely true though.
Yup, that's right :)
And I'm perfectly happy with proving b) wrong. ;-)
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 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.
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.
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.
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.
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.
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.
Yes, it is the count of articles of the language, the 31 Oct 2018.
Maybe .NET's popularity has grown since...
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.
No emberJS :`(
Ember.js : 23 posts
Wow I may need to change that :)
There will be
nimsoon.I hope to be adding some additional Elixir, F#, and Clojure articles to up those totals ;-)
Yes, please π
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!
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 ??
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.
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 βΊοΈ
We need more people on here!
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.
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.
Time to write that Algol post I guess...
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
Too many JS :(
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.
HTML is the best programming language.
<!-- Just a joke π -->
Awesome.
Actually Elixir is more popular than Haskell, it's still functional.
Well, I'm pretty impressed that have has such a low number of articles!