Hacker News Reader

Comment by rockyj | Hacker News Reader

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 requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease).

On top, any organization can hire JS devs with relative ease. And the same devs can also use the same skills to build a frontend.

I am not a JS/TS/Node fan but unfortunately it seems we do not have a better story to sell right now and we are stuck here for a while.

View on HN

> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease).

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.

Or if you wanted async request handling, you could use Starlette.

Its probably a rhetorical question, but I would suggest Go as another alternative.

Naturally, you wouldn't want to write the frontend in Go and it also has the "not perfect" quality.

I'll plug Vert.x here but just about anything these days depending on your workload.

> can spin up a http service in a day

Surely this is a typo?

I know Vertex has a reputation for being lightweight but 100MB for a JVM webapp seems unrealistic to me.

For instance, a barely used Jenkins needs 200MB.

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.

You are right, pretty much any modern web framework. So my original point still stands :)

I'm not exactly sure what you are arguing. You asked us to give you examples of frameworks based on your criteria ... which just about anything will meet these days.

Your original point was that node.js has an edge because it has something nobody else has - low memory footprint, low latency, quick time-to-market, scalable. If the response is that "any modern web framework"can do it, then your point does not stand at all.

Sorry, communication gap. I was only referring to the part -

"> can spin up a http service in a day

Surely this is a typo?"

I thought we were contesting that point only.

I agree that a lot of frameworks can do that. On top Node/JS also allow developers to do web/native(ish with RN) and desktop apps with great tooling, libs etc. this combo is hard to beat.

It seems to me that a lot of frameworks can also do the other things! Even Java (though not for a lot of entrenched codebases) has frameworks sporting millisecond startup times and latencies nowadays, with very low time-to-develop.

I would also bicker that node.js is not that easy to scale horizontally, at least not notably easier to do so than any other single-threaded runtime.

IMO the only edges that node.js has are:

* some people know javascript

* for a dynamic language, the runtime is quite performant - you get more for your core, and that's cool

* I agree with the ideal that you can run the same language on the front and backend, but I have found in practice that two things are true. First, that they are actually different languages, with different runtimes and libraries. Second, the holy grail of e.g. serverside rendering your react app and having the browser take over represents a miniscule minority of JS deployments.

Nothing here means node.js is a bad platform, obviously, but it also is a platform I would only choose because I knew JS and was working with others who knew JS, or I was REALLY committed to the dream of isomorphic Javascript. It doesn't have any characteristics that would cause me to suggest non-JS developers go learn node.js.

I think the confusion is around the phrase "spin up," which usually refers to the starting of a process or machine. I think what you meant is that developers can write an HTTP service in a day--referring to the speed of development for Node.js.

Vert.x is flat out amazing. For node developers, I recommend them taking a look at using it with Kotlin. A Typescript developer can feel awfully "at home" writing a Vert.x/Kotlin web service.

.NET Core can certainly run in well under 100MB, handle requests under 50ms and get running quickly under load. You also have async/await and type safety, scales horizontally. It's not JS/TS, so the skills are different and that's not idea but if you're in TS and squint, you're looking at C#.

Also far from perfect but I do think it's now a viable option as a replacement for node.

Thanks for sharing this. I plan / hope to look into C#/.Net Core if life permits.

PHP by a mile.

It's performant. It has bad rep for its history. But every release makes it better. And it has a nice model of architecture where the whole app is setup and tear down with every request in most scenarios. Your whole app is a response object.

There are nice, mature frameworks like Symfony or Laravel that make it really pleasant to use.

Pair with FastCGI and nginx and you can have a real killer.

Uhm, CGI? Those are not at all impressive metrics.

ASP.NET Core does all that just fine. Uses ~83 MB of memory when idle but easily handles the rest

> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so

This is a strange set of requirements for a platform.

"And the same devs can also use the same skills to build a frontend".

This is such an overstatement. Knowing the syntax is just 10% of the story.

There is literally 0 common things in for example React + Styling + SEO + browser + knowing good standards for the web vs. backend expressjs api talking to some DB and knowing good practices for having scalable backend based on for example 12 factor practices.

Pretty sure all major stacks including php/python/ruby can get good performance. Having one good devops person is way more important than what language you pick nowdays.

PHP with any modern framework. Comet / Workerman / Swoole are capable to handle tens or hundreds thousands of requests with up to 1ms latency.

Compile a Java/Kotlin app with GraalVM and you can have <50mb app with 0 startup time which can outperform anything that node can do.

I benchmarked Node.js on V8 vs Node.js on GraalVM (Graal Node) and GraalVM performed worse due to floating point issues and used more memory.

How about Go?

Yes, pretty good alternative. But you will still need to hire "frontend" devs who can code in JS/TS. Go will perhaps have a more performant backend. So plus one and minus one. Also, not sure how easy / hard it is to hire experienced Go developers.

Reply on news.ycombinator.com