I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling. And since you're stuck with JS on the frontend there are some significant advantages to using it on the backend as well.
I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
Actually I'm not seeing many projects with a JavaScript backend. In my experience the number is one, and it was 2015. I mean, backends of projects I worked on or somebody offered to hire me to work on. It could be selection bias and yet they're asking me about Java, which I basically abandoned about 15 years ago, PHP, which I know since the beginning of it but only kind of toyed with, even C# which I can read as a foreign language close to one I know but never used. I wonder if anybody asked me about Rust or Go, probably not. What they ask me about and I accept to work on are Ruby, Elixir and Python, in order of my preference. Python is a distant third (as preference.)
About frontend: JavaScript all the times if there is a frontend separate from the backend. React with some rare Angular project.
I'd like to make a poll and see how many of the people here are working on a JavaScript backend vs any other language.
I read an article from Thoughtworks where they said they use NestJS in some production apps that benefitted from Node's performance characteristics. In the same article however they were critical of the trend of shoe-horning server-side JS into projects where more classical languages/frameworks would be a better fit.
Same. I never understand these things I read about JavaScript momentum on the back end. I have yet to encounter a company using Express on the back end.
That hardly sounds representative of the Node.js adoption curve. Could you elaborate on your typical client profile? Are you a solo freelancer, maybe attracting clients with legacy codebases? Location?
Freelancer, Milano, Italy. They reach to me either for taking over existing projects or to start new ones. Of course it can be selection bias but it extends to the other developers I'm in contact with.
Just searched Milan on https://it.indeed.com - Node.js 123, Django 26, Rails 11, ASP.Net 133, Laravel 67. As Node is a web technology comparing it with general purpose languages such as Java and C# is apples to oranges.
Almost always word of mouth. They start looking for somebody experienced in what they want to do (development and/or software architecture) and some eventually find me.
He said word of mouth, obviously through a business network. It's a good thing to keep in touch with people and maintain business links for both parties. I do it all the time.
This is a little bit premature of me to posit however I have a good feeling about tech like Blazor.
In particular Blazor offers two interesting approaches (“hosting models”):
1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time.
2) a wasm based approach where the whole application is delivered to the browser and you make the API calls.
Both have you writing majority of the code in C# and Razor templating syntax. Yes, you make an argument that well it’s technically still JS running it. But this becomes an implementation detail that will be ironed out, because technically the browser is written in C++, but we look beyond all that. And so on and so forth.
Now, I’m not saying I expect the world to move to .NET. Far from it. I have been preaching for a language agnostic browser execution engine so that I can write not only my logic, but my layout and styling in whatever language I want to, whether it’s Ruby or F# or Lisp, and have the browser execute it via its own internal “assembly code”. Except I’ve been parroting this idea since mid-2000s and we have at last finally started down that road.
I think this is where we are headed, and I don’t think it’s far fetched.
>1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time.
Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.
Compared to React + React DOM at 109k unzipped Blazor's runtime at 2MB is a significant hike in download size so unsuitable for older devices and constrained bandwidth networks.
1. Being too large for constrained bandwidth networks hardly makes it a non starter for anything performance sensitive unless you have a very narrow definition of performance.
2. 2MB includes bootstrap CSS and they are working on getting that number down.
3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.
> I don't think any of the current JS frameworks are as comprehensive as Rails
To someone who is switching from the Node ecosystem to Django REST, this seems like an understatement.
I'd be happy to use server-side JS for certain microservices that needed its performance characteristics, or for prototyping in something like Firebase functions. But the mere thought of building a standard fully-featured web app in Node depresses me.
the whole trend though is that the server side is mostly a very tiny crud layer & a little bit of business operations.
yeah tools like django are amazing packages. node is shockingly hardly any more tamed than it was 5 years ago, still rag tag Express for the most part. with who knows what for the data layer.
but it just doesn't matter. alas! the actual application has been heavily front end biased, & all the real investment g architecture needs to revolve around that front end. it'd be great to have better out of box omakase js experiences. projects like hapi & fastify tried. but there's just not enough effort spent on the back end for that many devs to really care. and plenty of folks are using api based systems or hosted backends, appsync or some hosted graphql, where they can care even less about the backends.
> mostly a very tiny crud layer & a little bit of business operations.
Even if you have a SPA, which isn't a given (yes, trends. I know. They come and go), the API, data migrations and background workers can easily be 50% of your code and effort.
Yea, I have switched to Django with the intent of continuing to develop primarily SPAs.
Like I said in other comments I'd only build an API in Express if I needed its particular performance characteristics.
I've checked other tools in the JS ecosystem that serve as "low-code" API layers, but upon close inspection they always seem to have some limitations on the business logic you can write, and some of them lock you in to products. No thanks.
I'm finding Django REST gives me a sweet middle ground between dev speed backed by great abstraction "magic" and freedom to customize as the app grows.
> i think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling.
huge js lover here but I don't think this is true. I think the basic obvious progression is that the client side has shouldered more & more responsibility, that architectures have shifted away from being server side, & few folk have figured out how to make the server relevant. it does a tiny bit of business logic & mostly just crud operations on data. trying to do like we did, keep rendering & a lot of the client state on the server- it wasn't helpful, was a bad way of doing things. these choices of languages became irrelevant as the client side rose in prevalence, capabilities, & yes too, somewhat, performance, but mainly I chalk it up to a long long struggle to find suitable architectures. I don't think this is fair accompli, that it's all decided, but server side needs to radically change it's game if it wants to become relevant again.
The concept of performance is interesting, to me it should be more applied to the user's experience of performance. And personally, when I come across a slow, janky SPA where a server-rendered site would have made a lot more sense, I feel immediately annoyed by the lower performance.
In my experience I’ve seen JS on the backend really only used for lambda functions, to run socketio for some chat-like feature or for pre-rendering React components.
Seconded that in another comment in this thread. Lots of "fullstack JS saves you money since you can hire the same devs for web, backend & mobile" in Berlin, with varying success
> I think it's more that the massive engineering effort that's gone into improving JS has leapfrogged it over languages like Python, Ruby & PHP in terms of performance and tooling
This is not true – PHP is still much faster when running on the server than NodeJS.
JS has got much faster in the last 20 years, but in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on).
"Instead PHP is faster for the things websites normally do, like string manipulation."
No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript.
On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/writing to stores, fetching data from other servers, etc.) - which is what many web servers do most.
Your original comment also mentioned:
"in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on)."
Which is also not true. The V8 engine is hyperoptimized and runs not only Chrome but Node too. It is precisely one of the reasons why server-side JS has gained in popularity over the last decade. The fact that it was initially devised for a browser environment does not mean that optimisation is focused there.
If you're an engineer or web developer I really suggest that you brush up on these things, because with comments like the ones you've been dropping you'd definitely raise eyebrows - and not for the good...
It is certainly true that NodeJS has become much faster as your synthetic benchmarks shows, however we have to measure our programs in the context of intended use, as previous poster suggested.
NodeJS wins against PHP when NodeJS does not make an external database call, like in the two test suites JSON serialization and Plaintext, but as soon as you throw in MySQL database PHP wins.
What does this tells us? That V8, the implementation of the JavaScript, is faster than the Zend engine, the implementation of PHP, but the event based NodeJS platform is not faster than the PHP(Apache/Nginx) platform.
NodeJS performance has evolved massively thanks to V8 R&D, as you already mentioned, Zend Engine has also gained a lot performance but of course not comparable to V8 for obvious reasons, the prior is a Google based project, the latter is a volunteer community based project. However the PHP stack also consist of a web server, and they has also evolved massively the past 20 years, Nginx is relatively new on the scene with an event based asynchronous architecture and Apache has evolved with a new PHP module.
I think your personal attacks against muglug, regardless if he was right or wrong, is not appropriate for this forum, especially when you yourself is not entirely up to date.
> If you're an engineer or web developer I really suggest that you brush up on these things
I’m doing ok, thanks, and a little humility would go a long way :)
I work at a company where we run PHP as both a shared-memory server and also in a more traditional per-request model, both serving millions of requests a day. Separately I’ve created (and maintain) a 200-thousand-line multi-threaded PHP application with over 4 million downloads. I’m reasonably aware of PHP’s performance characteristics.
I’m less up-to-date on Node, admittedly, but it also intuitively makes sense that the V8 engine will be optimised more for in-browser use than serverside use.
PHP is fast but not as fast as Node. However, once you introduce something like Laravel into the mix performance tanks leaving it slower than Django and Rails according to Techempower benchmarks.
I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.