Ask HN: Are there and will there be a lot of JavaScript backend developer jobs?
How is it going to compare to Ruby and PHP?
PHP is pretty old and popular. Around 82% of websites are using PHP. How long is it going to stick around for?
PHP is pretty old and popular. Around 82% of websites are using PHP. How long is it going to stick around for?
I don't see a bright future for ruby, I think it had some lead advantage, but RoR/opinionated-design really cut down the options for innovation with a Ruby based web dev group. It is interesting to see how diametrically opposed philosophy of Ruby the language is from the RoR community, it is like Ruby created a liberal blank space and RoR immediately filled it with conservative inflexibility.
Php is in an interesting position, but I think ecommerce systems catching up and offering more integrations will erode its position. It is very expensive to hire and retain loyalty on a php project, especially when it is of any complexity since anyone who will tolerate it and understands CS has plenty of other options.
If I had to say what will trouble JS, it is C++ as the VM. Too many groups will lack members that are able to look bellow the scripting layer when the inevitable low level problems occur.
Personally, I see the future as a war (and up/down stack integration) between JS/v8 and LLVM based languages. While other options will keep their markets for years, they have no solid positions for growth. Python will hold on as long as it has the academic position, but it needs a better relation with LLVM or clever curriculum builders will choose another language to teach using only one easy enough language up through compilers, with llvm-ir replacing assembly in a way that makes sense given the Arm/Intel war could go either way now.
I agree with you that Rails requires following conventions but then again which framework doesn't?
Rails is a mature framework and has been widely used in production. The reason why rails succeeds is because it allows you to deliver applications very quickly to market to meet the business needs.
Ruby's philosophy is move quickly and break things, I have no doubt ruby will stay relevant thanks to the community embracing change rapidly.
It's why I never trust anyone who claims to be a "full-stack" developer. They will be bad at least one of them.
Or you don't have to use the latest fart.js and still implement frontend that will last more than 1 year. Or maybe I'm just a backend developer claiming to be full stack...
You joke, but that's an actual thing: http://jsfart.com
Now, as a professional, I wouldn't tie myself down to a single stack but be able to work with others because there's lot of stuff written on JEE, .Net and PHP that someone has to maintain and are so different from Node.
Also, I don't see other stacks growing as much as Node, like Go or Pyton. And even PHP is that big not because PHP itself but because of Magento, Joomla and all the other PHP based products already out there.
On a final note, affirming that a frontend developer can't do backend is simply stupid. And once Node and ES6 confluence it will be even easier.
JS as a backend is more of a joke, though. It has heartful followers, true. But it doesn't bring anything valuable to the table. I may be wrong (and happy to be corrected) but this was developed by people who learned the JS frontend stuff first and then didn't want to learn another language for the backend just as well. So they decided to make the language they already know available in the backend as well. But that's it.
Think about competitions in the backend/desktop area. For instance Go. It aims to combine the advantages you have in the most popular programming languages, while also providing stuff as core elements (e.g. packaging) that are only attached on top of other languages. Or coming from the other direction of the "cool" languages, it provides all the nice little modern features you know from other languages but also enables you to write and compile code as fast as the C codes of the ancients you always read about.
This is what real competition looks like. It provides something huge and new while also providing quality features you know from your current favorite language. If you don't bring something like that to the table people won't switch to you, at least not for serious projects. The advantage of already having educated developers on the market for the "old stuff" and having an infrastructure of libraries that solve most of the tasks at hand, is just too big to compete against without killer features.
And as I said, I may just not know the killer feature of server side JS, in which case it may be just a marketing blunder of the server JS people that can be corrected.
I wouldn't do a monolith in Node though... But actually, I'd never do a monolith again :-)
So I definitely don't see it as a joke. Before that I did C#, Clojure, Java, Python, C++ and Ruby jobs and honestly, I think Node is up until now my best experience. In terms of speed, joy and community. The latter is GREAT(!). I love js confs, so much different people, zero hostility, open minded. Great!
Also JS allows you to write very nice code. Look at libraries like Ramda, or the fantasy-land movement. You can write wonderful code in it if you know how to do it. ES6 really helps here. I wouldn't like to write code anymore in ES5 or earlier to be honest...
Lately, I started converting everything over to Typescript and the situation has improved a lot. I think if Typescript becomes the main way that people program JS stuff then Node might have a chance of gaining some mind share.
The whole product started as a NodeJS+MongoDB app, which was a disaster at scaling to the billions of requests a day we handle and we've replaced it everywhere except the dashboard, but there is absolutely no incentive for replacing it there and when something truly tricky comes up there is support in the rest of the org for them; of course nothing stops them from writing a hair ball besides themselves, but that's always the case.
You don't necessarily need to find someone who is only good at frontend code and throw them into a backend project, but if you find someone comfortable with Node, they're probably in that position because they also know how to do frontend, and once you have at least one senior Node developer, you can teach your frontend-only developers.
Maybe I just don't have a good sense for the web developer market and there are a lot of backend+frontend people who are not Node developers, but my intuition tells me that's not the case.
But!!! If you have the same language in both, its easier to check the code of the over side and derive some insights, or to eventually fix some small bug somewhere or implement a minor feature.
I experience that currently.
You're saying having a small team makes it a bad idea to use a standard-ish library for organizing things and avoiding grunt work?
I would argue the exact opposite.
The result is a webpage that can do lightening-fast transitions client-side without breaking the back button.
The code also usually required some (often significant) refactoring of the code in question to make it portable between the front-end and back-end environments. In classic ASP, this usually meant ensuring front-end code moving to the back-end was isolated from any DOM interaction and didn't use any ES5(+) features, while back-end code moving to the front-end had to be isolated from the ASP objects (Application, Server, Session, etc.). It's all stuff that seems like common sense, but wasn't rigorously applied to JScript code which only had to work on IE5 (later 6, finally 7 before the project was put out to pasture), especially since use of JavaScript on the client wasn't significant until the project's last couple of years.
Other languages have that as well, although probably not the same good practices.
> commonjs lexical scoped module system
Fast googling of commonjs results in it being some kind of standard library? Not really sure what this is. Can you explain more in depth?
In JavaScript there are values: 42, "hello", true. And objects: [list], {object}, function. And if statements ... While more stuff exists there is a consensus in the JavaScript community that they should be avoided, so you rarely see the bad parts. Then there are only a handfull of built in JavaScript functions. And there is no concept of stack, pointers or types. How the data is represented in binary vary and is very optimized.
A node script is usually a bunch of functions that are called by IO events, like a IP socket connection or callbacks from data streams, like when a buffer is filled.
Node has no standard library, just a bunch of built in modules, that are required like any other module. And Node does NOT support imports, includes, or global variables, instead you require Modules. And since modules are lexically/function/block scoped, they can only be called from within the function from where you required them. You never have to look elsewhere to see where a variable is declared, or search for places where it's used, like in many other programming languages.
Here's an example how a NodeJS script can look like:
var socket = require("socket");
socket.onConnection = function socketConnection(client) {
client.onData = function dataReceived(message) {
var sms = require("sms");
sms.send(message);
client.send("SMS message sent");
}
}
At the same time I think PHP has a good future, where 7.0 made a really great progress in performance. Laravel is awsome for web development.
Writing express servers feels a lot like writing a Ruby server at the Rack level. To people that are used to Rails/Django, it feels a lot more manual and painstaking. While I personally like the clarity of request flow and modularity that I get using express, there are definitely some friction points (picking the best model layer, quickly picking up a new codebase, generating admin UI, to name a few).
JS is not in a place yet where it could take on Java. But it is on the way to become an alternative that could eat away at Java use cases. JS6, TypeScript and the consolidation around NPM packages are significant improvements. Node control is too concentrated for a long term healthy ecosystem and lacks alternatives but if such would emerge then all bets are off. The primary back-end stack which is at the moment compiled Java byte-code could in the long run split into compiled whatever code and scripted Typescript code.
Caveat: Java investments stay subdued. JS investments don't level off.
At my company we have a mix of python, PHP and JS devs. Node is great for a lot of things, but it's better suited to smaller apps that do one thing. Cue microservice debate.
We have a lot of worker services written in Node, with a majority of our API services using PHP (Laravel/Lumen.) That's starting to change as some of our developers see the benefits of not having to context switch between languages when working on front and back end simultaneously.
It's worth considering.
Cobol has been dead for a long time. It's not popular even on HN.