31–40 of 181 posts
Earlier quoted context omitted.
Why? Use NestJS, AdonisJS, or use an existing boilerplate. You may not have everything but a simple endpoint can be up and running pretty soon. Use Heroku and / or Lambdas and your prototype is deployed and running.
You can do this with any web framework.
The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple s…
Why would a DBMS API need to be built into the runtime?
The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple s…
Node.js wasn't created in a vacuum. Its http lib, and express.js which extends it (and Sencha connect before that) implements part of the CommonJs API created by earlier SSJS frameworks such as Narwhal, Helma, etc. and was inspired by Ruby's Sinatra.
In fact, a common portable API and standardized language that isn't going away anytime soon (JavaScript) is what draw me to Node.js, and I still find it's an excellent framework for lightweight web servers and b4f approaches. TypeScript and Deno, not so much.
Edit: also, while Node.js had its share of quirks in early versions (especially around the Streams 1/2/3 API), its core API is super-stable (and it better be with some 100s of thousands of packages making use of it out there).
Earlier quoted context omitted.
You can do this with any web framework.
You are right, pretty much any modern web framework. So my original point still stands :)
TL;DR: async programming does not work well from the commandline.
from the article "JavaScript is evolution". Exactly. At any moment there may be some alternative that is better in some ways, but unless it also evolves it is not a long run contender. I don't love JavaScript, it can be a huge and gigantic pain (this, ==, null, undefined etc). But it continues to get better and is still for me the most productive language I have used.
Earlier quoted context omitted.
Why would a DBMS API need to be built into the runtime?
Because otherwise you end up with thousands of incomplete and incompatible implementations all fighting to be the best or running out of steam after a month or two. Node is a hellscape from a db perspective
I agree with some points author is making, but overall I wouldn't put them either on Node.js runtime, or Node.js ecosystem. a) Erratic max latency IME Node.js performs well if you are not pushing its limits. If you have a service receiving 25k+ requests per second, you should better benchmark it, regardless of the language. Horizontal scaling should be configured based on the results of the benchmark. b) Cognitive ov…
NodeJS does not handle multicore servers well, and I imagine many people don't realise this and have a huge amount of unused CPU capacity.
You need to run multiple nodejs processes (one for each core really) to get the most of it. But this then requires load balancing even on a single machine, so a lot of people don't do it. There are other solutions but often require json strings passed between the workers, instead of objects, which can end up stalling the whole thing (more time spend with json (de)seralization than actually doing work on complex models).
.NET (core) handles this extremely well. It's trivial to do a parallel async foreach, and it's easy to scope services (eg database access) to avoid threading problems. It also automatically uses as many cores as you have without any extra problems for handling multiple requests at once.
This is even more of a problem on mobile apps in React Native, which I've used a lot of. It is virtually impossible to use multiple CPU cores efficently on a RN application, which is pretty crazy considering how many cores mobile phones have. For 99% of projects it's not a huge issue, but on some it becomes a real killer, especially as the workarounds involve sending json strings between processes, which can end up being the blocker itself with complex state you want to pass between threads.
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
What about Python?
Flask will happily return responses in hundreds of microseconds or low single digit milliseconds if you're just rendering HTML templates. Throw in some DB queries and it's really easy to keep responses under 50ms.
Scaling horizontally isn't too bad because it's just stateless web servers and scaling vertically is easy because popular WSGI servers like gunicorn and uwsgi support the notion of internally load balancing X number of processes and from your POV all you need to do is tell it how many to use (1 config setting) and it does the rest.
Asynchronous workloads are no problem because you can spin up Celery. While it's not the actor model of Elixir, it gives you a nice level of abstraction because you send a task to the worker and it feels like synchronous code from your end. The mental model is great.
A gunicorn web server (a WGSI server in Python) will use less than 100mb of RAM too even for a moderately sized app (few dozen packages, thousands of lines of code, etc.) but this number will get higher based on how many processes you decide to run. However it's very predictable.
But I'm not sold on using 100mb as a benchmark because for $15 / month on DigitalOcean you can get a 2 core / 2 GB machine. 2 GB is plenty of memory to run a decently popular Flask app with a few processes + nginx + celery + postgres + redis. You'd have no problem serving hundreds of thousands of daily page views on a machine like that as long as you're not doing anything too out of the norm. Basically a typical site that's mostly DB reads but has a good amount of DB writes and you have good database indexes.
And for $20 / month instead you can double your RAM to 4 GB and now suddenly you can do the same with a Rails app including using an ActionCable service to handle thousands of concurrent websocket connections.
With the way hardware is nowadays life is amazing for web development because in so many cases you can be using any popular web framework and comfortably serve a huge range of web apps for $10-20 bucks a month all-in.