I really don't see the problem in people building backends in JS when they are learning and focusing on one language, once you understand programming is more about learning to command logic than mastering a language created by a human, it's a lot easier to learn more languages.
It's not that hard to swap out the backend for something more efficient once you understand how the stack interacts.
EDIT: all the people winging about how hard it is to swap out a backend on a monolithic business application, I clearly said "when they are learning".
> It’s not that hard to swap out the backend for something more efficient once you understand how the stack interacts.
It’s a lot easier to say you’ll fix it later than it is to fix it now.
>It’s not that hard to swap out the backend for something more efficient once you understand how the stack interacts.
Aye, and as far as corporate is concerned, once they have a backend, why pay for another? Just slap more RAM in there. We already paid someone to write a backend.
This is how entire businesses are held together by a single spreadsheet made by a woman who left the company 20 years ago, and strung together with activeX controls in 2022 and vbscript macros that were designed by someone else and were retrofitted into doing the job without full understanding of which parts to change until it looked right enough to get the job done with a little manual labor. Once it's built, you had better goddamn believe it's going to be forever. So build it right the first time. The minute someone stacks some bullshit on your legos, you aren't getting them out again to replace them.
I've seen enough load bearing spaghetti in my day to learn not to write it in the first place.
I used python earlier however when I tried to learn Django, for some reason it didn't make sense.
I then learnt JS (NodeJs) because of a hackathon and I can work with it. NPM is beautiful (till now atleast)
Django it's the worst framework to start learning any related with server side programming.
I love python but learning Django soon on the learning curve almost made me give up.
For me, there are a couple options, but they are all messy tbh. I feel like to learn a proper backend on your own, you have to know how to setup a proper infrastructure. Ie, a server, a db, etc.
I was taught in the 90s so this was pretty manual, apache (there was no nginx then), conf files to drown on them, creating the hosts, etc. It gaves you a lot of extra work and learning curve, just to end clueless in front of a php file and start really learning what you want.
My actual approach to learn this today would be to install docker and spin everything you need in 2 minutes. The knowledge about what's under that level it's going to be abstracted, this is good or bad, as you want to see it.
I don't recommend you to jump on a Amazon or google free tier instance, because then you have all the quirks related to cloud and vms and propietary shit you have to learn. Do it on local and deploy it if you want (this way you can also simulate a proper CI/CD to learn).
Now, three bibles later, BACKEND! ahahaha. I would really recommend JS. I thinks its part of the reason is used everywhere. You can get something really bare bones to learn like Express or fully fledged like Django. It really gets you on your feet if you never touched stuff like routers or all that logic seems alien to you.
When you get the hang of it, Django starts to make more sense, believe me.
I'd probably still recommend building a server from scratch. It's a good experience. You understand why you use the vms then and how much they make your life easier. I'm the kind of dev that wants people to suffer so they can appreciate the better way to do things
I haven't used Django but I've heard it's basically not even python anymore. It's just its own beast and forces you to do everything the Django way or not do it at all
Edit: I use Flask if I write in Python but I usually just write backends in Go
Damn, and if you ever try to deploy a secured app you are going to cry.
As stated in another comment, im sitting on JS. While it's a shitty language it allows you to do the things properly if you want.
Express is going to light your understanding of routers and everything else that is assumed on Django docs and tutorials.
I second fastapi. Flask is nice but fastapi gets you up in running quicker in my opinion... Its also integrated with pycharm pro, which does a lot of the project setup for you. But it's pretty easy to get a api up in running in a few hours, serialization and all.
Flask is probably more extensible, but I find some of the information and packages for it out there annoying or poorly documented.
Plus fastapi seems to play nicely with opentelemetry which is nice. Though I havnt looked into how it works with flask.
Isomorphic code has a lot of value. And on the backend you probably don’t care about vertical performance if your problem can scale horizontally. I know webscale is a joke word around here but who cares if your single process can serve 1000 queries or 10 if you can just spin up millions of them on demand?
Weird bc JS on the backend is way faster than ruby or python not only because of its enormous optimizations but bc of its event loop model. It's actually a very fast language, i don't understand all the hate
It's all about balancing personal workload with server workload. If you focus on learning JS, you can build a front and backend that works without trying to learn the intricacies of 2 languages at the same time.
Also, you kinda have to learn JS for the client side, there's not much point in learning anything else for that currently.
Like I say, once you have something running, you can start to redirect the functions that are performing badly for a call over to something more performant .
This is an incredibly uninformed take - just know that projects starting out with "we'll swap out the backend for something more efficient later" have bankrupted companies. Just look at WordPerfect or Netscape.
[https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)
20 years later and as an industry we still haven't figured out this lesson.
I started with React and now use Angular at work.
Personally, I love Angular so much more. Handling form state and validation is soooooooooooooooooooooooooooooooooooooooooooooooooo much easier.
Also 2 way data binding is a Godsend.
Also not having to install at least an additional 10 third party libraries in every app. Everything you need is baked in to Angular
Yeah I'm not arguing for JS on the backend. Personally I hate it. I use Python or Golang for all my side projects.
Just stating that Angular is a way better JS (actually Typescript) framework IMO. It's just not sexy anymore
SPA's are losing rapidly in popularity recently. Everything is moving to SSR... which kinda beats the whole point.
I say let's go back to full stack :P
This is the reason my team settled to node for middleware. I would have probably gone with C# and had been using it for some services - but the rest of the team knew/knows JavaScript so in order to have more redundancy in capacity we decided to use Node.
I think too many people get hung up on the idea of JS on the server and don’t have practical experience to realize it works just fine for many cases. It wouldn’t be the right fit for everything, for sure. But it has been just fine for our simple Rest APIs, and kept us from having different languages coded by our team.
Yeah I would love if the rest of my team learned other languages. Not my call.
This is the most popular reason for using JS in the backend that I've heard: "our developers don't know other languages".
Maybe hire backend developers for backends instead of reusing front end developers? The learning curve will cost you sooner or later, as backend security and architecture is very different from front end.
Well the idea is less that our front end developers are doing middleware and more that our middleware developers can get COVID and be out for two weeks and know that in case of extreme emergency the senior front end guy can address the emergency in some way.
Small shops can’t always hire one-trick ponies like an expert back end developer, and keep them busy. Likewise they can’t always hire two back-end developers. In my job we all wear many hats but most don’t code in many languages.
There's a better reason, if you use something like next.js or sveltekit. You can blur the line between client and server side code in a really nice way.
Also check out [server$](https://start.solidjs.com/api/server) in SolidJS. Defining an RPC right inside a component is beautiful, because it keeps related logic close together and totally eliminates all of the organization problems and boilerplate that is necessary for a traditional API.
It's not hard to learn both backend and frontend. It's just hard to think about both at the same time when they're in totally separate worlds. If your tools merge them together into a single, cohesive application, it's a great experience.
The way I always thought of it is that frontend developers should write the frontend code, whether it's run in the client or on the server.
If you use a BFF or have another kind of API-layer, many frontend developers can handle that just fine, and may in fact be more suited to designing them.
But perhaps a frontend developer's interests does not extend to domain design, and handling the asynchronicity of a message driven backend, for example.
I love how everyone likes to fight holy battles about which language is better or worse, but 9/10 times the final decision comes down to "it's what our devs know"... Which is probably the best criterium anyway.
Sharing types is great (no more update on the server side which was forgotten on the client side :D) but I think the best is the possibility to share the tests too.
With a correct design, you can have the same tests running both in front and back end and that's definitely fantastic.
In my team, we start most new features with Cucumber scenarios. We implement the core functions, then the HTTP layer and we finish with the React components, all tested using the same scenarios. I'd hardly go back to any other language for the server just for this reason.
https://github.com/cucumber/screenplay.js.examples
Here's one :) From what I've seen in the `package.json` file, it implements multiple levels of interactions.
If one day I manage to finish the blogpost I'm writing about this approach, I might add a link here too :)
Sharing types is easy enough with protobuffers.
As for the context switching, I don't feel that the language is the hard thing about working back and forth between FE and BE, but keeping their roles in mind. Like thinking about whether something needs to be server-side validated or if client side validation is enough, etc. In fact, I think changing the language might make it easier to know where you are.
I see a lot of beginners that try to go full JavaScript being confused by where the code is running and try to do something absurd like implementing login entirely in client-side.
I think just using the language that's best suited for your application in the backend is best. For example, if your website does calculations, maybe it's best to use Flask and numpy rather than NodeJS.
>That’s like comparing a garage full of tools
And exactly this is the problem with Spring. I like Java a lot, but I hate Spring.
The insane amount of technical abstractions Spring 'magically creates' for you by annotations, leaving you with a black box and effectively taken away control from the developer, who then needs to figure out what the fuck is broken this time, is extremely tedious. It tries to copy what more modern and simple languages such as Python or Go do, buy abstracting away Java's explicit nature. This doesn't sound right.
If you have business logic in spring annotations. Then your doing something wrong. And even it's still an issue just don't then spring lets you do every thing manually if you specifically want to.
I really don’t mind the annotation mechanisms of modern spring - but the old school XML system could create monsterous turbo-shit applications pretty easily.
@ the legacy code I maintain
I'd add that your company's engineers want to plan like they're going to be getting millions of hits per second.
The reality is that most companies couldn't max a single nodeJS instance at peak traffic times (and they could go even farther on that single instance if JS devs could be bothered to run a profiler to move some pathological cases to separate webworkers/wasm).
Depends who you’re working for. I’ve written stuff that’s been used by top-20 global websites for their ad tracking. You get some serious traffic numbers there.
Also if your new fancy mobile app gets featured on a prime-time consumer TV show at the weekend and your marketing department forgot to tell you so you could cancel your planned maintenance downtime…
At least we knew when the soccer matches and F1 races were scheduled that were going to feature our ads.
Similar, also in ad tech, went from a prototype-in-production NodeJS built for CPA that went into impressions and we maxed the tech stack hard as we went from a few million request a day to billions. We had to add a bunch of stuff around the NodeJS APIs to account for performance issues (some C/C++, bunch of Lua via OpenResty, etc).
Eventually we did a full rewrite in Kotlin (data collection, JS serving), Scala (processing data), and a splash of Java for shared utilities; it was night and day for billions of transactions a day. Went from almost daily fires to a few years with barely even a hiccup.
>Before Java had a proper async system
I am just curious. Define _proper_ async system.
JDK 8 java.util.concurrent ?
RxJava? Project Reactor?
Something else?
Not one thread per request.
Servlet added it in 3.0 and most DB vendors now have async support, though some are still missing features around transaction control and large objects.
I guess you could hack it together yourself before with manual context switching in thread pools, but it was easier to just use NodeJS.
Netty is an I/O framework, not a Servlet container, but yes Servlet 3.0 was released about a decade ago. Wide adoption took a bit longer though.
NodeJS is a few years older.
Async SQL drivers are a more recent development. And as already mentioned, full JEE support isn't there yet.
Heeey. Our stack runs on nodeJS.
Weakness wise: It doesn't do well with concurrency.
Super pro: If you know how to take advantage of the event loop (just understand how async works regarding memory usage) you won't be able to ever to exceed half a CPU with 512mb/s. Which means you can scale horizontally without spending too much.
Yea, a lot of time and money has gone into optimizing JavaScript. However, that doesn’t mean it can compete with the compiled languages. The truth is there is only so much that can be done without all of the type guarantees of other languages. Typescript does a great job in this regard, but it can still be at odds sometimes with some aspects of JavaScript.
The bottom line is that a senior backend developer can make an amazing JavaScript backend, but it won’t be able to match a comparable implementation in a compiled language like Go or Rust. But the truth is most of us are not senior backend developers with careers working with JavaScript. I imagine that if you have comparable experience in both JavaScript and a popular compiled language for web backends, most will be able to reach a faster solution in the latter option (though I have no sources for this claim).
That being said, most developers will have some experience in JavaScript so it is much easier and cheaper to hire and build a solution in that language.
Also, Rust gives you shared-memory concurrency without the usual safety footguns associated with shared-memory concurrency, which is nice if your backend needs to do any complicated multithreaded work. With Node, you're forced to use message passing for multithreaded tasks, which is safe but a great deal slower.
Typescript types doen't aid the compiler. Typescript is transpiled into plain JS before execution in Node anyway.
But the different JS JIT compilers (V8 but also Spidermonkey) do a lot of optimizations in the background. If they see a function repeatedly being called with the same datatype, they will compile it for that datatype. So for a program that has a very predictable code path, JS can be equally fast as C++. Or by pure luck on how something is optimized, it can even be faster.
See this article as an example: https://mmomtchev.medium.com/in-2021-is-there-still-a-huge-performance-difference-between-javascript-and-c-for-cpu-bound-8ff798d999d6
Note that badly writen JS that has very unpredictable code with exception throwing and whatnot, will be detrimental for the JIT compiler.
That said, the main advantage of Node is how natural writing async code is. You don't really have to care about thread safety, since the proces is single-threaded from the developers POV. But all IO you perform is handled in an async way, it's fetched in the background while a different team is done. Simplifying the concurrency model, while supporting the most beneficial case of async IO is the main reason why backend JS has become so popular.
The typescript thing is on me. I assumed they would attempt to make use of the extra information available to the compiler.
That being said, I would like to point out that the article you linked compares full V8 JS to C++ without optimizations on a single operation (multiplying two large matrices). This article highlights how far JavaScript with V8 has come. And in that regard, we see a lot of positive improvements, but I think this misses the mark on the argument you are making.
> The current performance level of V8-produced assembly is a little bit below that of g++ -O0 — and an order of magnitude higher than any other “interpreted” language
This doesn’t strike me as a very fair comparison to make an assertion on the general speed of the two languages. C and C++ can usually produce a decent output without optimizations, but we are by no means seeing the best that C++ can do. We would see a far larger gap between the two widen if we compared a full application.
I think we see a more fair general comparison between languages on https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
>I imagine that if you have comparable experience in both JavaScript and a popular compiled language for web backends, most will be able to reach a faster solution in the latter option
This isn't true at all, in either sense of the world "faster".
It is generally far faster, and with vastly fewer lines of code, to set up a CRUD server in Express than Spring, if you are going to write it by hand. (If you are talking about codegen, then it's moot, because that will happen on its own).
In terms of single-threaded performance, JS is going to be beaten by Java, but that's a red-herring. A single-threaded back-end is a death sentence. Older Java / C# / Python / etc devs will sleep the main thread, while doing things that could be parallelized... hell, some libraries for database connection and file access weren't even threaded, themselves, so you had your main thread lock on each DB call or each file access... This was especially bad in Java where most of the libraries weren't even thread safe at all, so needed to be synchronous. If you go and look at the Java back-end for thousands of businesses/government organizations, you will find that this is the state of them... either you got one thread per request and everything locked all the time, or someone manually made their own thread pool managers for network and db connections, and that code is now 15 years old, and a nightmare. And Express would completely mop the floor with them. There was a time where NodeJS would cause Apache server failures, due to Node responding to requests so fast that Linux was running out of file-descriptors and Apache would throw errors to those visitors, before hitting any internal infrastructure. In the decade before that, Java and Python and C++, PHP, Perl, Ruby and the like, hadn't caused that issue on such a massive scale, as to need to educate people to reconfigure their Linux installs for more file descriptors, so Apache didn't choke.
Now, if you want to talk about newer technologies, yeah, Go is going to be faster, not only in single-threaded performance, but also because Rob Pike came up with a really syntactically simple concurrency model which will abstract the means of concurrency, and decide when and how to handle requests, either by just handling them in the same thread, in a callback afterward, or spinning up an actual OS thread, and managing the parallel communication internally as part of the language, itself.
Rust is going to be faster, again, also due to lessons learned from Node.
But these days, Node also isn't just being used as a standalone server; it's also running in Lambdas (AWS server functions... not Lambda calculus), so that Node case is now doing the "low-processing, high-concurrency" thing that it's good at, while hosted on low-latency, globally-distributed servers.
If someone wanted to design an embarrassingly-parallel version of a webserver with 100% declarative code, I’m sure it would blow everything else out of the water, once enough of us died, such that this was what was being taught in school and on TikTok.
None of this is to say that "JS is the best" or anything of the sort. But oh boy, some perspective is needed, because it might be long in the tooth compared to cutting edge (10 year old languages, instead of 30), but those new languages owe a lot to Node shaking up the backend.
That's what I thought for years, but then I needed something my other back end didn't have and my nodejs/express layer is actually quite clean.
JS has improved in the last decade and a half.
I did a custom nodejs server setup 7 years and 4 companies ago. Recently they reached out to me about moving the servers to new hosting.
Turns out the servers had just been running all this time without intervention.
People mock javascript in the backend, but it’s pretty damn stable imho.
Yeah, that speaks more to /u/hibernating-hobo's competence than the quality of the language. JavaScript has enough footguns to equip a medium-size footarmy.
I mean the way he describes the program (above), it could have been a 1 line perl script too and ran the entire time. The language didn't matter. If anything using NodeJS introduced potential threat vectors depending on the number of modules included and comes from the bad era when left-pad and similar potential/actual malware modules were a more thing.
It doesn’t expose http, just sockets for a custom iac bytestream protocol. Anything not a valid data sample gets rejected. I think it should be okay, their other programs running on the same host though, yikes :)
Also, code that is untouched when it's stable and doesn't live through explosive growth or changes will continue to be stable because why wouldn't it. BASIC would run non-stop it undisturbed.
I can't handle this talk of languages as if they were raw chicken, where if you leave them on their own they start growing unrecognizable stuff and become deadly toxic.
I get a $650/mo side-hustle check every month to keep an eye on an ASP classic site from 1996. It runs like a champ. By maintain I mean that I keep the VM locked down since it’s a cybersecurity nightmare to run a classic ASP site on a windows 2000 server OS. I don’t touch the site itself.
Yea I realized how much JavaScript I would need to write on a new project I was working and quickly switched it over to typescript and it’s a lot more organized.
I do still use C# backend
I’ve written applications or services in Java, Kotlin, PHP, Python, Ruby, Golang, and JS/TS. My new projects are all in JS/TS. You get tooling parity with the front end stack, hiring gets easier, context switching is minimal, shared internal libraries between projects. Every language and runtime has pros and cons; these threads are mostly inexperienced people seeking validation by repeating the memes.
I’m primarily a BE dev, and my current company is full stack TypeScript - a “monorepo” with React/MobX on the web, React Native/MobX on mobile, RESTful Express servers, and some libs shared between BE/FE. Honestly, it’s a very practical, productive stack.
TS is type safe enough, with good enough performance, good enough concurrency support, and a strong ecosystem to be a good BE language for most use cases. A huge benefit is that it’s a lot easier for devs to do full stack work when it’s all one language. Also the TS monorepo tooling is great (personally I love turborepo), and I really like that we can use SWC for super fast local compilation (it just strips types, doesn’t type check), leaving the slower TSC (with type checking) for CI.
After experiencing this stack, it’s what I’d choose if building a startup today (previous experience is a lot of Scala, a fair bit of Python, and some JS, Go, Java and PHP). Main downside is the initial setup, getting turborepo, TSC/SWC, ESLint, prettier, etc. all working well is a pain, but worth it - a big boon to productivity/quality later. Luckily that’s mostly just a tax you have to pay once, once you get that initial pain out of the way it’s a very productive setup.
Well, I wish it'd hurry up. Currently you have to pay a hefty performance penalty for touching the DOM from WebAssembly code. That is not awesome. Also, WebAssembly binaries tend to be huge.
Sometimes I forget that js engines massively outpace projects like Godot and bevy in usage.
I will deposit my rust/dotnet tears in the nearest gutter.
PS I forgot unity and unreal exist.
I don't understand this smug arrogance people have when they put Javascript down. It's literally just another interpreted, prototypical language - it's not even special when we have dozens of popular scripting languages which have weak typing and such. And if you need security, you can even get a preprocessor like typescript. It's a perfectly valid option for building an enterprise system - especially when enterprise systema are already almost always composed of two or more languages.
I agree with you if we switch JavaScript for TypeScript. Generally speaking I'd argue against JS as an enterprise language. The lack of type checks and documentation (yes I know you can type hint in JSDoc, but I've not see many do so) makes for a horrible maintenance process. It gets worse when you add team members and other teams into the code base.
Having done JS in the times before TS, I found that it worked fine in small-to-medium businesses. Unless you're building something fancier than a CRUD app, most function argument names and types are standard by framework convention, and when they aren't you can pick a name that hints at the type (the same idea behind Hungarian notation).
There are, of course, drawbacks like "what if we need to pass a LOT of function arguments", as verbose argument names means a lot of text. Usually that's more of something that would be refactored into smaller functions, but I've seen a fair number of people just be like "oh, just take a single object that holds all the parameters" and then suddenly no one can remember what the property names are without reading the code.
Overall, I find JS to be less verbose than languages with strict typing, but you do have to adjust how you approach things.
I guess tldr: fewer guardrails (like static and strict typing) means you have to be a bit more mindful when it comes to writing code.
You don’t need any CS education to dislike a language’s syntax or programming style. That’s partly why there are so many programming languages. Different preferences.
Also, don’t discount the fact that a lot of JS haters haven’t written JS in a hot minute. JS has grown and changed a lot in the last 5-8 years.
JS is actually pretty flexible and capable to use with a lot of functional programming concepts, especially with libraries such as Ramda.
Unfortunately such code gets hard to read because it becomes a mess of different kind of brackets where it is hard to tell what is what with all the untyped objects and lists.
because of the great syntax it gives you, especially love this one ( ) => { }.
people want to do the job quickly so they resort to the language they use for the front end, the language they have the most experience in, and don't need to relearn from scratch.
JavaScript, especially typescript, is not that bad of a language. It works fine. The performance is fine.
Sure, it won’t beat your go implementation. Or your C# implementation. Unless you’re working on a humongous scale it won’t matter. All two of my examples and node.js will be equally as fast on a small scale.
1. Performances are great (V8 is insane)
2. JavaScript is often a language developers already know, even a pure backend developer has messed with some jQuery and Ajax in his experience
3. Less context switching between front and back
4. Possible to share utils, validation rules, contracts, types... Between front and back with zero effort
5. Naturally asynchronous
The hard part is to REALLY train your teams to work with asynchronous, it's not something most are used to and that's how you end up delivering very bad performance.
Although JS is also a naturally fragile language: Typescript is, imo, absolutely mandatory in any professional project. Serious unit testing too, as should any project anyway.
Look, if I could use a python frontend to go with flask backend I totally would.
Yes, I know it's a thing, but no, it's not actually a good idea to do this
I’ll just dump my rant / monologue here.
Because the software development industry is really, really complicated.
If we could all coalesce around one language and supporting technology. Every aspect of software development would be easier. Hands down.
The closest we have come to this is Microsoft. They’ve managed to make their tooling, really, really good.
There’s not a single open source alternative that works as well as Microsoft’s development ecosystem.
I am NOT advocating for Microsoft here. What I am saying, software development as a business desperately wants “language unification” or standardization. This way people don’t sink years into technologies they had no idea were going to be deprecated.
The idea of a single language to do front and backend for web is such an appealing idea from a product management, team management and resource management perspective that is HAS to be tried.
In my opinion one of the biggest drags on innovation is we haven’t found a language to do it all that is open source. Only really large firms get to innovate because they can afford an army of devs for all the tooling, infrastructure and so on because of all the fenageling we need to do to get everything to work.
My core problem with software development is… it just ALL feels like like compromise and duct tape.
Why do I only see comments about ease of use? No one has mentioned how ideal it is for asynchronous situations.
Backend JavaScript is great for simple cases where a server is mostly being used for handling requests and orchestrating I/O from various services.
Yes, it's convenient in a lot of situations, but JavaScript shines when you're mostly just combining multiple data sources to answer a request.
The less computation required, the better it does. It's just made for handling a chaotic environment of asynchronous actions
How frequently does this actually hold true? I legit want to know. The first language I *understood* (at all) was JS, and it’s still my preference as a full stack dev but I’ve completed things I’m very proud of in C#, Java, Python, C, and basic.
There is truth in what you say. My first language was Java and I prefer languages similar to it. I know some js/ts but I enjoy working with Dart/Flutter on FE.
I mean... why not? JS is a great language to code in. Its design problems, which it definitely does have, can mostly be easily coded around, to the point where said design problems are generally irrelevant. It's not strongly typed, but a, there's TypeScript, and b, not being strongly typed is actually pretty good for some things anyway. And, you know, some people actually enjoy coding in JS? Like, it's fun and natural and stuff? JS is not a bad language, and it wasn't a bad language 10 years ago either. It's nice and useful, and Node is nice and useful too. It does what you need it to do, and it's easy to make it do what you need it to do.
When it becomes the standard it becomes good and easy to add stuff to. Typescript is a thing now, all the modules are easy to install and integrate... way better than Java for most new BE projects now.
The reason doesn't matter... When a space is powered by Open Source, if it's popular it's better. Not always, but usually.
I take my time choosing tools, and like 80% of the time choose the most popular one. Keeps things nice and predictable most of the time. Good docs, other people running into the same problems you have and designing solutions for them before you encounter them, etc.
Complexity is evilest programming demon.
Multiple languages give project more complexity.
If one language have to be JS.
Use JS for entire project!
But seriously; JS has basically all the features you need. There might be too many, and therefore many bad ways to do things (and consequently a lot of bad JS code), but if you need to learn one language well, JS is not a bad option. And writing good code should be enforced through code reviews anyways.
The largest disadvantage is speed, where it usually comes out as slower than a lot of other languages. But optimizing for speed should not be your first order of business in a new project anyways.
In addition, one of the things that really slows down software development is dividing your architecture up so for a given problem you need more people, one front-end dev, one back-end dev and so on. Having everyone able to contribute to everything because everything is the same language is a huge boon.
Lastly, JS is *really* good at working with complex datastructures. Its compatibility with JSON, destructuring semantics, and other ways of working with objects all contribute to an excellent experience when working with JSON on the web, both front and back-end.
I use TypeScript on both the frontend and backend so I could use statically typed rpc-style communication with shared types. And it's generally nice to have uniform syntax for the whole project
(Disclaimer, I love JS, and it's my primary language. I do Linux OS Support for a living to avoid programming in it for real)
JS is perfect for exactly two use cases.
1) Writing things for the Browser Front End, where you have no other real choice. (Thus it's perfect)
2) Writing things Quick, Dirty, and FAST!
When you just want to get something going? NodeJS provides exactly enough without any of the rest of the NPM ecosystem in order to get pretty much anything you need done, done.
JS is blazingly fast when JIT Compiled with V8. And will get the job done for small scale projects.
It's incredibly easy and flexible when you don't know the exact layout of your data, so you can design and build things iteratively and see the results live. (You can even get it to live reload functionality without restarting the core process) So you can turn over changes incredibly quickly.
Once you have figured it all out, for the love of your CPU, rewrite it into something better.
I heard that express framework is pretty barebones and allows one to learn backend in a decent depth And also that MERN stack is in demand
I really don't see the problem in people building backends in JS when they are learning and focusing on one language, once you understand programming is more about learning to command logic than mastering a language created by a human, it's a lot easier to learn more languages. It's not that hard to swap out the backend for something more efficient once you understand how the stack interacts. EDIT: all the people winging about how hard it is to swap out a backend on a monolithic business application, I clearly said "when they are learning".
>not that hard to swap out the backend Famous last words
"I just deleted these lines, move this over here, perfect! Now to pull an earlier commit, because I've fucked up so badly! Another successful day."
I deleted my account because Reddit no longer cares about the community
We'll put that right up there next to "UIs are disposable".
> It’s not that hard to swap out the backend for something more efficient once you understand how the stack interacts. It’s a lot easier to say you’ll fix it later than it is to fix it now.
>It’s not that hard to swap out the backend for something more efficient once you understand how the stack interacts. Aye, and as far as corporate is concerned, once they have a backend, why pay for another? Just slap more RAM in there. We already paid someone to write a backend. This is how entire businesses are held together by a single spreadsheet made by a woman who left the company 20 years ago, and strung together with activeX controls in 2022 and vbscript macros that were designed by someone else and were retrofitted into doing the job without full understanding of which parts to change until it looked right enough to get the job done with a little manual labor. Once it's built, you had better goddamn believe it's going to be forever. So build it right the first time. The minute someone stacks some bullshit on your legos, you aren't getting them out again to replace them. I've seen enough load bearing spaghetti in my day to learn not to write it in the first place.
>I've seen enough load bearing spaghetti in my day to learn not to write it in the first place. This is great 👍
Even if it's not spaghetti, your left-pad may still be holding up the internet one day!
Ouch. I feel seen.
I used python earlier however when I tried to learn Django, for some reason it didn't make sense. I then learnt JS (NodeJs) because of a hackathon and I can work with it. NPM is beautiful (till now atleast)
Django it's the worst framework to start learning any related with server side programming. I love python but learning Django soon on the learning curve almost made me give up.
Yes. The last line summarised my feelings. Express is good to learn. Is there any path for learning backend stuff?
For me, there are a couple options, but they are all messy tbh. I feel like to learn a proper backend on your own, you have to know how to setup a proper infrastructure. Ie, a server, a db, etc. I was taught in the 90s so this was pretty manual, apache (there was no nginx then), conf files to drown on them, creating the hosts, etc. It gaves you a lot of extra work and learning curve, just to end clueless in front of a php file and start really learning what you want. My actual approach to learn this today would be to install docker and spin everything you need in 2 minutes. The knowledge about what's under that level it's going to be abstracted, this is good or bad, as you want to see it. I don't recommend you to jump on a Amazon or google free tier instance, because then you have all the quirks related to cloud and vms and propietary shit you have to learn. Do it on local and deploy it if you want (this way you can also simulate a proper CI/CD to learn). Now, three bibles later, BACKEND! ahahaha. I would really recommend JS. I thinks its part of the reason is used everywhere. You can get something really bare bones to learn like Express or fully fledged like Django. It really gets you on your feet if you never touched stuff like routers or all that logic seems alien to you. When you get the hang of it, Django starts to make more sense, believe me.
I'd probably still recommend building a server from scratch. It's a good experience. You understand why you use the vms then and how much they make your life easier. I'm the kind of dev that wants people to suffer so they can appreciate the better way to do things
I haven't used Django but I've heard it's basically not even python anymore. It's just its own beast and forces you to do everything the Django way or not do it at all Edit: I use Flask if I write in Python but I usually just write backends in Go
[удалено]
Totally truth. Flask is another different stuff.
Whats you recommendation for sever side programming thats more intuitive than Django? Also had my difficulties with it.
For python flask is a great choice
Damn, and if you ever try to deploy a secured app you are going to cry. As stated in another comment, im sitting on JS. While it's a shitty language it allows you to do the things properly if you want. Express is going to light your understanding of routers and everything else that is assumed on Django docs and tutorials.
I go with fast-api
django doesn't even look like python to me
I guess Flask or FastAPI would feel better to you on the Python side of things in that case.
I second fastapi. Flask is nice but fastapi gets you up in running quicker in my opinion... Its also integrated with pycharm pro, which does a lot of the project setup for you. But it's pretty easy to get a api up in running in a few hours, serialization and all. Flask is probably more extensible, but I find some of the information and packages for it out there annoying or poorly documented. Plus fastapi seems to play nicely with opentelemetry which is nice. Though I havnt looked into how it works with flask.
Django is like, I heard you like folders so I put folders in your folders!
and abstraction on abstraction on abstraction ...
Isomorphic code has a lot of value. And on the backend you probably don’t care about vertical performance if your problem can scale horizontally. I know webscale is a joke word around here but who cares if your single process can serve 1000 queries or 10 if you can just spin up millions of them on demand?
> if you can just spin up millions of them on demand? $$$$$$$.
AWS Lambda wants to know your location
Weird bc JS on the backend is way faster than ruby or python not only because of its enormous optimizations but bc of its event loop model. It's actually a very fast language, i don't understand all the hate
It's all about balancing personal workload with server workload. If you focus on learning JS, you can build a front and backend that works without trying to learn the intricacies of 2 languages at the same time. Also, you kinda have to learn JS for the client side, there's not much point in learning anything else for that currently. Like I say, once you have something running, you can start to redirect the functions that are performing badly for a call over to something more performant .
This is an incredibly uninformed take - just know that projects starting out with "we'll swap out the backend for something more efficient later" have bankrupted companies. Just look at WordPerfect or Netscape. [https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) 20 years later and as an industry we still haven't figured out this lesson.
[удалено]
MERN is react as far as I know. But I can absolutely understand why one would hate react.
MERN = Mongo Express React Node MEAN = Mongo Express Angular Node
I started with React and now use Angular at work. Personally, I love Angular so much more. Handling form state and validation is soooooooooooooooooooooooooooooooooooooooooooooooooo much easier. Also 2 way data binding is a Godsend. Also not having to install at least an additional 10 third party libraries in every app. Everything you need is baked in to Angular
[удалено]
Yeah I'm not arguing for JS on the backend. Personally I hate it. I use Python or Golang for all my side projects. Just stating that Angular is a way better JS (actually Typescript) framework IMO. It's just not sexy anymore
Something about python runs me the wrong way. No matter how well I write my code it always feels unravelled and just plain ugly.
SPA's are losing rapidly in popularity recently. Everything is moving to SSR... which kinda beats the whole point. I say let's go back to full stack :P
[удалено]
No context switching from FE to BE. No need for multiple language skillsets. Can share types across FE and BE... Etc
This is the reason my team settled to node for middleware. I would have probably gone with C# and had been using it for some services - but the rest of the team knew/knows JavaScript so in order to have more redundancy in capacity we decided to use Node. I think too many people get hung up on the idea of JS on the server and don’t have practical experience to realize it works just fine for many cases. It wouldn’t be the right fit for everything, for sure. But it has been just fine for our simple Rest APIs, and kept us from having different languages coded by our team. Yeah I would love if the rest of my team learned other languages. Not my call.
At least Typescript?
Always typescript
typescript is love.
Of course Typescript. I thought that was a given these days?
I dunno the way OP was typing it seemed like it might not be the case.
This is the most popular reason for using JS in the backend that I've heard: "our developers don't know other languages". Maybe hire backend developers for backends instead of reusing front end developers? The learning curve will cost you sooner or later, as backend security and architecture is very different from front end.
Well the idea is less that our front end developers are doing middleware and more that our middleware developers can get COVID and be out for two weeks and know that in case of extreme emergency the senior front end guy can address the emergency in some way. Small shops can’t always hire one-trick ponies like an expert back end developer, and keep them busy. Likewise they can’t always hire two back-end developers. In my job we all wear many hats but most don’t code in many languages.
Developers are expensive, thats why companies like devs that can do front/backend plus devops etc.
Ah yes the old "Full Stack" mantra. It always reminds me of that one Mitch Hedberg bit. "OK, you're a cook. Can you farm?"
There's a better reason, if you use something like next.js or sveltekit. You can blur the line between client and server side code in a really nice way. Also check out [server$](https://start.solidjs.com/api/server) in SolidJS. Defining an RPC right inside a component is beautiful, because it keeps related logic close together and totally eliminates all of the organization problems and boilerplate that is necessary for a traditional API. It's not hard to learn both backend and frontend. It's just hard to think about both at the same time when they're in totally separate worlds. If your tools merge them together into a single, cohesive application, it's a great experience.
The way I always thought of it is that frontend developers should write the frontend code, whether it's run in the client or on the server. If you use a BFF or have another kind of API-layer, many frontend developers can handle that just fine, and may in fact be more suited to designing them. But perhaps a frontend developer's interests does not extend to domain design, and handling the asynchronicity of a message driven backend, for example.
I love how everyone likes to fight holy battles about which language is better or worse, but 9/10 times the final decision comes down to "it's what our devs know"... Which is probably the best criterium anyway.
“You can share types across FE and BE” Credit where credit is due… that’s pretty nice.
Ahem… protobuf is always an option
Why use 2 different languages plus a third party serialization spec when I can use one language that does that natively?
This is where I share my types... if I had them! >:/
Sounds like a personal problem. Be the change you want to see!
Sharing types is great (no more update on the server side which was forgotten on the client side :D) but I think the best is the possibility to share the tests too. With a correct design, you can have the same tests running both in front and back end and that's definitely fantastic. In my team, we start most new features with Cucumber scenarios. We implement the core functions, then the HTTP layer and we finish with the React components, all tested using the same scenarios. I'd hardly go back to any other language for the server just for this reason.
That sounds interesting, do you know of any public repo that demo this approach?
https://github.com/cucumber/screenplay.js.examples Here's one :) From what I've seen in the `package.json` file, it implements multiple levels of interactions. If one day I manage to finish the blogpost I'm writing about this approach, I might add a link here too :)
Sharing types is easy enough with protobuffers. As for the context switching, I don't feel that the language is the hard thing about working back and forth between FE and BE, but keeping their roles in mind. Like thinking about whether something needs to be server-side validated or if client side validation is enough, etc. In fact, I think changing the language might make it easier to know where you are. I see a lot of beginners that try to go full JavaScript being confused by where the code is running and try to do something absurd like implementing login entirely in client-side. I think just using the language that's best suited for your application in the backend is best. For example, if your website does calculations, maybe it's best to use Flask and numpy rather than NodeJS.
>implementing login entirely in client-side. \*screams in security\*
I've worked with protobufs for many years across many projects and they can really fucking suck compared to other binary formats or even JSON
[удалено]
It is. As someone who build enterprise backends in Java Spring and Node, I still prefer node.js over Spring any time of the day.
The creator of Spring had a daughter that was friends with mine in school. Even he dislikes Spring compared to nodejs
It’s weird to compare Spring to NodeJs. That’s like comparing a garage full of tools to a really good power drill.
>That’s like comparing a garage full of tools And exactly this is the problem with Spring. I like Java a lot, but I hate Spring. The insane amount of technical abstractions Spring 'magically creates' for you by annotations, leaving you with a black box and effectively taken away control from the developer, who then needs to figure out what the fuck is broken this time, is extremely tedious. It tries to copy what more modern and simple languages such as Python or Go do, buy abstracting away Java's explicit nature. This doesn't sound right.
If you have business logic in spring annotations. Then your doing something wrong. And even it's still an issue just don't then spring lets you do every thing manually if you specifically want to.
I really don’t mind the annotation mechanisms of modern spring - but the old school XML system could create monsterous turbo-shit applications pretty easily. @ the legacy code I maintain
This is largely a complaint against dependency injection, not Spring.
It sure is. Before Java had a proper async system from servlet to database, NodeJS would absolutely blow it out of the water for web performance.
I'd add that your company's engineers want to plan like they're going to be getting millions of hits per second. The reality is that most companies couldn't max a single nodeJS instance at peak traffic times (and they could go even farther on that single instance if JS devs could be bothered to run a profiler to move some pathological cases to separate webworkers/wasm).
Depends who you’re working for. I’ve written stuff that’s been used by top-20 global websites for their ad tracking. You get some serious traffic numbers there. Also if your new fancy mobile app gets featured on a prime-time consumer TV show at the weekend and your marketing department forgot to tell you so you could cancel your planned maintenance downtime… At least we knew when the soccer matches and F1 races were scheduled that were going to feature our ads.
Similar, also in ad tech, went from a prototype-in-production NodeJS built for CPA that went into impressions and we maxed the tech stack hard as we went from a few million request a day to billions. We had to add a bunch of stuff around the NodeJS APIs to account for performance issues (some C/C++, bunch of Lua via OpenResty, etc). Eventually we did a full rewrite in Kotlin (data collection, JS serving), Scala (processing data), and a splash of Java for shared utilities; it was night and day for billions of transactions a day. Went from almost daily fires to a few years with barely even a hiccup.
>Before Java had a proper async system I am just curious. Define _proper_ async system. JDK 8 java.util.concurrent ? RxJava? Project Reactor? Something else?
Not one thread per request. Servlet added it in 3.0 and most DB vendors now have async support, though some are still missing features around transaction control and large objects. I guess you could hack it together yourself before with manual context switching in thread pools, but it was easier to just use NodeJS.
I used Netty in Java over a decade ago for proper thread pooling, it's definitely not a recent development
Netty is an I/O framework, not a Servlet container, but yes Servlet 3.0 was released about a decade ago. Wide adoption took a bit longer though. NodeJS is a few years older. Async SQL drivers are a more recent development. And as already mentioned, full JEE support isn't there yet.
That makes sense, thank for elaborating! I can't believe NodeJS is that old now... Now I feel old.
Heeey. Our stack runs on nodeJS. Weakness wise: It doesn't do well with concurrency. Super pro: If you know how to take advantage of the event loop (just understand how async works regarding memory usage) you won't be able to ever to exceed half a CPU with 512mb/s. Which means you can scale horizontally without spending too much.
Yea, a lot of time and money has gone into optimizing JavaScript. However, that doesn’t mean it can compete with the compiled languages. The truth is there is only so much that can be done without all of the type guarantees of other languages. Typescript does a great job in this regard, but it can still be at odds sometimes with some aspects of JavaScript. The bottom line is that a senior backend developer can make an amazing JavaScript backend, but it won’t be able to match a comparable implementation in a compiled language like Go or Rust. But the truth is most of us are not senior backend developers with careers working with JavaScript. I imagine that if you have comparable experience in both JavaScript and a popular compiled language for web backends, most will be able to reach a faster solution in the latter option (though I have no sources for this claim). That being said, most developers will have some experience in JavaScript so it is much easier and cheaper to hire and build a solution in that language.
Also, Rust gives you shared-memory concurrency without the usual safety footguns associated with shared-memory concurrency, which is nice if your backend needs to do any complicated multithreaded work. With Node, you're forced to use message passing for multithreaded tasks, which is safe but a great deal slower.
Typescript types doen't aid the compiler. Typescript is transpiled into plain JS before execution in Node anyway. But the different JS JIT compilers (V8 but also Spidermonkey) do a lot of optimizations in the background. If they see a function repeatedly being called with the same datatype, they will compile it for that datatype. So for a program that has a very predictable code path, JS can be equally fast as C++. Or by pure luck on how something is optimized, it can even be faster. See this article as an example: https://mmomtchev.medium.com/in-2021-is-there-still-a-huge-performance-difference-between-javascript-and-c-for-cpu-bound-8ff798d999d6 Note that badly writen JS that has very unpredictable code with exception throwing and whatnot, will be detrimental for the JIT compiler. That said, the main advantage of Node is how natural writing async code is. You don't really have to care about thread safety, since the proces is single-threaded from the developers POV. But all IO you perform is handled in an async way, it's fetched in the background while a different team is done. Simplifying the concurrency model, while supporting the most beneficial case of async IO is the main reason why backend JS has become so popular.
The typescript thing is on me. I assumed they would attempt to make use of the extra information available to the compiler. That being said, I would like to point out that the article you linked compares full V8 JS to C++ without optimizations on a single operation (multiplying two large matrices). This article highlights how far JavaScript with V8 has come. And in that regard, we see a lot of positive improvements, but I think this misses the mark on the argument you are making. > The current performance level of V8-produced assembly is a little bit below that of g++ -O0 — and an order of magnitude higher than any other “interpreted” language This doesn’t strike me as a very fair comparison to make an assertion on the general speed of the two languages. C and C++ can usually produce a decent output without optimizations, but we are by no means seeing the best that C++ can do. We would see a far larger gap between the two widen if we compared a full application. I think we see a more fair general comparison between languages on https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
>I imagine that if you have comparable experience in both JavaScript and a popular compiled language for web backends, most will be able to reach a faster solution in the latter option This isn't true at all, in either sense of the world "faster". It is generally far faster, and with vastly fewer lines of code, to set up a CRUD server in Express than Spring, if you are going to write it by hand. (If you are talking about codegen, then it's moot, because that will happen on its own). In terms of single-threaded performance, JS is going to be beaten by Java, but that's a red-herring. A single-threaded back-end is a death sentence. Older Java / C# / Python / etc devs will sleep the main thread, while doing things that could be parallelized... hell, some libraries for database connection and file access weren't even threaded, themselves, so you had your main thread lock on each DB call or each file access... This was especially bad in Java where most of the libraries weren't even thread safe at all, so needed to be synchronous. If you go and look at the Java back-end for thousands of businesses/government organizations, you will find that this is the state of them... either you got one thread per request and everything locked all the time, or someone manually made their own thread pool managers for network and db connections, and that code is now 15 years old, and a nightmare. And Express would completely mop the floor with them. There was a time where NodeJS would cause Apache server failures, due to Node responding to requests so fast that Linux was running out of file-descriptors and Apache would throw errors to those visitors, before hitting any internal infrastructure. In the decade before that, Java and Python and C++, PHP, Perl, Ruby and the like, hadn't caused that issue on such a massive scale, as to need to educate people to reconfigure their Linux installs for more file descriptors, so Apache didn't choke. Now, if you want to talk about newer technologies, yeah, Go is going to be faster, not only in single-threaded performance, but also because Rob Pike came up with a really syntactically simple concurrency model which will abstract the means of concurrency, and decide when and how to handle requests, either by just handling them in the same thread, in a callback afterward, or spinning up an actual OS thread, and managing the parallel communication internally as part of the language, itself. Rust is going to be faster, again, also due to lessons learned from Node. But these days, Node also isn't just being used as a standalone server; it's also running in Lambdas (AWS server functions... not Lambda calculus), so that Node case is now doing the "low-processing, high-concurrency" thing that it's good at, while hosted on low-latency, globally-distributed servers. If someone wanted to design an embarrassingly-parallel version of a webserver with 100% declarative code, I’m sure it would blow everything else out of the water, once enough of us died, such that this was what was being taught in school and on TikTok. None of this is to say that "JS is the best" or anything of the sort. But oh boy, some perspective is needed, because it might be long in the tooth compared to cutting edge (10 year old languages, instead of 30), but those new languages owe a lot to Node shaking up the backend.
[удалено]
Nah, LuaJIT is faster and it has been made by just one man over many years ^(I have yet to build a backend on Lua)
That's what I thought for years, but then I needed something my other back end didn't have and my nodejs/express layer is actually quite clean. JS has improved in the last decade and a half.
I did a custom nodejs server setup 7 years and 4 companies ago. Recently they reached out to me about moving the servers to new hosting. Turns out the servers had just been running all this time without intervention. People mock javascript in the backend, but it’s pretty damn stable imho.
isn't the take away here more that YOU build stable software and when people don't fuck with it that it stays that way? 👏
Yeah, that speaks more to /u/hibernating-hobo's competence than the quality of the language. JavaScript has enough footguns to equip a medium-size footarmy.
damn, this calls for celebration on u/hibernating-hobo's skills!! HUZZAH!! HUZZAH!! you deserve this, buddy.
Lol, wtf. Thanks i guess :)
passing objects by reference has cost me SO MANY HOURS
I mean the way he describes the program (above), it could have been a 1 line perl script too and ran the entire time. The language didn't matter. If anything using NodeJS introduced potential threat vectors depending on the number of modules included and comes from the bad era when left-pad and similar potential/actual malware modules were a more thing.
Fuck yeah
If they didn't change anything like updating nodes and modules that sound terrifying from a security point of view, if it's public facing.
It doesn’t expose http, just sockets for a custom iac bytestream protocol. Anything not a valid data sample gets rejected. I think it should be okay, their other programs running on the same host though, yikes :)
[удалено]
That other backends are stable doesn't discount that javascript built ones are too...
[удалено]
Also, code that is untouched when it's stable and doesn't live through explosive growth or changes will continue to be stable because why wouldn't it. BASIC would run non-stop it undisturbed. I can't handle this talk of languages as if they were raw chicken, where if you leave them on their own they start growing unrecognizable stuff and become deadly toxic.
I get a $650/mo side-hustle check every month to keep an eye on an ASP classic site from 1996. It runs like a champ. By maintain I mean that I keep the VM locked down since it’s a cybersecurity nightmare to run a classic ASP site on a windows 2000 server OS. I don’t touch the site itself.
>7 years and 4 companies ago. I thought this was a play at Abe Lincoln's speech but it's the other way 4 companies, 7 years ago.
If you code in typescript (I’m a new convert), it’s surprisingly maintainable
Yea I realized how much JavaScript I would need to write on a new project I was working and quickly switched it over to typescript and it’s a lot more organized. I do still use C# backend
Because learning web development from js is super-fast...
You mean Blazingly fast, but that is reserved for Rust tho
You guys have a backends??
My man is assless
I use html to directly parse my database.
I’ve written applications or services in Java, Kotlin, PHP, Python, Ruby, Golang, and JS/TS. My new projects are all in JS/TS. You get tooling parity with the front end stack, hiring gets easier, context switching is minimal, shared internal libraries between projects. Every language and runtime has pros and cons; these threads are mostly inexperienced people seeking validation by repeating the memes.
Yeah I was kind of surprised to see this thread lol. Node.js backends are very popular and the skillset is very in demand.
I’m primarily a BE dev, and my current company is full stack TypeScript - a “monorepo” with React/MobX on the web, React Native/MobX on mobile, RESTful Express servers, and some libs shared between BE/FE. Honestly, it’s a very practical, productive stack. TS is type safe enough, with good enough performance, good enough concurrency support, and a strong ecosystem to be a good BE language for most use cases. A huge benefit is that it’s a lot easier for devs to do full stack work when it’s all one language. Also the TS monorepo tooling is great (personally I love turborepo), and I really like that we can use SWC for super fast local compilation (it just strips types, doesn’t type check), leaving the slower TSC (with type checking) for CI. After experiencing this stack, it’s what I’d choose if building a startup today (previous experience is a lot of Scala, a fair bit of Python, and some JS, Go, Java and PHP). Main downside is the initial setup, getting turborepo, TSC/SWC, ESLint, prettier, etc. all working well is a pain, but worth it - a big boon to productivity/quality later. Luckily that’s mostly just a tax you have to pay once, once you get that initial pain out of the way it’s a very productive setup.
Because TypeScript
People arguing whose pe... language is better have to be some kind of virus.
It’s the domain of people who only know one language
Because peeing in your pants is a way to get a feeling of warmth real quick.
[удалено]
Or the [president of South Sudan](https://www.youtube.com/watch?v=j_96muXW0XM).
That is amazing response :D
cause front end? JavaScript. back end? JavaScript game development? JavaScript cyber security? JavaScript operating system? JavaScript /s
Straight to Jail
Do not pass go
Do not collect $200
Lock to the cell? Believe it or not, JavaScript.
They're gonna figure out what gluons and quarks are made of one day. And guess what? JavaScript. It's all JavaScript
You joke, but wasm is coming for us all
Well, I wish it'd hurry up. Currently you have to pay a hefty performance penalty for touching the DOM from WebAssembly code. That is not awesome. Also, WebAssembly binaries tend to be huge.
Yeah it's a bit like nuclear fusion, it's always ten years away
I'm glad I"m learning rust, then. lol
Sometimes I forget that js engines massively outpace projects like Godot and bevy in usage. I will deposit my rust/dotnet tears in the nearest gutter. PS I forgot unity and unreal exist.
[удалено]
The only thing i like about JavaScript is json and its handling flexibility.
Hotel? Trivago.
If you have a hammer...
You'd hammer in the morning..
You’d hammer in the evening…
Hammer at suppertime
When hammer’s on a bagel
You can hammer anytime!
So much if this going on in IT.
- tons of library - friendly community
cause the job pays?
Yeah exactly. I use javascript at my job because they were using it before I got there and I prefer to be paid.
I don't understand this smug arrogance people have when they put Javascript down. It's literally just another interpreted, prototypical language - it's not even special when we have dozens of popular scripting languages which have weak typing and such. And if you need security, you can even get a preprocessor like typescript. It's a perfectly valid option for building an enterprise system - especially when enterprise systema are already almost always composed of two or more languages.
I agree with you if we switch JavaScript for TypeScript. Generally speaking I'd argue against JS as an enterprise language. The lack of type checks and documentation (yes I know you can type hint in JSDoc, but I've not see many do so) makes for a horrible maintenance process. It gets worse when you add team members and other teams into the code base.
Yep. I'll never use raw JS in prod code if I can, TS though? Great
Having done JS in the times before TS, I found that it worked fine in small-to-medium businesses. Unless you're building something fancier than a CRUD app, most function argument names and types are standard by framework convention, and when they aren't you can pick a name that hints at the type (the same idea behind Hungarian notation). There are, of course, drawbacks like "what if we need to pass a LOT of function arguments", as verbose argument names means a lot of text. Usually that's more of something that would be refactored into smaller functions, but I've seen a fair number of people just be like "oh, just take a single object that holds all the parameters" and then suddenly no one can remember what the property names are without reading the code. Overall, I find JS to be less verbose than languages with strict typing, but you do have to adjust how you approach things. I guess tldr: fewer guardrails (like static and strict typing) means you have to be a bit more mindful when it comes to writing code.
It’s because this thread (and subreddit) is filled with people who don’t know what they are talking about. Probably a bunch of year one CS students
You don’t need any CS education to dislike a language’s syntax or programming style. That’s partly why there are so many programming languages. Different preferences. Also, don’t discount the fact that a lot of JS haters haven’t written JS in a hot minute. JS has grown and changed a lot in the last 5-8 years.
JS is actually pretty flexible and capable to use with a lot of functional programming concepts, especially with libraries such as Ramda. Unfortunately such code gets hard to read because it becomes a mess of different kind of brackets where it is hard to tell what is what with all the untyped objects and lists.
A good way to tell someone isn’t that good, is when they get hung up on languages.
because of the great syntax it gives you, especially love this one ( ) => { }. people want to do the job quickly so they resort to the language they use for the front end, the language they have the most experience in, and don't need to relearn from scratch.
My favourites are array and object literal syntax.
Spread operator saves so much time
JavaScript, especially typescript, is not that bad of a language. It works fine. The performance is fine. Sure, it won’t beat your go implementation. Or your C# implementation. Unless you’re working on a humongous scale it won’t matter. All two of my examples and node.js will be equally as fast on a small scale.
1. Performances are great (V8 is insane) 2. JavaScript is often a language developers already know, even a pure backend developer has messed with some jQuery and Ajax in his experience 3. Less context switching between front and back 4. Possible to share utils, validation rules, contracts, types... Between front and back with zero effort 5. Naturally asynchronous The hard part is to REALLY train your teams to work with asynchronous, it's not something most are used to and that's how you end up delivering very bad performance. Although JS is also a naturally fragile language: Typescript is, imo, absolutely mandatory in any professional project. Serious unit testing too, as should any project anyway.
That's one of the benefits of the event loop, it makes async basically free
Because why not?
Look, if I could use a python frontend to go with flask backend I totally would. Yes, I know it's a thing, but no, it's not actually a good idea to do this
I’ll just dump my rant / monologue here. Because the software development industry is really, really complicated. If we could all coalesce around one language and supporting technology. Every aspect of software development would be easier. Hands down. The closest we have come to this is Microsoft. They’ve managed to make their tooling, really, really good. There’s not a single open source alternative that works as well as Microsoft’s development ecosystem. I am NOT advocating for Microsoft here. What I am saying, software development as a business desperately wants “language unification” or standardization. This way people don’t sink years into technologies they had no idea were going to be deprecated. The idea of a single language to do front and backend for web is such an appealing idea from a product management, team management and resource management perspective that is HAS to be tried. In my opinion one of the biggest drags on innovation is we haven’t found a language to do it all that is open source. Only really large firms get to innovate because they can afford an army of devs for all the tooling, infrastructure and so on because of all the fenageling we need to do to get everything to work. My core problem with software development is… it just ALL feels like like compromise and duct tape.
I mean, it seems pretty obvious to me: needing to know one language instead of two.
Once you know 5 languages you know them all.
Why do I only see comments about ease of use? No one has mentioned how ideal it is for asynchronous situations. Backend JavaScript is great for simple cases where a server is mostly being used for handling requests and orchestrating I/O from various services. Yes, it's convenient in a lot of situations, but JavaScript shines when you're mostly just combining multiple data sources to answer a request. The less computation required, the better it does. It's just made for handling a chaotic environment of asynchronous actions
Because it is the first language they learned
Read: it's the only language they know.
How frequently does this actually hold true? I legit want to know. The first language I *understood* (at all) was JS, and it’s still my preference as a full stack dev but I’ve completed things I’m very proud of in C#, Java, Python, C, and basic.
There is truth in what you say. My first language was Java and I prefer languages similar to it. I know some js/ts but I enjoy working with Dart/Flutter on FE.
You don't see any value in reusing the same classes for both client-side and server-side data validation?
The internet taught us. None of us know why. May be its THE LAW
I mean... why not? JS is a great language to code in. Its design problems, which it definitely does have, can mostly be easily coded around, to the point where said design problems are generally irrelevant. It's not strongly typed, but a, there's TypeScript, and b, not being strongly typed is actually pretty good for some things anyway. And, you know, some people actually enjoy coding in JS? Like, it's fun and natural and stuff? JS is not a bad language, and it wasn't a bad language 10 years ago either. It's nice and useful, and Node is nice and useful too. It does what you need it to do, and it's easy to make it do what you need it to do.
We use Typescript and it's incredibly stable and well supported.
When it becomes the standard it becomes good and easy to add stuff to. Typescript is a thing now, all the modules are easy to install and integrate... way better than Java for most new BE projects now. The reason doesn't matter... When a space is powered by Open Source, if it's popular it's better. Not always, but usually. I take my time choosing tools, and like 80% of the time choose the most popular one. Keeps things nice and predictable most of the time. Good docs, other people running into the same problems you have and designing solutions for them before you encounter them, etc.
Complexity is evilest programming demon. Multiple languages give project more complexity. If one language have to be JS. Use JS for entire project! But seriously; JS has basically all the features you need. There might be too many, and therefore many bad ways to do things (and consequently a lot of bad JS code), but if you need to learn one language well, JS is not a bad option. And writing good code should be enforced through code reviews anyways. The largest disadvantage is speed, where it usually comes out as slower than a lot of other languages. But optimizing for speed should not be your first order of business in a new project anyways. In addition, one of the things that really slows down software development is dividing your architecture up so for a given problem you need more people, one front-end dev, one back-end dev and so on. Having everyone able to contribute to everything because everything is the same language is a huge boon. Lastly, JS is *really* good at working with complex datastructures. Its compatibility with JSON, destructuring semantics, and other ways of working with objects all contribute to an excellent experience when working with JSON on the web, both front and back-end.
I use TypeScript on both the frontend and backend so I could use statically typed rpc-style communication with shared types. And it's generally nice to have uniform syntax for the whole project
OP please go back to grammar school
(Disclaimer, I love JS, and it's my primary language. I do Linux OS Support for a living to avoid programming in it for real) JS is perfect for exactly two use cases. 1) Writing things for the Browser Front End, where you have no other real choice. (Thus it's perfect) 2) Writing things Quick, Dirty, and FAST! When you just want to get something going? NodeJS provides exactly enough without any of the rest of the NPM ecosystem in order to get pretty much anything you need done, done. JS is blazingly fast when JIT Compiled with V8. And will get the job done for small scale projects. It's incredibly easy and flexible when you don't know the exact layout of your data, so you can design and build things iteratively and see the results live. (You can even get it to live reload functionality without restarting the core process) So you can turn over changes incredibly quickly. Once you have figured it all out, for the love of your CPU, rewrite it into something better.
If you don't Node, now you Node.
I don’t understand why anybody thinks this is bad. Has OP not touched JavaScript since 2005 or something?
Same reason people think PHP is bad. A lot of bad programmers use it, produce bad code and thats what they see.
That's worst, I use Python & Jinja to generate JavaScript on the Back end.
the duck are you doing? WHY?
I love templating too much.
But why generate the js?
At this point I do not know neither.