I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app.
Rails is not the only choice that does so. And people with broader skill sets can assemble their own solutions and might not want that anyway. But this author just wanted to pick a platform and move on, and yep, Rails works for that.
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that.
* Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core.
* React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
* Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison.
* Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc.
Without speaking of the DOM and CSS, which are just _now_ starting to feel feature complete for most use cases.
Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.
"Javascript has such a minimal standard library"
My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust?
My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.
This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues.
TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction.
[0] https://tc39.es/
[1] https://developers.google.com/web/updates/2018/03/smooshgate