How popular are Node.js and Python for web development?

According to this report not long ago, Node.js is used on 0.6% of websites, Python is used by 1.1% of websites:

PHP vs. Python usage statistics, December 2018

With PHP at 78% as the dominate backend language.

Node.js can probably creep up towards 1%, but I’m not really expecting it to.

I think Node.js has probably peaked, maybe if TypeScript gets a lift, it’ll take Node.js with it, but to beat Python, Node.js needs to almost double its market share, and I just don’t see that happening.

0.6% doesn’t sound like a lot, but remember it is 0.6% of all websites.

All things considered, I’d say they are already similarly popular.

What will be the dominant front-end technology in 5 years time?

In short, you might as well play roulette and bet on black, because nobody can answer this question with fact. We can only present hypotheses.

The world of web development, especially front-end development, evolves about as quickly as the physical tech industry does, and there is no way we can predict what Samsung, Apple, Nokia, and the other’s will churn out in even the next two years. Much less five.

Let’s look at a bit of JavaScript history.

Build Tools (2014 – 2018)

  • Three years ago, Grunt was the dominant build tool.
  • Two years ago, Gulp rose up and stole the throne.
  • One year ago, was Webpack’s claim to fame.
  • Somewhere in there, Browserify fought a good fight.
  • At one point, plain npm scripts became a fad.
  • When I wasn’t looking, Rollup rolled out.
  • Along the way, I built Owlister. (It is junk. Don’t look.)
  • Now, Webpack dominates, but tomorrow is unpredictable.

Transpilers (2009 – 2018)

  • Eight years ago, Coffeescript became Earth’s favorite abstraction.
  • Six years ago, Dart arrived like a drunken monkey on weed.
  • Five years ago, TypeScript was born, bringing type safety to JavaScript.
  • Three years ago, Babel arrived to let us use future JavaScript today.
  • Two years ago, Elm became a buzzword. (Nearly irrelevant, but not quite.)
  • Now, TypeScript and Babel rule. Seemingly invincible? Time will tell…

Frameworks (2010 – 2018)

  • Seven years agojQuery was the most suggested JS “framework”.
  • Six years ago, Backbone and Knockout were widely adopted.
  • Five years ago, Angular and Ember took the stage.
  • Four year ago Meteor stormed the gates and built a following.
  • Three years ago, React took its first breath. The prophecy…
  • Two years ago, Polymer and Vue made names for themselves.
  • One year ago, [Angular 2 and Vue 2] released, [bombing and succeeding].
  • Six months agopeople quit caring that “React is not a framework.” Don’t.
  • Now, Angular 4 has arrived, React dominates, and Vue is a super-power.

*These numbers are not exact, but even the absolute correct time-frames would reveal an identical pattern of “king of the hill”. Don’t grill me.

But wait, there’s more!

In the midst of the frameworks timeline, there have also been countless other contenders take a shot at stardom. Aurelia, Riot, Spine, Dojo, Deku, Inferno, Mithrill, Stapes, Svelte, etc. Any one of these lovely ladies could become the new hotness in a matter of weeks. We just can’t tell.

If I were to revisit this answer in five years, I’d most definitely be adding weird framework titles to my timelines above, as even the power-houses of today will not last forever. These tools will probably be such that I have never even heard of at this point in time.

Behold, WebAssembly.

WASM is… difficult to explain. Simply put, WASM allows developers to compile most any language into performant, browser agnostic byte code. What this means is that the front-end community has the opportunity to detonate yet again with a landslide of developers from all walks of life developing for the browser.

JavaScript has done its job well, but as the world progresses it will be replaced. That time could very well be within the next five years. The murderer could be WASM or it could be a new browser that takes a majority of the market share that allows developers to write their applications in Haskel. Improbable, yes. Impossible, no.

The Safe Bet.

As it stands, our best guess is that JavaScript will still dominate the browser in five years. That said, your best bet would be to acquire a slew of developers who are tool/framework agnostic by means of deep JavaScript understanding. Don’t allow yourself to be contracted to a specific tool. I guarantee you that Angular, React, Vue, Backbone, Aurelia… none of these guys will reign in five years.

Those who become proficient with languages and have a firm understanding of design patterns and architecture will have no problem adapting to future tools and are, in essence, future-proof.

Should you learn Docker?

Maybe yes. Maybe no.

If you ever write server/back-end software, it should be a requirement today that you know Docker.

If you create applications, it’s good to know Docker so you can create a standardized build environment. You never really want your application release builds to come off a developer system, and it’s even better if the standard build system can be defined in software.

If you want to run a specific version of a database on your development system, then Docker can do that pretty trivially as well.

If you have problems with version conflicts between various installed environments (Python 2 vs 3, various gcc[lib] versions, other tools installed globally, etc.) then Docker can be useful to set up the perfect environment to run a picky tool, and once it’s working you can share that environment with a coworker and know that it will just work.

Docker is a tool. You should learn it if it will help you do your job. The above examples are not exhaustive. Any time that it would be good to have a standardized environment on your development system, for testing or sharing or running specific software, Docker would be useful.

But if you never need it for the above reasons or otherwise, then no, you don’t need to learn it. It wouldn’t hurt to learn it just in case. But there’s no “should”. It’s really, really not hard to learn, though. At least if you understand the command line.

Why do backend developers have more confidence in their profession than frontend developers?

Because 99% of the time when someone identifies as a front-end developer they are saying that they have not been a developer for very long.

Think of it this way. On the web, Ajax was “invented” in 2004 (actually Outlook was doing it in 1999 but shh…we can’t give Microsoft any credit). It did not become a central part of most web developers’ lives till 2008/2009 or so. Even then, Javascript was avoided by many until frameworks started coming out in the early 2010s.

So what were people who were already established developers pre-2010 doing? Working largely on the back-end. So now that they do a lot of front-end work too, they face the choice, do they brand themselves as a “front-end” or a “full-stack” developer? I certainly choose the latter.

Which leaves most people who embrace the “front-end” moniker as people who have been coding professionally for less than six years. So yeah…they’re less sure of themselves.

For the record, I use the “front-end” and “back-end” terms above in the manner I see them used more often, with “back-end” meaning server-based languages, databases, etc; and “front-end” meaning HTML, CSS, and Javascript. Personally, I dislike those definitions and prefer “back-end developer” to indicate how good someone is at understanding architecture, performance, databases, and security; and “front-end developer” to indicate to what degree someone thinks about human-computer interaction, responsiveness, UI optimization and reusability, browsers, responsiveness, and accessibility. When you formulate definitions this way you start seeing these as two largely orthogonal dimensions of a square, rather than anything mutually exclusive.

Disclaimer: I use 99% rhetorically. It certainly is an overwhelming majority but I haven’t done any data gathering on the subject. That being said, I certainly don’t claim that front-end development is easy. There’s a huge amount of churn. There aren’t many other areas of development where people have to actually stay on top of language specs. 

Why React Dev’s Like to Hate Vue.js

After having worked on React development on medium/large scale apps, I have to admit that VueJS is like a breath of fresh air.

In my opinion, most developers are having as I call it the “Simplicity (Un)reasoning” bias, which means: if it is simple to learn, simple to use then it is for simple projects. Crazy right?

Meanwhile, the arguments in favor of React or Angular 2+ are dubious as well.

Angular is for large teams because it enforces you to write code in a typed way because of TypeScript. Yes but React and Vue support TypeScript or Flow not to mention that Vue’s lifecycle events are more clear cut than React’s.

Vue has only one person writing code. Not anymore.

Vue is for simple projects. Maybe you should read how Adobe is using it these days.

I am not writing this specifically for Vue but believe me that this simplicity can be found in other libraries as well e.g. RiotJS, StimulusJS etc.

Unfortunately, React and Angular have excellent marketing strategies, which plays a major role since they are trying to sell longevity instead of code happiness. By code happiness I mean the factor which make your developers happy to write code they understand and are proud they wrote it. With React and Angular I am not that happy, especially with React.

With Vue the selection was being made from a pool of 10+ team leaders because it just works as it should out of the box. Their vue-cli is also in the same league angular-cli is, but the difference is were angular could not operate very efficiently without, Vue could work without it with no problem.

Finally, I have to point out that lately among the majority Front-End developers, there is this strange notion that if your code is easy to understand, not very complicated and not using the latest ESxxx you are doing something wrong. If you look at Angular you have to learn RxJS, TypeScript etc. and even if you are not satisfied with this selection few will admit it. We have to get rid of the herd mentality and marketing strategy of 2–3 large companies and exercise common sense and independent spirit.