Apologies for the length here, but it seems like programming language and stack philosophy discussions simply require obscene amounts of length to produce fully-rational arguments. Trying to cut back invariably forces you to end the journey to philosophical truth with subjectively-felt emotion. Would appreciate feedback on what could be removed without compromising legibility.
Programmers generally overvalue the utility of a programming language to solve a particular problem, undervalue the utility of fine-grained knowledge of tools, and overvalue the utility of learning different paradigms.
We're moving from Rails to NodeJS, while it's not as drastic a change as, say, Rails to Python would have been, it's a big enough change to where I can slowly, over time, come to understand the absolutely stark differences between the two ideals.
The first thing that hit me is there just isn't the availability of third-party libraries in Javascript. We've had to re-implement functionality that we had gems for, first for pgsearch, second for CarrierWave, and I'm sure there's others. We undertook a fairly significant search for JS libraries that could replicate the functionality, but failed, leaving us to spend 1-2 weeks to write a bare-bones JS implementation.
I wrote the PGSearch implementation, and it involved studying the Rails gem output and the Postgres docs and concatenating SQL fragments together in a composable way. Luckily it didn't have to actually interoperate with Sequelize, that would have involved another week or two of work, the documentation on Sequelize is pretty far from Rails-caliber and I'd have needed to source dive from day one.
The second thing that hit me is the immaturity of the semantics of the language itself. When ES6 breaks, I simply don't have bandwidth to figure out why, the project is just that new. Ruby never breaks, I didn't even know that syntax and semantics of a production-quality general purpose programming language even had failure modes, that's how solid Ruby semantics are. But I'm finding myself having to wrap my head around the concept of semantic breakage in ES6, with frightening frequency. One day I'll isolate the root cause of what makes things like destructuring assignment fail to generate expected output, but right now workarounds are the order of the day.
I'm finding nothing really useful in those semantics that the team lead who made the nearly-unilateral decision to re-platform that are in any way interesting or even useful to spend time learning rather than just leveling up my standard library and framework understanding of Ruby and Rails. They just seem like hacky ways to do things that Rails already figured out clean approaches to solve.
NodeJS and React in particular seems to encourage weird separations from an OOP standpoint. Today I had the realization that routing is happening in both a centralized place, a dedicated, declarative routes file ala routes.rb, and more specialized routes in the controllers. This particular separation means that if I want to understand how a particular controller action is being routed, I must look in two locations rather than one, and if I'm starting outward trying to get in, I need to remember that the centralized declarations exist. When brought up, this was defended as "it works."
Of course it works, what I want is flat, easy-to-traverse declarative trees of definition. Is there a way to get to that? Not without breaking the conventions of Restify. This is something I didn't realize I'd come to lean on in Rails until it was gone. The semantics of modules in ES6 favor composition and discourage inheritance. A composed class in which the components live in a separate file than the parents needs special tooling so that you can understand the parent if all you have a reference to is the child. Otherwise you have to remember. JS fans seem to love to rely on memory.
Lack of clarity in the codebase forces me to use a debugging REPL to ascertain program behavior. This is another area in which no available JS-ecosystem tool even comes close to the power and utility of just dropping in a one line invocation into the codebase, cmd-tabbing over to the terminal or browser, then up-arrow and enter in case of the terminal, and cmd-r in the case of the browser to re-execute the code path, then immediately running commands in the context of the running application.
This fluidity appears to be impossible to find in Node, though browser debugging is mostly on par. I need it because I need to move the debugger around to ratchet closer to the source of the defect. Every extra keystroke matters. The three or so extra actions required in Node to get the debugger working is unconscionable, the sheer pain of it discourages a debugger workflow and relegates me to using logging statements, which, again, has a strictly worse standard framework implementation to Rails'. I could get into why, but this is way too long as it is.
It's not that I want to work with Node the same way I work with Rails. I'd love to be able to appreciate the Node Way. It's just that the Node way is cruftier and hackier.
This hell has me yearning to get back to the motherland. And I haven't even touched the differences in the metaprogramming workflow, which could easily double the size of this comment.
Straight up porting an app from Rails to Node.JS seems like a bad idea to me. Not that I'd ever consider using node.js, but the whole appeal is that you can quickly build small services, with either an integrating endpoint or a straight up api in front. If you're just replicating your Rails monolith you forfeit all the benefits.
To be clear instead of node I would consider either Ruby because it is more comfortable, or golang for it's simplicity and performance.
I also want to comment that I miss Rails while working in Node. The node ecosystem feels like a giant hash table. It's really hard to figure out where things belong except to memorize it.
Also choosing the right node module for the job can be hard. There are often 4-5 modules doing the same thing, all of them claiming to be the best, yet most of them not being that good at all.
If I had been consulted during the architecture phase, I'm fairly sure I would have found those alternatives and recommended one. I was not consulted, so we're stuck with the architecture we have, unless I want to go to the effort of changing the architecture.
Starting to really loathe the resource-augmentation biz model.
Programmers generally overvalue the utility of a programming language to solve a particular problem, undervalue the utility of fine-grained knowledge of tools, and overvalue the utility of learning different paradigms.
We're moving from Rails to NodeJS, while it's not as drastic a change as, say, Rails to Python would have been, it's a big enough change to where I can slowly, over time, come to understand the absolutely stark differences between the two ideals.
The first thing that hit me is there just isn't the availability of third-party libraries in Javascript. We've had to re-implement functionality that we had gems for, first for pgsearch, second for CarrierWave, and I'm sure there's others. We undertook a fairly significant search for JS libraries that could replicate the functionality, but failed, leaving us to spend 1-2 weeks to write a bare-bones JS implementation.
I wrote the PGSearch implementation, and it involved studying the Rails gem output and the Postgres docs and concatenating SQL fragments together in a composable way. Luckily it didn't have to actually interoperate with Sequelize, that would have involved another week or two of work, the documentation on Sequelize is pretty far from Rails-caliber and I'd have needed to source dive from day one.
The second thing that hit me is the immaturity of the semantics of the language itself. When ES6 breaks, I simply don't have bandwidth to figure out why, the project is just that new. Ruby never breaks, I didn't even know that syntax and semantics of a production-quality general purpose programming language even had failure modes, that's how solid Ruby semantics are. But I'm finding myself having to wrap my head around the concept of semantic breakage in ES6, with frightening frequency. One day I'll isolate the root cause of what makes things like destructuring assignment fail to generate expected output, but right now workarounds are the order of the day.
I'm finding nothing really useful in those semantics that the team lead who made the nearly-unilateral decision to re-platform that are in any way interesting or even useful to spend time learning rather than just leveling up my standard library and framework understanding of Ruby and Rails. They just seem like hacky ways to do things that Rails already figured out clean approaches to solve.
NodeJS and React in particular seems to encourage weird separations from an OOP standpoint. Today I had the realization that routing is happening in both a centralized place, a dedicated, declarative routes file ala routes.rb, and more specialized routes in the controllers. This particular separation means that if I want to understand how a particular controller action is being routed, I must look in two locations rather than one, and if I'm starting outward trying to get in, I need to remember that the centralized declarations exist. When brought up, this was defended as "it works."
Of course it works, what I want is flat, easy-to-traverse declarative trees of definition. Is there a way to get to that? Not without breaking the conventions of Restify. This is something I didn't realize I'd come to lean on in Rails until it was gone. The semantics of modules in ES6 favor composition and discourage inheritance. A composed class in which the components live in a separate file than the parents needs special tooling so that you can understand the parent if all you have a reference to is the child. Otherwise you have to remember. JS fans seem to love to rely on memory.
Lack of clarity in the codebase forces me to use a debugging REPL to ascertain program behavior. This is another area in which no available JS-ecosystem tool even comes close to the power and utility of just dropping in a one line invocation into the codebase, cmd-tabbing over to the terminal or browser, then up-arrow and enter in case of the terminal, and cmd-r in the case of the browser to re-execute the code path, then immediately running commands in the context of the running application.
This fluidity appears to be impossible to find in Node, though browser debugging is mostly on par. I need it because I need to move the debugger around to ratchet closer to the source of the defect. Every extra keystroke matters. The three or so extra actions required in Node to get the debugger working is unconscionable, the sheer pain of it discourages a debugger workflow and relegates me to using logging statements, which, again, has a strictly worse standard framework implementation to Rails'. I could get into why, but this is way too long as it is.
It's not that I want to work with Node the same way I work with Rails. I'd love to be able to appreciate the Node Way. It's just that the Node way is cruftier and hackier.
This hell has me yearning to get back to the motherland. And I haven't even touched the differences in the metaprogramming workflow, which could easily double the size of this comment.