4 ms·

PHP, Java, and C will probably stay around as long as their isn't a huge shift in software development, e.g. by having AI doing the development for you. JS as

by erikb 10y ago

PHP, Java, and C will probably stay around as long as their isn't a huge shift in software development, e.g. by having AI doing the development for you. 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.

danielheath 10y ago
The killer feature (and only reason I use it) is being able to render the same templates with the same data on the server (isomorphic/universal/whatever). The result is a webpage that can do lightening-fast transitions client-side without breaking the back button.
- taspeotis 10y ago
  For what it's worth, ReactJS.NET does server side rendering, so you can have a .NET backend. https://reactjs.net/guides/server-side-rendering.html https://reactjs.net/guides/server-side-rendering.html
  - vizeroth 10y ago
    In most cases, it's probably still easier to use C#, but JScript has always been an option in ASP.Net (and classic ASP). I found that the ability to use the same code on the back-end and front-end was nice when you needed it, but those occasions were quite rare. 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.
    - caseymarquis 10y ago
      IronES2015 or IronTypeScript. Interesting thought.
- Daishiman 10y ago
  That part of the web workflow just doesn't seem big enough to warrant all the other parts that are missing in the NodeJS ecosystem. In practice if those things are important enough there's a variety of template languages that are ubiquitous.
- botw 10y ago
  so you have to keep the same code on client side for every page that requires re-rendering. kind of bloated?
- erikb 10y ago
  Hm? Other languages also have template systems. PHP actually started as template system. Even today it should be possible to do inline templating stuff just with PHP (although other template languages are easier to use for that purpose). Not a huge fan of PHP either, but templating is not a killer feature. Everybody has that.
narrator 10y ago
I have been doing some NodeJS development and it has been pretty miserable compared to something with a real type system. 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.
Eridrus 10y ago
NodeJS has an advantage on very lean teams where you need a front-end that's not hideous and a backend of some sort, NodeJS makes it easier to find a single person who can do all the programming on that project. It's not a technical win, but it is a business win.
- nik736 10y ago
  Biggest myth I have ever heared. Only because someone can write frontend JS, doesn't mean he can understand backend logic and actually write proper backend code. Also, if you are a 1-2 person team and using a frontend JS MVC framework in 95% of all cases you are doing it wrong.
  - mpfundstein 10y ago
    I agree. Backend and Software are two different worlds. At least if you want to get both right :-) 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.
  - Eridrus 10y ago
    Not all projects require "proper backend code" whatever that means. It's not my team, but our enterprise/analytics dashboard is written in Node; we've been fine with 2 developers on that team for 3 years. It doesn't receive a tonne of traffic since it's largely just interactive reports for our users and the actually complicated parts are handled by a separate team that makes sure the relevant data lives in a Druid database that the dashboard team can query. 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.
z3t4 10y ago
nodes killer feature is the (accidently) combination of good practises. And the commonjs lexical scoped module system
- erikb 10y ago
  > combination of good practises 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?
  - z3t4 10y ago
    Node uses JavaScript witch is a simple scripting language that is event based, asynchronous, and thread safe. 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"); } } Besides lexical scoped modules in the example above there is also a "closure" of client in dataReceived from when socketConnection was called.
mpfundstein 10y ago
I am working currently as a Senior dev on a team of 8 developers. We use NodeJS6 for the backend and its a great language wot work with. I've never been so productive. There are some drawbacks (weird type system, you need disciplined programmers, etc...) but the overall experience is great. We have a microservice architecture, where every service is on average maybe max 700 lines or so and honestly, Node works great there. You don't have to worry about threads etc.. The event system simplifies all this tremendously. You have millions of library for every flavour. So Microservices in Node are a joy. 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...

by erikb 10y ago

danielheath 10y ago

The killer feature (and only reason I use it) is being able to render the same templates with the same data on the server (isomorphic/universal/whatever). The result is a webpage that can do lightening-fast transitions client-side without breaking the back button.

taspeotis 10y ago
For what it's worth, ReactJS.NET does server side rendering, so you can have a .NET backend. https://reactjs.net/guides/server-side-rendering.html https://reactjs.net/guides/server-side-rendering.html
- vizeroth 10y ago
  In most cases, it's probably still easier to use C#, but JScript has always been an option in ASP.Net (and classic ASP). I found that the ability to use the same code on the back-end and front-end was nice when you needed it, but those occasions were quite rare. 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.
  - caseymarquis 10y ago
    IronES2015 or IronTypeScript. Interesting thought.
Daishiman 10y ago
That part of the web workflow just doesn't seem big enough to warrant all the other parts that are missing in the NodeJS ecosystem. In practice if those things are important enough there's a variety of template languages that are ubiquitous.
botw 10y ago
so you have to keep the same code on client side for every page that requires re-rendering. kind of bloated?
erikb 10y ago
Hm? Other languages also have template systems. PHP actually started as template system. Even today it should be possible to do inline templating stuff just with PHP (although other template languages are easier to use for that purpose). Not a huge fan of PHP either, but templating is not a killer feature. Everybody has that.

narrator 10y ago

I have been doing some NodeJS development and it has been pretty miserable compared to something with a real type system. 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.

Eridrus 10y ago

NodeJS has an advantage on very lean teams where you need a front-end that's not hideous and a backend of some sort, NodeJS makes it easier to find a single person who can do all the programming on that project. It's not a technical win, but it is a business win.

nik736 10y ago
Biggest myth I have ever heared. Only because someone can write frontend JS, doesn't mean he can understand backend logic and actually write proper backend code. Also, if you are a 1-2 person team and using a frontend JS MVC framework in 95% of all cases you are doing it wrong.
- mpfundstein 10y ago
  I agree. Backend and Software are two different worlds. At least if you want to get both right :-) 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.
- Eridrus 10y ago
  Not all projects require "proper backend code" whatever that means. It's not my team, but our enterprise/analytics dashboard is written in Node; we've been fine with 2 developers on that team for 3 years. It doesn't receive a tonne of traffic since it's largely just interactive reports for our users and the actually complicated parts are handled by a separate team that makes sure the relevant data lives in a Druid database that the dashboard team can query. 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.

z3t4 10y ago

nodes killer feature is the (accidently) combination of good practises. And the commonjs lexical scoped module system

erikb 10y ago
> combination of good practises 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?
- z3t4 10y ago
  Node uses JavaScript witch is a simple scripting language that is event based, asynchronous, and thread safe. 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"); } } Besides lexical scoped modules in the example above there is also a "closure" of client in dataReceived from when socketConnection was called.

mpfundstein 10y ago

I am working currently as a Senior dev on a team of 8 developers. We use NodeJS6 for the backend and its a great language wot work with. I've never been so productive. There are some drawbacks (weird type system, you need disciplined programmers, etc...) but the overall experience is great. We have a microservice architecture, where every service is on average maybe max 700 lines or so and honestly, Node works great there. You don't have to worry about threads etc.. The event system simplifies all this tremendously. You have millions of library for every flavour. So Microservices in Node are a joy. 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...