You will set up an Express server, look at the code, and think: "Where is everything?" No ORM. No router DSL. No middleware stack configured by default. No generators. No conventions. This is not a limitation -- it is the philosophy. Express gives you a function that takes a request and returns a response, and everything else is your problem. After Rails, this feels like being handed a knife and some wood and told to build your own furniture.
The instinct will be to judge Express as primitive. Resist that. What Express teaches you is what Rails does for you. Every middleware you manually wire up is a middleware Rails auto-configures. Every route you hand-register is a route Rails infers from conventions. This is valuable knowledge. You will understand Rails better by building without it.
Node's single-threaded event loop is a fundamentally different concurrency model from Puma's thread pool. Node handles concurrency through non-blocking I/O and callbacks, not threads. One thread, thousands of concurrent connections, no shared-state race conditions, but also no CPU parallelism. This is why Node is excellent for I/O-heavy workloads (APIs, real-time apps) and terrible for CPU-heavy workloads (image processing, ML inference). Puma's multi-threaded model handles both, at the cost of thread-safety complexity. Understanding both models makes you dangerous in architecture discussions.
The npm ecosystem deserves its reputation -- both good and bad. The velocity is extraordinary: there is a package for everything, published yesterday, with twelve dependencies you have never audited. left-pad broke the internet. node_modules is a meme because a hello-world app can pull in 400MB of dependencies. But the ecosystem also moves faster than RubyGems ever has, and the best packages (express, fastify, zod, prisma) are genuinely excellent.
Learn to read package.json the way you read Gemfile. Learn npm audit the way you run bundle audit. The tooling is different but the discipline is the same.