React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.
There was some initial burden I admit with NodeJS but I have at least got to the productive plateau (with TypeScript). Once you figure out the pattern that works for you, it gets simpler. The inventing part is what drives most developers crazy, and it did for me too. It's perhaps too non-restrictive but well, hopefully there's somebody in your company showing you the right way. And you don't want to install every basic package by hand? But have them already included? You understand that adds quite a bit of bloat to projects that have no need for eg CORS or body-parser. And "code hacked together" is only a problem with bad programmers, you can get working and secure code with NodeJS, it just needs thought put into it. And yes, Rails has advantage with this but I think you made that argument clear.
Instead of making the argument "NodeJS is bad" you should aim that at the frameworks of NodeJS. SailJS was a good attempt at Rails but it's way too restrictive with its patterns (and sadly the documentation is not good). Deno looks promising and I hope people will be building better frameworks on top of that.
In the Ruby ecosystem, Rails will get you very far. In Python, Django will do the same. PHP –> Laravel. Scala –> Play.
JS does not have an equivalent, and the community seems to actively dislike the approach. That's fine, a monolithic framework approach isn't always the best option, but in the Node ecosystem it's not even an option on the table.
Perhaps because Express & Koa were "good enough" there never was a large enough momentum behind say SailJS to make it work. Nevertheless my experience with ORMs or scaffold generators has been that I always feel they are one custom use case away from turning from time-savers to time-sinks. When you write your own SQL and implement your own models/services or whatever abstraction you decide to use, you get a much deeper understanding of what is going on than just trusting your framework to do it for you. And is that good or bad? That is certainly a topic for debate.
This is interesting to me, because Ruby has Sinatra (and others) that compare well to Express/Koa. Python has Flask which is very popular, as well as a number of fantastic alternatives. These ecosystems have very mature, well designed, small web frameworks, but still people choose the larger frameworks in these ecosystems, and all of the frameworks get good maintenance.
I wonder if it's a cultural thing in the JS ecosystem. Maybe the ease of publishing a package creates a race to the bottom in terms of package scope, which makes it so difficult to sustain larger more all-encompassing packages.
I've worked with Ruby+Rails/Sinatra/Cuba, Python+Flask/Django/Bottle/Sanic, and Node+Express, and when I was in the Node ecosystem I sometimes really wanted that Rails/Django equivalent – not always, but the lack of it would cause me to avoid Node for large backend projects.
If you need complex relationship models, ObjectionJS sits on top and will auto-manage relationship tables and all that nasty stuff for you.
I'd echo the sentiments of the other developers here. Building a backend or full-stack app in Node is painful at every step of the journey. You're writing basically everything by hand, while using sub-standard orms and route handlers.
I've decided I like React enough to continue using it. But I'll be sticking to Rails for the backend.
It's not clear to me why people make this choice with node when after you choose it you are left to solve solved problems from scratch. Chosing node is the explicit choice to enter an ecosystem that does not have good cohesive solutions to basic problems. To do things that could be done easily with a framework like rails the very hard way.
My point was indeed that there is no real Rails equivalent in the Node ecosystem. Something mature which is supported by a large community over many years. Django, Spring Boot, Laravel, Phoenix play such a role in each of their language.
In Node you have to come with your own set of libraries, structure and convention, which is not the most efficient way to start and maintain a project. I agree that more senior programmers might avoid most of the common mistakes, but still you might spend time discussing little details such as structure and conventions. Frameworks such as Rails make at least some of those discussions irrelevant and allow you to quickly move on.
That was the entire point.
Deno is not a framework.
As in building frameworks on top of Deno, like Express/Koa/etc are built on top of Node; Node is not a framework either
In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale.
For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment.
The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.
Regarding Node.js, however, I would say the pain is not worth it. For the same purpose I would now reach for Go (for networking stuff) or Rust (for high performance). This is after several years in a Node shop.
React bringing the “same way of thinking” in the front end industry may be true now, but it definitely was not the case for many years. I saw three or four react projects and they were architected very differently, with different routing, different state patterns, different approaches to updating backend state, different build systems, etc.
meta: I won't mind _this_ comment being downvoted since we're so far afield from the OP, but it's worth it to me to clarify intent in responding to a friendly peer.
[1] Technically, Node didn't invent server-side JavaScript; Netscape's application servers supported a version of the same idea in the '90s, back when Netscape was still a thing. But there was a long period where JS was effectively ghettoized as a language for browser scripting only, and Node is what broke it back out of that.
and
a generation of programmers that grew up on Javascript thinking it would be cool to write JS on the server too.
It's funny because many frontend web developers are keen to point out the distinction between Javascript, HTML and CSS and the importance of why HTML and CSS are distinctly different mark ups. Yet will then discuss frontend and backend code as if it's the same beast.
Maybe this opinion is an age related thing though. I've been publishing websites since the 1990s ('93 I think my first site went live). So I've always seen frontend and backend as separate entities - as they were for most of the web's evolution.
"The right tool for the job", yes, of course -- but why would you insist that a particular set of traditional architectural constraints must needs be permanently enforced at the level of language and runtime? Being locked into a "3-tier architecture, server-side" perspective is a common trap for many senior developers. As is dismissing the real (and amazing) progress and expansion of possibilities inherent in the accelerating changes in front-end technology. Of course there are ignorant juniors. Of course the signal:noise ratio in the world of modern web and mobile dev is suboptimal; there's so much churn and noise and froth. But also progress, evolution, improvement. To write it all off, clinging to comforting notions that what we mastered a decade or more ago is the best -- let alone only -- way to do it?
"The difficulty lies not in grasping the new ideas, but letting go of the old."
1. it was too difficult to get any other language first class support for browser scripting (the reasons for that are obvious)
2. frontend developers wanted to reuse the same language for front and back (often because they simply didn't want to learn another language).
Let's also circle back to my point about the right tools for the job. Javascript has always made some sense for frontend development - it might not be the best designed language from an academic perspective but it suited browser scripting well enough to get the job done. Plus in the early days we didn't need anything particularly pretty anyway. But JS definitely did not suite backend development when Node was first being deployed. In fact I'm pretty sure Node was just a hobby project where some guys thought "Chrome's JS VM can run headless - lets see where this takes us." (this part may be incorrect but I have a vague recollection of that being the case). However without tools like Docker nor any decent way of running parallel execution stacks (nor a first class web server supporting Node ala mod_perl / mod_php / phpfpm / et al) it meant Javascript was simply not a good language for backend development for a relatively long time because the tooling wasn't there and the language lacked the primitives to compensate (like how Python, Perl and Ruby could all self host their own threaded web server).
These days Javascript still doesn't support threading but it does have other primitives that do a reasonable job of compensating. Plus with tools like Docker, you can always scale sideways when your application failed to scale upwards. The tooling around JS has improves, the language itself has improved and the way we host web sites has also evolved (eg cloud environments running containers vs VMs or even bare metal servers running web servers written in C++ which spawn language VMs as separate processes). The whole landscape of backend development had to change as well as Javascript itself before it really because a first class backend language.
So to summarise, yes you're right to and extent. But you answer a subtly different question: "why is node still popular?" rather than the question I was answering: "why did it become popular?"
Ironically it was the popularity that gave node the momentum to improve; rather than node initially being good that gave it popularity (though obviously node improving would have had a snowball effect on node's popularity as well).
Definitely a fair point about addressing the original question. IME, node _became_ popular in part because it allowed web developers to start solving problems themselves, directly, using a language they already knew [albeit a kind of terrible/problematic language at the time], to do things like CLI scripting for automation of tedious FE dev workflow tasks (a la Grunt and bower), or standing up dirt-simple web servers. At that point the floodgates had opened. With the concomitant (and ongoing) shift in architectures toward executing more and more of the application on the client side (with hugely popular services like gmail and google maps demonstrating the power of "Ajax"), the rest became almost inevitable. With Node, like Javascript in general, the quality followed the popularity, as world-class engineers set to fixing and improving what was available to work with, to shape it into something better-suited to the task. The process might even be ~akin to selective adaptation in biological evolution.
nodejs is JavaScript bindings for libev. http://software.schmorp.de/pkg/libev.html
Other comments listed npm modules with Rails equivalents, so I won't repeat.
The one thing I got out of nodejs is becoming reacquainted with working closer to the metal. Minimalism for some HTTP endpoints (what the kids call REST) can be fun.
Rails, PHP, nodejs et al, J2EE, etc. I've got no dog in this fight. Each is uniquely terrible. I hate them all.
Just my two cents, I would be happy to hear some success stories from it though.
- Parcel is like if Webpack were a build system and not a programming language to create a build system with. - Vue has good set of solutions. Nuxt is a nice version of "here's what you're probably going to want, already glued together." - If Deno ever becomes a thing, it will be cool.
It feels like maybe if we're lucky, in five years, there will be an ecosystem for modern JS that doesn't suck.
I personally prefer callback convention, but it's not the only paradigm. Primises/Futures, and async/await is also very popular.
Node.JS makes you think async, which has a learning curve, but I prefer that over multi threading locks and data races.
Go is also great. But I think JavaScript is much easier.
Use Angular on the client and something server side in Node and you're set.
Use Typescript and you'll be able to refactor easily too.
Nobody uses just React+Express w/o TS for something serious.
Yup. Because there is no Rails-like framework in NodeJS.
>Use Angular on the client and something server side
That "something server side" is the entire problem. In 2006 if you're writing a web app, the answer was Ruby on Rails. In 2019 the answer is "Angular or React or Vue on the front end and something server side". No generators, no scaffolds, no auto-generated migrations, no opinions, no ORM, no standardized way of doing anything, no naming scheme, no guidance. Just "something server side".
If I said "use Ruby to create a web app" you'd load up Rails. If I said "use Python" you'd load up Django. If I said "use NodeJS", you'd just... list all your NPM packages?
To be honest I wouldn't suggest Node as a solution for your backend which is probably why I said "something server side" because when I think Node I just think of a thin API wrapper that uses an RPC to call your Java services or what-have-you. The only reason you even do that is to give the FE people something to mesh data together from services for their clients while you can keep backend APIs generic. Luckily graphql will start to replace that convention.
Makes me want to build such a framework in TS... but why would I do that when I can just use Spring. :)
Keep in mind, at my current company we don't use it (giant 5 year old AngularJS codebase) but I would love to.
You don't even have to use it fully. Just mark your function arguments and you're already saving headaches.
I agree though that using TS and not worrying about actually defining types can be great. I do think you can run into sort of wandering inference bugs or cases where other peoples' types can be poorly defined, but that's a rare problem in my experience and well worth the benefits you get otherwise.
Anyway, I'm definitely not trashing TypeScript or suggesting no one should use it or anything. I almost always start new projects with it.
You can check here www.kiwi-server.com.
Of course It's open source
As an example, I spent quite a long time investigating ORM libraries for relational DBs, and the projects that were half dead were the majority.
Knex was suggested by everyone, but at that time the project leadership was changing so the future was uncertain. I settled on Sequelize, which had most of the functionality, but several points did not make sense:
- the documentation is hard to search
- I had to create a PR for sequelize-cli (separate module, that is not recommended for production!) to get the same functionality of `rails db:create`
- the syntax was changed to use Op instead of strings for security, in a minor version
- the way associations are defined is weird at best
- no support for ES6 in the cli, so all migrations are ES5
Etc.
And this is just for an API server. I looked into the frontend part and it was so much work.
I am still using Node for server processes when I have to, but I wouldn't recommend it over Rails. The way you can generate a simple app that does something useful, configure it and deploy it to Heroku in few hours is unchallenged.
Doesn't matter if you're coming from outside or not, no one can predict the future.
For example winston was probably the most recommended logging library (14k stars) and was a good recommendation at one point. But then they decided to do a rewrite for v3 which introduced a ton of bugs and incompatibilities. I spent several days trying to get it to log in the old format and failed and ended up downgrading back to v2.
This is a recurring theme in the js ecosystem (another example is react-router which is just a huge piece of shit and no one should depend on it despite its 37k stars).
Put on top the fact that NPM doesn't want to deal with version conflicts and installs 173 versions of the same package and you get a huge directory full of security warts.
The JS ecosystem is just immature.
No one does, they just throw it in production and hope whatever way they figure out how to get the thing they need done at that moment doesn't burn them later.
What anm89 says is on point. All solutions available are awful in their own special ways. If a router solution _is_ needed, and there's no chance you can't just rely on the browser history API, imo stick with RR despite it's major downsides, because at least there is the major benefit of vast community support; all solutions seem fairly shit otherwise (just cross your fingers you don't need to do any React Native work that needs a routing/navigation library cos hoo boy it's a shitshow)
They have a react version. I experimented with it in one of the small projects i worked on. My experience was positive.
Most importantly, it's API is simple and easy to use.
The backend was written in Go, and I just ran go build and it worked without problems. The fact that it just worked without me having to change anything shows how important backwards compatibility is to that community.
The past few weeks I've been working on a backend Typescript project, and the number of packages I've seen that don't use semver or any similar versioning system makes me cringe. I even saw one that wore this as a badge of honour in their README :s If you release a library and you don't have a sensible versioning system, you are just making life harder for your users. (I'd argue for a CHANGELOG too - the GitHub releases section doesn't count)
Action text in RoR <=> DraftJS (Isomorphic ReactJS plugin with server side rendering), Froala (compatible with most of SPA frameworks)
Active Record in RoR <=> SequelizeJS (ORM), Slonik(Non-ORM, my recommendation) in NodeJS
Action Cable in RoR <=> WS, Socket.io 2.0 (recommended)
DraftJS - https://github.com/facebook/draft-js
Froala - https://www.froala.com/wysiwyg-editor
SequelizeJS - https://sequelize.org/master/
Slonik - https://github.com/gajus/slonik
WS - https://github.com/websockets/ws
Socket.io - https://socket.io/
Put another way, you're exactly right, it is apples to oranges, or a better analogy might be a Porsche to a Pontiac. Why would you ever choose the thing which is inferior in almost every way?
You should have a look at things like adonisjs.com to get a better comparison. I am not saying node-based tech is better or worse, but to dismiss all nodejs server side and say Rails is better at everything is not a healthy attitude, especially regarding the shaky history of the Ruby language itself (eg. The whole RubySpec thing).
And; how can node be inferior in every way when it isn't even the same kind of entity? It seems you are barking up the wrong tree.
It is a testament to how successful Rails is when it is hard to distinguish it from the programming language it runs on. Congrats to them.
I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance.
It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor.
Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions.
Experience can actually be a negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for example.
But what I can or cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole.
Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people.
It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.
Ryan Dahl has a speech about his regrets with Node, and most of them center around the way code is managed.
IME, the sloppiness to how code is managed in Node, combined with the lack of conventions/dominant Rails-esque framework in the Javascript ecosystem, leads to codebases where no one is sure how or why something is set up the way it is.
As annoyed as I sometimes get with Rails' forced conventions or auto-magic abstractions, the beauty is that they are consistent. With a team full of experienced Rails engineers, you can pretty much guarantee that multiple people on your team can explain the "why" behind something quickly. This is a massive productivity save, especially when you're ramping up.
https://edgeguides.rubyonrails.org/action_text_overview.html
Rails is a web framework. Why does it have anything to do with a WYSIWYG editor on the frontend? There's a giant vast offering of WYSIWYG editors to choose from that POST data back to your web backend just like any other form. I don't want rails to have any opinion or "state" of WYSIWYG selection for my application.
I kinda feel like Rails had it's heyday around 3.2 or 4.0 and since then has been creating problems to solve instead of solving actual popular use cases.
Man did you pick the wrong framework.
>There's a giant vast offering of WYSIWYG editors to choose from
As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works.
>Why does it have anything to do with a WYSIWYG editor on the frontend?
Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way.
That's an obviously false statement. There's like a dozen react based ones alone and at least as many vanilla JS ones all over the web. I've implemented several in Rails before with image upload support. Works no differently than any other web backend.
> Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way.
No, Rails explicitly does not have opinions on everything. It doesn't even come with built in authentication handling, which is a pretty major web framework component. I like that it has strong opinions about things like handling the HTTP request/response, configuration, code layout, ORM, etc but leaves a lot to the user to implement. In the past they've even culled features off into their own gem when they decided it wasn't relevant enough. A WYSIWYG text editor doesn't seem all that much like core functionality to me.
rails new app_name --skip-action-cable --skip-action-text etc...
rails new -h see all the options
I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box.
The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers.
Hope they will ship many more releases!