When working on projects that have back-end and front-end teams separated and the back-end is not using NodeJS, I often see front-end guys having a “brilliant” idea to add a NodeJS component somewhere in between, either for the “performance scale-up” or “this is so easy and intuitive to do certain things in NodeJS”.
In a conventional CRUD, monolith application, adding NodeJS to the backend is actually bringing more harm than good in my opinion:
- add another language/framework that the back-end team needs to master
- performance bottleneck is usually not in the webserver. Often the database is the bottleneck
- maintaining a proxy/dispatcher just adds more complexity to handle when errors happen.
Don’t get me wrong, I like JS as much as other languages. I’m just feeling some JS developers, compared to other languages developers, are pushing a bit too hard to inject their favorite languages everywhere, even that doesn’t make much sense in terms of architecture.
Love to hear your thoughts and experiences here.
I think we all push for familiar solutions. There are just a LOT of node users.
The main reason to be modular when building most systems today has nothing to do with performance. It’s to apply Conway’s law in reverse and avoid having to waste so much time communicating and convincing other humans to let you get work done.
The short answer would be : Conway law combined with familarity. The system reproduce the communication structure of the organization. The front-end have a need to do some supporting stuff on the backend, but the backend belong to another team, and it’s easier for them to just wrap that backend in a “backend for frontend” that to deal with the politic. So they build a new system. And that system is likely to be in JS because that’s what they know.
For the long answer: let me just note that your question is actually two questions:
Let answer the second question first. Why build backend component in NodeJS? Well, Node is already used in the frontend team build, along with mocha, chai, eslint, and other node standard tools. They already manage their dependencies via NPM. Building a backend part in Node mean using the exact same set of tool that they know, and the same language that they know, and the same IDE that they know. This is why my personal projects use Node: I use JS anyway for the UI, and it is less friction to just use it on the backend too, as I don’t have to write my string-util module twice.
First question now: Why a proxy? Having introduced such a proxy in a project, our stated reasons was control and risks: the existing mission system was hard to work with, had no tests, and took 15 minutes to boot. Changing it involved political discussions with people that viewed changes as dangerous to their job. Any outage was 30 000$ per hour in cost. It took 6 week for new code to be in production. With a non-mission critical proxy in our control, no such restraint: release was on every pull-request, and we could use TDD, static check our code, do automated deploy in the cloud, without asking the permission to anybody. If the project was ever cancelled, there was little to rip out of the existing mission system. Also, our proxy was doing tasks like validating form values, which was strongly coupled to a UI that was changing with every whim of marketing and UX. Had we not introduced the proxy, our capacity to iterate and accommodate their request would have been seriously hampered. I still stand by our decision to introduce it.
An interesting point : We built said proxy in Java. Since we were Java dev, this is what we knew. The JS part was the new part we didn’t knew much about, and we wanted to limit the part were we would do dumb stuff. If the team had been familiar in JS already, I may well have recommended to use Node.
There’s a huge funnel problem for computer science at the moment. Go and Rust have some pretty serious evangelical marketing teams, but they are a drop in the ocean compared to the emergent ultramarketing behemoth that feeds JavaScript to the new developer.
Part of this is that JS is constantly “new and modern” – with the implication that it’s a bandwagon that you’ll be safe on, unlike some of the old cobwebbed bandwagons. Constant change and “improvement” is itself a safety generator.
Another part is that it’s so easy to get to hello, webpage. The sweet spot on the racket is enormous. Every computer including your phone comes with at least 1 and usually several JS interpreters. Frictionlessness drives adoption.
The problem is that JS is, violently, garbage for most purposes. It’s a local maxima that has essentially everyone trapped, including the next generation. It’s not clear how we escape from this one.
I feel about JS similarly to the way I felt about the x86 ISA taking over the world. “A local maxima that has everyone trapped”, that caused billions of dollars of R&D to be diverted into clever hardware, code generation, psychological treatment for programmers, etc. (I think the last thing is a joke, but I’m not sure.) One could even draw a parallel between the modern “micro-op” architectural approach to bypassing literal x86 in hardware and the WASM approach to bypassing literal JS in the browser.
The longer it goes, the more this talk gets correctly.
I’m not sure any other ISA would have been better than x86 at the time x86 began to take off. Lots of companies were trying lots of things in the RISC world, and plenty of money was being spent on RISC hardware and compilers, and the x86 still began to take off. Intel had a lot of money? IBM had a lot of money, and IBM was working on RISC. HP had a lot of money, and HP was working on RISC. And so on.
Of the obvious choices available at the time x86 began to take off (1984ish), I would say the 680x0 was a better choice, demonstrated by watching the parallel evolution of the two. At least the extensions to 32-bit and virtual memory seemed a lot more straightforward on the 68k. They both would have run out of steam and gotten weird by now, but I feel like it would have been less weird.
Simply wait. There are some better tools out there (for some value of the objective function “better.”)
We’ve moved on from C, C++ and Java, all of which have had a similar level of death grip. JS is not invincible. The more users it attains, the more it suffers problems of perception due to the wide variance of quality. This gives rise to new opportunities.
Really, I get a bit disappointed that everyone is content to rewrite everything every seven years, but, hey, it’s their life.
I take strong offense at this proclamation of JavaScript as garbage. What kind of an opinion is that? If you don’t know JavaScript, don’t call out garbage. If you do know if well, you’ll see that it isn’t any more garbage then any other modern language for most purposes for which it is used - at least on backend.
The entire ecosystem has some issues, but every ecosystem does. And considering that node was created only a decade ago and has vastly more users then some “serious” things that exist for ages, it’s obvious that there’s something that it’s going correctly.
You are offended on behalf of Javascript? People can dislike things that you like. It doesn’t do anything.
Okay, inprecise choice of words on my part. I’ve wanted to state that I strongly disagree with his statement, english isn’t my first language and so I didn’t think every word completely through. I think you can still get the message. Be flexible a bit and you’ll understand it.
I’m not sure what other languages you know, but compared to most popular languages:
Javascript has a weird type-system that doesn’t really pay off. Sure, they added inheritance recently (welcome to the 80s), but there are all kinds of inconvenient relics like having to do
Object.keys(x)when in Python you can just dox.keys()(as in most popular languages)Javascript makes it much harder to catch errors. Its implicit typecasting (undefined+“1”==“undefined1”, really??) and misuse of exceptions in the API means that when something goes wrong, you’ll often find out a few functions later, and then struggle to zero-in on the actual problem.
The ecosystem is too fractured. The lack of a curated “standard library” sends novices into all sorts hacky solutions, and makes other people’s code less familiar.
I could really go on for a long while, and there are tons of example that I could give. I can say positive things too, like it has a good JIT, lots of interesting libraries, and some nifty syntax features (while lacking others), but overall think it’s a really bad language, that just happened to be in the right place and in the right time.
For the record, JavaScript has always had inheritance, it just hasn’t had a class syntactical sugar that made it trivial to use until ES6.
I wouldn’t call it bad. It just has bad parts. The == operator you mentioned is a trap for many beginners. On the other hand, there’s no inheritance problem because the inheritance was always there - you just have to know how prototypes work. The type system without extra tools and some practice is a pain. Yet the closure or say prototypical inheritance and composability you get is great.
JavaScript got really lousy reputation because unlike, say, C++ or Java, everybody wrote it, not just people who studied software engineering for five years and know how to use tools, have structure and not break the rules.
And it’s keeping the lousy reputation because it is still being done - randos adding jquery plugins for perfectly css-able animations even today.
Plus it’s got 25 years of backwards compatibility to maintain, so those bad parts never leave. Yes, it has been at the right place at the right time - but many others have tried and are still trying.
But despite all the bad parts and lack of standards, it’s still immensely flexible and productive and for a lot of use cases actually provides the best concepts to do them. Could you put something like elixir in a browser engine? Or java? Or Rust? Probably. Would it be better? Maybe, but I suspect not by much.
I don’t know, I’m probably not seeing it. I’m not claiming that it’s a great language or that it’s even good for everything and everyone. But people only see the ads and single page apps where they don’t belong or where they simply don’t like it, and ignore a lot of directness that the language provides, look down on flexibility, and don’t allow the little language that could its deserved praise (where it does deserve it).
Once again, as I’ve said in another comment - I don’t claim it’s the best language ever. I’m just saying it is not garbage. These days the tooling and the entire ecosystem is mature and there are no more language issues in writing a typical NodeJS application then in most other similar languages.
It added inheritance as a sop to people who didn’t know composition and refused to learn. Are you not satisfied with that? Does it have to become a pure Smalltalk clone for you? Composition is more powerful but it’s less familiar. Now JS has easy ways to do both.
I have a deep understanding of JavaScript; I promise that my opinion is rooted in experience.
Even though you personally find Node impressive, there might be people who don’t get impressed by languages (or any software really).
Being impressed or having respect (for a software) makes no sense. It is just a tool that should be used or discarded at will. Not a cultural icon.
You have stated no arguments that support your conclusion. I believe that the jury is still out on the matter of language effect on productivity. All the studies I know of were totally botched.
Anecdotally, I have seen more poor Node backends than Python ones. I have also seen less high quality Haskell backends, which confuses me greatly. Still, I wouldn’t go as far as to conclude that everything is the same crap.
Denying the role of aesthetic judgement in programming is madness.
I didn’t state I find Node impressive. I do love it for the productivity it brings to me. And that is just the point of my reply. The guy claimed JavaScript is garbage, also without arguments. I’ve just pointed out that. No more garbage then any other language, in my opinion. If anybody brings arguments into this whole discussion, including the original post of the thread that claims people are pushing node, we can talk about with arguments. Otherwise we’re all just giving opinions and estimations.
Anecdotally I’m seeing much more crappy Java Enterprise and Spring backend code lately then node. Likely because I work at a java shop now. But I don’t claim that people are pushing Java exclusively for backend (even though they do at my company, we literally have 100% Java in my 800 people department), nor do I claim Java is garbage.
I hope that clarifies my objection to the claim of garbageness.
I think you are right that JavaScript brings great initial productivity. Especially in the single developer case. For many simple tasks, it is easy to use node, easy to use npm, and easy to deploy code. Where I have seen problems that I know are avoidable in other languages is in its long term sustenance and operation, which are vitally important parts of software engineering.
Other languages have, for example, highly vetted and deep standard libraries of functions which are included in the system and move very slowly, which eliminates large classes of dependency management issues. Or, they have good type systems, which helps prevent common problems, especially in dynamic languages. Or they have exceptional tooling that enforces good practices. Or they are especially operable in production, with good intrinsic performance or observability characteristics.
But the most important thing, to me, is that most other languages have a culture of remembering, but this is distinctly lacking in JavaScript. I attribute this to many JavaScript programmers starting from scratch in their software career inside JavaScript, and not having broader exposure to the vast surface of other kinds of software. And I attribute it also to the “stack overflow” method of programming, in which rather than engineer your software, you assemble it from the guesses of others, losing fidelity and getting more blurry with each iteration.
It could sound like I’m being a pretentious jerk. I’ll confess to that. But having been a professional software engineer for now 32 years, and having seen probably a hundred languages and environments, the current JavaScript one is my least favorite. I appreciate that it’s one that you have significant personal investment in, but I would also encourage you to step out and up, and look around.
Thanks, this also raises some quite relevant concerns. And I agree with these things. And now I have to fall back to the fact that despite these problems, it’s not garbage. I did step out and I try other languages and their frameworks, but I’m simply personally the most productive with it. And when I worked in teams where Node was used on the backend, the teams were professionals and mostly didn’t have problems with the language itself - maybe more or less then if it was done in, say, Spring or Rails, but I would say the typical problems are always stupid things like commas in the database where they break serialization somehow.
And that is the point of my original comment. Which was that I object to the claim that JavaScript is garbage. Maybe a lot of garbage is written in JavaScript today, but it in itself is not that, and can provide perfectly productive envrionment for doing our jobs.
I wouldn’t call JavaScript “garbage” myself, but it sure has some problems that few other languages have.
[1] + [2]resulting in"12"being a simple example. JavaScript definitely took the 90s/00s vogue of “all things should be dynamic!” more than a few steps too far.Well, just because it’s popular doesn’t mean it’s good ;-)
I notice myself that I often use tools that I know, even when it’s not necessarily the best fit, simply because it’s so much easier. Yesterday I wrote some Ruby code for a Jekyll plugin and had to look up a lot of basic stuff and made a few simple mistakes along the way; there was quite a lot of overhead here. And I programmed Ruby for a living for 2 years (but that was 5 years ago, and looks like I have forgotten much).
JavaScript is rather unique in the sense that almost everyone has to deal with it because it’s the only language supported by browsers[1], so there are a lot of people familiar with JS who would rather like to use it in other scenarios as well: not necessarily because it’s the “best”, but because it’s just easier as they won’t have to re-learn a whole bunch of stuff.
That’s not necessarily a bad thing, by the way; I’m all for giving people the tools to Get Shit Done. My point is merely that much of NodeJS’s popularity probably stems from factors other than intrinsic qualities of the language, runtime, and/or ecosystem.
[1]: Ignoring wasm, which isn’t quite ready for production-use, and “X-to-JS” compilers, which typically still require knowledge of JS.
Oh, I wasn’t claiming that the popularity of NodeJS comes from it’s quality. I’m just saying JavaScript is not garbage, which the commenter claimed without argumenting it.
I mean, I know that [1] + [2] is “12” in JavaScript. But if you ask me how many times I’ve had a problem because of that in the last year, I would possibly be mistaken, but I would say 0 times.
Again, it’s not the best language and it has its problems. But it’s not garbage.
I find this interesting, because a few comments upwards, you state this:
It might just be me, but in no other language have I ever heard of specifically this problem. If you dig a little deeper, you’ll notice that there are a few fundamental issues in the language. But definitely the most prominent root issue is that types are treated extremely loosely, which causes all sorts of offshoot problems, like the two above.
I always try to think a bit more holistically about this, and when you do, you start to see this pop up everywhere. Just yesterday I was debugging an issue with a colleague where he accidentally was throwing a JSON-encoded string at a program where in fact he should have been taking the JSON document, extract a specific key’s string value and send that to the program. Basically the same thing: it’s too easy to mix up types.
I occasionally see this in Python as well: when you accidentally have a string instead of a list of strings; because of the “everything is a sequence” abstraction it’s too easy to mix things up, and you end up chasing down the rabbit hole before you figure out where it’s going wrong. It’s better if things error out early when you try to do something that makes no sense.
Having type-specific operators makes it easier to get your bearings when reading unfamiliar code, too, in my experience.
No, it means JS has a powerful monopoly (the web) and thus commands a huge mindshare. Some subset of those people want to take their painstakingly earned experience to the server.
So, ‘heads I win, tails you lose’, eh? Good argument. /s
Do you feel Rust developers are pushing a bit too hard to use Rust everywhere?
When working on projects that have user-space and kernel-space teams separated and the kernel-space is not using Rust, I often see user-space programmers having a “brilliant” idea to add Rust to the kernel, either for some “performance scale-up” or to make memory management “so easy and intuitive”.
In a conventional application, adding Rust to the project is actually bringing more harm than good in my opinion:
Do you hear yourself? Do you see how this can devolve into absolutely anything?
What do you value? What’s important? Is it to make cool things? Fast things? Memory-safe things? Javascript-all-the-things? Or to simply have an easier life? To be lazy? Get high and play quake?
If you think someone has a weird opinion, chances are you don’t know what they value. You might be able to understand if they value something else more than you, they’re going to come up with different ideas and opinions than you.
But if you know what their value is, you can decide for yourself if that’s something you want.
Is that actually true? It feels like studies from, say, Microsoft, suggest it is not.
This is clearly a parody of OP’s “performance bottleneck is usually not in the webserver” :)
This must be what it feels like to fall for an Onion article!
As much as I don’t like nodejs that much, there’s nothing wrong with a team choosing to use node for frontend and backend.
It sounds like your situation is much more specific. If there are 2 teams and team A is asking team B to add more moving parts and to adopt/support a framework B is unfamiliar with just because A is familiar, that should set off some warning bells.
If the entire organisation is running on some other language, then introducing a new one will add overhead for everyone, such as sysops having to get (and keep!) it running, but also making it harder for other teams to understand/re-use code from the now-JS project, contribute fixes to it, etc.
This is an issue with any new language, and not specific to JavaScript. I think this is one of those cases where fairly small businesses look at all these huge tech companies deploying a host of languages and think “that’s awesome, we can do that too!” and forget that Google and its 20 different languages has a sysops team that’s slightly larger than your 2-person team which in all likelihood is already overworked from trying to migrate everything to k8s.
Even when NodeJS (or $other_language) would objectively be the better choice from a technical point of view, it may not necessarily be a good idea to actually use it because of these kind of practical “facts on the ground”.
You know that old saying about how the structure of a large software system usually reflects the structure of the organization that writes it?
I think the power of NodeJS, from the beginning, has been that it allows people with a front-end background to do an end run around back-end development teams that they don’t get along well with. It does that by being the same language that nearly every website uses.
You can argue about whether that’s a good or a bad thing. I personally think it’s a good thing. Organizational friction sucks to have to deal with, and it’s very powerful to have an option that reduces it.
I would say that if you’re seeing this request to use Node a lot in your organization, there is probably a social problem that you should address. It’s great that Node exists as an option for this situation, but if teams that rely on each other aren’t talking to each other or don’t have the same priorities, that’s really, really bad for the long-term future of your organization. Focus on the social issues before they get even worse.
Several differences in established languages such as Java and .NET on backend:
The ecosystems move more slowly.
They’ve been used in tons of situations where they ran into problems and probably fixed them.
Tons of tuning of VM’s in GC, profiling, etc.
Lots of tooling in ecosystems.
The maturity combined with the above should make it easier to build systems that run for a long time with higher stability and less maintenance. Performance differences will vary. The JS ecosystem just seems to move quick with no focus on long term or high reliability.
I figure combining JS with .NET or Java backends might negate some of their benefits. The exception would be if the backend app itself was flawed in a way they couldn’t get fixed. Then, the JS was added to fix it. I’d still encourage them considering, if they have the skills, using Java or .NET for that proxy using the most boring, battle-tested components they can. If the backend is a problem and they only do JS, then it would be a good idea to inject JS to deal with it.
That’s my non-scientific analysis based on what I’ve seen in the ecosystems over the years.
There should be an architect who makes such decisions – not „front-end guys pushing something“. And he should see the system as a whole instead of be focused on one certain part and its performance or convenience for a particular task.
To answer your question: yes, people often push what they know and what they are used to, because it is comfortable for them.
Or she/they.
In a way, I agree, but I feel like you are going right to the opposite end of the spectrum. I think the better scenario is that the architect gets the frontend folks to make the right decision for themselves versus imposing a decision. I expect an architect to be an effective influencer without having management authority.
The ability to hold a veto is an important responsibility of an architect, but they shouldn’t wield it for many decisions because it creates other organisational and management problems. From the frontend perspective there might be some things that an architect is missing and you want them to be able to raise those concerns.
Much of my beloved profession has become an abomination. 100% javascript stacks are the closest we have to the cleansing fire. Let it burn!
For me, it’s usually not JS developers pushing, but single-language developers pushing… More mature(?) developers tend to push less and ponder more.
And since JS and PHP are the entry languages, I see a disproportionate amount of pushing from these two language users.
It definitely feels like “Nodejs developers” will try to use nodejs as much as possible in any scenario they can, more so than other developers in my experience.
Where this makes even less sense to me is when it comes to dev tooling. They will write a whole npm module with a bunch of dependencies to do what a shell script could have achieved in one or two lines.
I typically use PHP for web backend projects but I’m pretty reluctant to write general purpose tooling with it. The
It’s the fast path toward putting “full stack developer” on your resumé.
This type of answer belongs in HN. Let us keep this community different.
This should be the accepted answer.
This is not SO and even there it’d be marked off-topic :P
Glad you enjoyed my joke ;)
This is not about joking, this is about keeping the comments section on lobsters different than the popular communities where it’s much easier to say snarky one-liner than giving a thoughtful answer. The fact that /u/idrougge post is the most popular post in this comment section might show how “mainstream” lobsters is getting and reflect how I generally feel lately about this site.
Something something upvote comment trees bad, forum good.
This is unfortunate that instead of addressing anything I said you resort to sarcasm and do exactly what I’m pointing out about this comment tree.
This is so poignant, I had to interject. Because @N64N64 is actually pointing to the root cause of Lobsters’ decline, just in such an inarticulate way that you missed the point… as did all eight of the downvoters that caused the comment (and any response to it, including this one) to become hidden by default. I always expand these, myself. And I generally read lobste.rs/newest and keep an eye on the mod log, because I’ve been around a bit and am firmly convinced that popularity points are actively harmful to thoughtful discussion. They incentivize the bad behaviors you and I both know too well from Those Other Sites and don’t want on this one. Reordering the comments by popularity just accelerates this bad pattern, as well as obfuscating the natural temporal ordering of a conversation, and perpetuating the weird notion that one only responds to a single comment at a time. So yes, upvote-ordered comment trees are bad, and the older and plainer style of forums are really better, although probably not the best possible form.
We can shake our fists and demand that newcomers discipline themselves against their conditioning, but I fear that we’re pissing in the wind. Ultimately, Lobsters will devolve into just another snark tank, and those of us who need something better will go find it somewhere else.
Thanks for filling in the “something something” part. :)
Maybe I’m the exception to this behavior, but as a front end dev of 8+ years I’ve always been happy to jump into unfamiliar back end code to contribute as needed. Over the years I’ve written C, C++, C#, Java, Perl, and Ruby for the back end all while writing JS 99% of the time for web apps.
I’ve also had co-workers from multiple companies that praise JS like it’s the one true language and all others will wither away.
Overall I feel like it’s ignorance. So many of the “JS or bust” devs I know have only ever touched JS, so maybe it’s a fear of things that are different?
This sounds more like an organizational problem than anything. It seems to imply that the front-end folks think that the back-end guys are moving too slow. That could be the case, or the front-end people don’t have a good handle on what things are easy or difficult on a back end.
Node isn’t a magic bottle, it will make some some things easier, but it’s certainly not a magic “performance scale up”, unless you’re dealing with a truly slow back end.
If you could transverse time backwards, I’d say the pattern would be visible as
“Do you feel Ruby/Python developers are pushing …” “Do you feel Java developers are pushing …”
“Do you feel PHP developers are pushing …” “Do you feel VB developers are pushing …” “Do you feel Delphi developers are pushing …”
There’s not much we can do here other than try to bring different ideas packed in a form different than the language flamewar.
The thing I say to my younglings is that tomorrow they will hate JS, so learn what’s behind it.
It happens with other things, too. I’ve seen people at multiple companies pushing for Java or Kotlin lambdas, some even using the lambda as a full Spring Boot app because they don’t understand what lambdas are or what they’re for.
I know people who only know PHP and so only want to do things in PHP.
The one benefit JS devs really have here is that if you’re doing web-related work, it really helps to know JS. It’s not as odd to ask some non-JS folks to learn a little bit of JS vs non-JS folks asking JS devs to learn Java, Kotlin, PHP, Ruby, whatever else. They’re not as versatile. Just my 2¢.
This is such a generic question that it’s pretty hard to answer. The devil is always in the details. Sure, all of those bullet points that you’ve mentioned are indeed true. But if you’re a front-end engineer, it’s best to use the tools that you’re familiar with in order to express your ideas, because you’re not wrestling with the concepts of a new language or framework in order to prototype your idea into reality. When I’m prototyping an idea, I typically use my favorite language (Ruby) even if it’s not going to be the language that I actually implement the idea in. This is usually a means to an end, I want to show people what something like this could look like. If I get buy-in from my team and/or stakeholders, I’ll develop it using a language or platform better suited for the task. I can imagine that if JS was my favorite language, I’d do the same. But any professional engineer can’t argue with the fact that incorporating that idea into an existing monolith is demonstrably easier to work with.
When faced with a front-end engineer who wants to build a component in Node, perhaps next time you can tell them to make a prototype of their ideas. When that prototype is built and functional, you can then incorporate its ideas into your monolith, which I’m sure is not using JS. That way, your front-end engineers get to work with an API of their own design, and you aren’t up every night debugging performance issues with an unfamiliar platform.
I guess everyone’s an evangelist for whatever stack they use. I see the same behavior with native mobile developers as well. Personally, I just like to use Javascript for as many things as possible, since it’s a universal language almost.
Haven’t really encountered this before. Of course we look at all the options, including some node stuff sometimes. To say it’s happening everywhere or to target the entire js community with a statement like this is quite the generalisation.
NodeJS: let the frontend devs also make the backend
Elixir+Phoenix Live View: let the backend devs also make the frontend
One of these is good, the other is terrible.
I’m sorry but I find that a little elitist. There’s always someone to blame, whether it’s designers, web developers, frontend developers, for some reason we can’t stop pointing the finger at certain groups and saying ‘they’ve ruined everything!’. Don’t get me wrong, things are a mess, but this kind of tribalism isn’t the answer.
This isn’t a comment on the skills of the developers; it’s a critique on the quality and appropriateness of the tooling.
Pretty much how I found myself loving frontend development. Because of Elm, and now Haskell - which is used in frontend and backend.
No, it is necessary in many cases to meet the performance needs expected by many organizations. Generally in these cases, people are using node to render frontends in backend services - not as general backend API. Is this not the cases that you generally are seeing?
JS injection is the new design pattern. Oddly, it’s an anti-pattern by itself.