What are your opinions on the future of back-end web development? Is the Java ecosystem going to wither away as more modern and better solutions are emerging and maturing?
If so, which language/framework and/or programming paradigm do you think will become the new dominant player and how soon?
Personally I would love to see Rust becoming a new standard, it’s a pleasure to write and has a rapidly growing ecosystem, I don’t think it’s far away from overtaking Java. The biggest hurdle imo is big corporations taking a pretty big risk by choosing a relatively new language that’s harder to learn compared to what has been the standard for decades.
Playing it safe means you minimize surprises and have a very large amount of people that are already experts in the language.
Taking the risk will definitely improve a lot of things given that you find enough people that know or are willing to learn Rust, but it also means that you’re trading off Java flaws with Rust flaws. That’s the case however with every big change, and Java flaws are a good enough reason to make a big change.
Java is getting better each year plus Kotlin works in the same eco system and is hyper popular. I don’t think that Java will wither any time soon.
I really like Kotlin, I would much prefer using it at work instead of Java
It sure is! We moved a few years ago and no one regrets.
Advertising it on work is not an option? Because the technical barrier to change language inside the JVM ecosystem is quite low.
Why not use it at work? It’s incredibly easy. You can even replace it a single file at a time.
That’s not possible for one person to do out of their own personal preferences in a large scale enterprise application.
It would be a project wide migration with tons of people working on it and testing afterwards.
That’s not possible for one person to do out of their own personal preferences in a large scale enterprise application.
It would be a project wide migration with tons of people working on it and testing afterwards.
I do not know why you think this. You bring it up at an architectural meeting, you begin by explaining the reduction in bugs (there are plenty of studies for this). Then after you get buy in you can literally add the Kotlin library to your pom or build.gradle or buck or whatever system you use and then you can add a single file for Kotlin and it just works. You don’t have to migrate anything, even existing files. I know. I’ve done it multiple times at multiple companies. Migration is incredibly easy if you want to do it, but you can literally just have both side by side with no problems. You wouldn’t need testing for anything except the new code you added. In fact a great way to start with Kotlin is by using it for test files. Then you don’t need to test anything related to the Kotlin code at all!
And yes, I’ve been the “one person” pushing the Kotlin so I do understand the political and technical problems you have to deal with. It really isn’t as difficult as you think.
Going to a hybrid would technically be easy it’s true, but very few people know Kotlin so no one would write it, not even the ones who know it since others need to be able to read it.
I’m not nearly high enough hierarchically to call a shot like this or be able to continually enforce it. I usually always ask my team leader for his opinion even if I’m simply adding some kind of dependency.
I really think you’re overstating how difficult Kotlin is to learn. I’ve converted over 30 people to Kotlin, and it doesn’t take more than a few minutes for them to get the gist of it. If you use Lombok it’s even easier. Just say it’s Lombok without all the bytecode manipulation, it’s actually part of the language.
People love using it once they see it. I’ve had one single person go back to using Java after using Kotlin. Do you use anything like groovy, cucumber, aspectj, powermock, etc? If so you have an even greater argument here. It’s much easier to learn Kotlin than to get any new employee up to speed on those tools and frameworks.
Just try. It really sounds like you don’t believe in yourself here. I wasn’t high ranking when I switched my last company over to Kotlin. The language really speaks for itself. There are also plenty of resources giving you ammo for convincing.
Kotlin is a very easy transition, and it sorts out a ton of issues that you find in Java. Certainly easier than moving to Rust.
Java gets a bad reputation from proponents of FOMO/fad-driven development, but the whole Java ecosystem was built for the web. Anyone is hard-pressed to find a better tech stack than Java-based frameworks without resorting to hand waving and passing personal opinions as facts.
I love C# and the whole .NET Core ecosystem, but even I have to admit it’s very hard to argue against java.
fad-driven development
This is certainly a way to dismiss all other programming paradigms, I suppose. Also, having used both C# and Java, I can’t see myself writing another backend in Java again when C# is such a pleasant language to write in. Both languages have flaws of course, but I find C#'s significantly more tolerable than Java’s.
Exactly. The only reason Java is remotely tolerable today is because of influences from those ‘fad’ languages. Kotlin and Scala were also fads when they came out, they just got adopted because Java was utter shit at the time. Hell, even Java was a fad at some point in time.
I think a strong argument could be made for the JVM as a whole to be honest, since it encompasses several languages. That being said, I’m not sure I’ve seen a backend written in Kotlin despite how prominent it is for app development.
I’m not sure I’ve seen a backend written in Kotlin despite how prominent it is for app development.
I worked with really Big Bank who have their whole backend written in kotlin. It was such a great thing to witness because usually financial institutions don’t give a fuck about clean code and modern programming languages.
I’ve been using ktor in a personal project and it’s been a joy; all the familiarity of Spring but with Kotlin first.
Also, I know that Amazon has started to switch some projects to Kotlin, since they’re such a large Java shop: https://aws.amazon.com/blogs/opensource/adopting-kotlin-at-prime-video-for-higher-developer-satisfaction-and-less-code/
Amazon has been adopting a lot of languages in recent years, including writing services in Rust and C# to my knowledge. It’s cool seeing them branch away from Java, although I know that internally they use their own flavor of Java (Corretto).
I can tell you without any shred of doubt that Amazon still standardizes on Java-based frameworks, including Spring, and has absolutely no plans to switch. Each Amazon team is able to pick its own tech stack, but the ones that do not use Java or a JDK-based stack are extremely rare, and more than not are working on specialized applications such as mobile development.
I can also tell you without any shred of doubt, that there are many Amazon teams that absolutely hate Java and would rather build their stack on top of anything else (except PHP, which is rightfully prohibited company wide)
It is branching away from Java, even if it still uses it primarily. Unusually, off the top of my head, I happen to know more .NET developers working there than Java developers, and interestingly they develop one of the services on AWS. I know that there are significantly more Java developers, but I don’t think we are in disagreement that there are projects that don’t use Java.
That being said, I’m not sure I’ve seen a backend written in Kotlin despite how prominent it is for app development.
That’s funny because as a backend Kotlin dev I literally haven’t seen an Android app written in Kotlin (at any of the companies I’ve worked at) but have worked since 2016 with Kotlin on the backend.
Before google announced support for Kotlin the split was massive. Most apps were backend with only a fraction Android. And Kotlin wasn’t even originally built for Android. It only happened to work and then it got popular after someone reported a bug on Android and they fixed it.
It’s nice to see that it’s in use for backend. I personally haven’t seen it, but I always felt like it’d be a good choice for backend development.
Yeah it’s great! We compile it into native code and deploy it as lambdas on aws. It’s actually faster than most nodejs lambdas. I love it!
Scala got adopted? https://insights.stackoverflow.com/trends/?tags=scala%2Cc%23%2Cjava their business model is killing the language
Apparently I used it at its peak. It was the go to language for big data processing at the time
We had developers leave my company because they had to work with scala during 2 -> 3 migration. Everybody hates it now
I never used Scala 3 but was under the impression that the migration wasn’t as bad as Python 2->3 https://lichess.org/@/thibault/blog/lichess--scala-3/y1sbYzJX
This better shows what migration is like https://docs.scala-lang.org/scala3/guides/migration/incompat-syntactic.html
More, new brackets near lambdas, new string formatting, indentiation change. Doesn’t look much, but absolute madness when your team is weak in Scala. Only 1 dev had prior scala experience, but whole team had to be involved in migration of breaking changes in scala syntax behavior and… same for gatling. Also changes in syntax. Mid-level dev left the company because of it, we very soon completely got rid of scala and replaced it with TS and Go. Both languages new to the team, but 0 complaints since February.
The only reason Java is remotely tolerable today is because of influences from those ‘fad’ languages.
This might be your personal opinion but it is not a very informed one, or in touch with reality. Java frameworks such as Spring still dominate the backend ecosystem and some FANGs still standardize their backend development around it.
Read that again. I didn’t mention anything about ecosystem, I said Java, aka the language and JVM. You can patch it up all you want with frameworks, it is still a shit language, had an absolutely useless GC up until Java 9 (20 years into its existence). Though it has gotten slightly less shit in the last couple of years. It is informed from years of working with Java 6 onwards. The fact that I don’t agree with your opinion doesn’t make me less informed.
deleted by creator
This is certainly a way to dismiss all other programming paradigms, I suppose.
My comment has nothing to do with paradigms.
In fact, your strawman is proven to be false by the fact that there is no mainstream tech stack for the web which is not object oriented and provides a request pipeline that uses inversion of control for developers to pass their event handlers. They all reimplement the exact same solution and follow the exact same pattern to handle requests.
Your original comment and this one are exactly what you criticized in your first comment - opinions presented as facts. I encourage you to branch out. You might find that there are other languages and frameworks out there doing cool stuff, and IoC occuring even in the lowest level of languages.
Edit: Since you love facts so much, let’s look at some numbers. According to the Stack Overflow 2023 survey:
- JavaScript, Python, and TypeScript (which is apparently separate from JS here) all are more popular among professional developers than Java. C# and Java are toe-to-toe, with Java only 1.33% ahead (negligible at scale), while JS is more than twice as popular as both languages.
- Node.js takes the lead for web-based frameworks, with Express being the most popular listed framework that I can see. Both flavors of ASP.NET are more popular than Spring Boot among professional developers, and people have been moving towards .NET Core for years now. Flask is only 2% behind Spring Boot as well, and being a Python-based framework, does not use traditional IoC and instead follows more of a service-locator pattern, where many request-related variables are stored in what is essentially thread-local static state.
- Although meaningless on its own in my opinion, it’s still fun to point out. Java is one of the least admired mainstream languages in the survey, falling at 44.11%. It falls behind C++, C#, JS, Python, and TS. The most admired language falls back to Rust for… I forget how many years in a row, which isn’t even an object-oriented language (though borrows some concepts from them).
I can’t describe it. Java is a good language. I just don’t like it, don’t want to write it, am sick of dealing with its build tooling, and have worn thin of all the IDE’s-do-all-the-work-for-me mentality. Good Java programmers are excellent but they are eclipsed by an army of people that haven’t any idea how it works… in my experience.
Just use scala or any other decent JVM language then :)
It may be an opinion, but pointing it out won’t make me like java any more.
Just switch to Kotlin. You get all the benefits of Java with hardly any downsides. Modern language with modern features that is incredibly enjoyable to work with.
I don’t see it withering away anytime soon. My entire career has been enterprise web development (which is why I roll my eyes at all the web dev rants). Every company I’ve worked at has used Java on the backend and some JS framework for the frontend. Java has only been improving in that time and getting much easier to write. I don’t see companies taking an (in their view) unnecessary risk that makes it harder for them to hire and lose efficiency, at least in the short to medium term.
I think the only way that changes is if developers are interested enough to try Rust, or any other language, in their free time. If they like it enough, they’ll suggest it at work. If enough developers are doing that, it’ll slowly shift the local scene.
For me it has been the same except replace java with c#, I can argue that golang might soon be admitted into the “serious backend language club”.
For how much crap people give java and c# they are languages you can get shit done in, fast , efficiently and stable.
I’m surprised no one has mentioned golang. We have the usual dichotomy of java and rust but there’s a very very good option for those who are worried about rust adoption.
I vastly prefer writing rust code but go on its own gets you very very similar performance at the cost of developer experience. I think sum types are the #1 requested feature so once that comes I’ll be a much happier boy.
I think Golang had the potential to take over just because it’s so easy to pick up and start contributing.
My last position was Golang focused and our hiring was never focused on experience with the language because we knew that if you understood programming concepts you would succeed in Golang.
Today, I’m working on Rust and while I enjoy it for what I’m using it for (Systems level instead of Web Services) I’d be hesitant to suggest it for most backend application just due to the ramp up time for new developers.
tl;Dr Golang will have an easier time hiring for because no language specific experience is required.
I’d be hesitant to suggest it for most backend application just due to the ramp up time for new developers.
I would probably suggest Rust for that exact reason, you’ll have to fight the language a little bit at the beginning (at least if you’ll have a very “interior mutable” experience instead of a functional background), but it teaches you how to write your code in a nicely relatively uniform compositional safe style, that IMHO can be read quite well between different people (team) and I think is easier to review (as long as it’s not some super magic trait-heavy/proc-macro code of course, but I think for actual applications (vs libraries) that part will be rather low)
Also I think nowadays the barrier into the language is much lower than it was a few years ago. The tooling, specifically rust-analyzer (and probably Intellij Rust too, never tried it though) and the compiler itself got really good in the meantime (I actually think Rust-analyzer is by now the best LSP for any language I know of), so that getting into Rust is likely not that hard anymore (you’ll have to learn/understand a few concepts though, like heap/stack and the lifetime system, but I think that it’s not that hard to learn).
Go just often feels very hacky to write with a lot of quirky things like handling errors, and a lot of missing features like pattern matching or a relatively good type system, I don’t think it really promotes that nice architectures (or limits the programmer kinda).
Yeah it’s pretty crazy how fast you can get going in go. As long as you are aware of a pointer you are mostly good to go.
Just wish it felt better 😫
What is it about go that doesn’t feel good? I have this feeling myself.
I didn’t enjoy parsing JSON with Go, and I the documentation sucked. But it was really really easy to stand up a simple API endpoint. I would have reached for go for the project I am currently working on, but it didn’t have the libraries I needed. It’s interesting.
It’s the usual if err != nil return err critique.
If you could yoink the question mark operator from rust AND support sum types that would be the dream.
The marshaling isn’t too bad unless you need to do more specific things. I vastly prefer how rust’s serde does it but that language is the forbidden fruit
I’m on the boat that rust is a bit more cumbersome to write that Java/C#. I work in .Net and I really want to give Kotlin a go now.
I guess I’ll just have to wait for MS to add the current trendy feature to C# again for the sum types though lol.
I actually think java is more cumbersome to write, Rust is definitely higher cognitive load though (get the typing right, fight the borrow-checker etc.).
With cumbersome I mean, that the language limits yourself with a relatively bad type system (compared to Rusts) and often results in a lot of boilerplate and IMHO generally promotes the wrong patterns (I think https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition brings this on point in a comical way). But I’m biased, I much prefer functional programming vs object oriented programming…
I remember reading the Hello World edition of that one. I haven’t gone through a big project and a couple of small ones with rust so I’ll have to stop talking hahaha.
But yeah writing inheritance heavy code in Java is the absolute worst and not everything needs an interface and not everything has to use the strategy pattern for a single use case. Java promotes overkill dependency spaghetti so I get that, however interfaces work the same as Rust traits and can be used in the exact same way with POJOs so I’m on the fence.
I’ll have to wait and see which one I’ll like more I guess.
Well just program a little bit more Rust, at some point you don’t want to look back haha. It’s almost like a curse for me, I can’t really enjoy programming in another language anymore (ok not completely true, but at least the major languages I had to use before like C# or Typescript etc. feel dirty and limiting now ^^). I would enjoy something like Haskell with better tooling anonymous sets, less laziness and a slightly more opinionated syntax though (having all kinds of weird operators sometimes looks a little bit brainfuck). Sometimes Rust is a little bit boiler-platy and gets complex when you’re overusing fancy trait-based generic code (but it’s kinda fun, you can do a lot of fancy stuff with traits), and often the type system is limited compared to Haskells, if you’re approaching higher-kinded types territory…
I have not done much GoLang development, but I am working on automating some dependency updates for our kubernetes operator. The language may be good, but the ecosystem still feels immature.
Too many key libraries are on version 0.X with an unstable API. Yes, semantic versioning does say that you can have breaking changes in minor (and patch) releases as long as the major version is still 0, but that should be for pre-release libraries, not libraries ment for production use.
Too many key libraries are on version 0.X with an unstable API
Sounds like my rust experience but then again it’d be non-existing for some of them.
I think that India will be a major factor and there are many Java developers. C-level guys don’t care about programming languages, they do care about cheap labor. So I don’t think that Java is going to wither away anytime soon, at least on a global scale.
This was said 20 years ago and none of it was true. Outsourcing is big but we don’t outsource our highest level jobs. The typical architect role or senior engineer roles
Unless it’s a 10-man startup, a typical company doesn’t employ exclusively architects and senior engineers.
By the way, I think it’s quite arrogant to think about this in terms of outsourcing and “we”. “We” might not outsource everything, but there’s a huge market with a lot of potential beyond borders where “we” are located. That’s why I explicitly said:
I don’t think that Java is going to wither away anytime soon, at least on a global scale.
That is a bit dismissive of Java developers around the world. There are several of us still left and we are in key positions of power.
I think that .NET will be used more and more instead of Java, because C# is similar to it, but better¹. And there is also F# which is great too². Rust and JS³ might also get some more usage in backend.
¹The only thing missing is union type.
²And has union type :D.
³And that’s unfortunate because I don’t like JS.
It has nothing to do with “being better”, it is mostly about a corrupt ecosystem and developers not even realizing what happening.
- Most non-tech companies use services from consulting companies in order to get their software developed / running. Consulting companies often have large incentives from companies like Microsoft to push their proprietary services. For eg. Microsoft will easily provide all of a consulting companies employees with free Azure services, Office and other discounts if they enter in an exclusivity agreement to sell their tech stack. To make things worse consulting companies live of cheap developers (like interns) and Microsoft and their platform makes things easier for anyone to code and deploy;
- Microsoft provider a cohesive ecosystem of products that integrate really well with each other and usually don’t require much effort to get things going - open-source however, usually requires custom development and a ton of work to work out the “sharp angles” between multiple solutions that aren’t related and might not be easily compatible with each other;
- Companies will always prefer to hire more less expensive and less proficient people because that means they’re easier to replace and you’ll pay less taxes;
To make things worse consulting companies live of cheap developers (like interns) and Microsoft and their platform makes things easier for anyone to code and deploy
You’re saying this as it is a bad thing when it is not though; better defined APIs and ecosystems that lift cognitive load from you is always a good thing, there is no way to spin that as a negative.
I think dotnet offers an incredibly good ecosystem for development, and I say this as someone that wants to jump ship and change the stack. What pains me the most about the stack is nothing technical. It’s not even the past predatory moves of microsoft, but the developer culture that surrounds it. Most dotnet devs I’ve worked with and talked to seem to be people that simply use visual studio as a window to the rest of the world. They tend to have very poor knowledge about almost everything with barely any fundamentals.
Not sure I follow your point about open source; I think everything we use at work is open source already. Everything is on github and there are quite a lot of discussions in how to steer the language and ecosystem being made in the wide open. It reminds me of the openjdk and python ecosystems. Third party libraries are all open source and have been since almost forever. There is still some closed source culture but not much.
I’m just saying that Microsoft created a self perpetuating (negative?) feedback loop when it comes to software development that essentially takes all the “hard parts” of programming and replaces them with services so anyone with little experience can deliver useful software products. That in turns allows for consulting companies to hire more cheap labor and reinforces the need to by into MS ecosystem that will be developed (improved?) even further in this direction…
deleted by creator
This is the real answer.
There are still, in the year 2023, Cobal developers graduating and getting hired to work on software.
My alma mater’s website runs on PHP.
The investment to flip even a microservice from one language to another is REALLY high, and most companies won’t pay unless there’s a significant pain point. They might not greenfield new projects with it anymore - but it will still be around effectively forever.
I’ll throw my 2¢ in on TypeScript → JavaScript. The typings accelerate development significantly (if the developer doesn’t fight them and make everything
any), and you can write to modem JS when you have older runtimes.But more you can do full stack from cloud infra (Infrastructure-As-Code with something like AWS-CDK or CDKtf) to deploy and orchestrate front-end to back-end.
Yeah but the ecosystem drags it about as far down as you can go.
Backend development for large applications relies on stability, the JS ecosystem has anything except stability.This is okay for FE development where you naturally have a lot of churn.
It’s a reasonable expectation that a backend built today should be maintenance free and stable over the next 5-10 years if no more features or bugfixes are required. And is buildable, as is, anywhere in that timeframe with minimal or zero additional work.
Additionally, strong backends in the same ecosystem are similar, they use similar technologies, similar configs, similar patterns, and similar conventions. This is not the case for JS/TS backends, there is incredible churn that hurts their long term stability and the low-maintenance requirements of strong enterprise, and even more importantly small businesses backends.
Mature ecosystems provide this by default this is why C#/Java is so popular for these long-standing, massive, enterprise systems. Because they are stable, they have well established conventions, and are consistent across codebases and enterprises.
This is a perspective most devs in the ecosystem lack, given that half of all developers have < 5 years of experience and the vast majority of that is weighted into the JS ecosystem. It takes working with systems written in python, TS, JS, C#, Java…etc to gain the critical insight necessary to evaluate what is actually important in backend development.
Edit: to be clear this isn’t just shitting on JavaScript because that’s what people do, I work with it everyday, TS is by far my favorite language. 2/3 of my career is with JS/TS. This is recognizing actual problems that are not singularly solvable with the ecosystem that pulls down its liability for backend development. There are languages and ecosystems are much better for your back end it’s not that scary to learn a new language (many of my co-workers would disagree it’s not scary 😒)
On your point about junior devs working on backend. I think part of that is that asynchronous programming is just hard. You have to have a brain for it. Some stuff you can get away with (front-end, for example, if you miss an event after an animation it’s not the end of the world), but for serious back-end systems you have to know how to handle async no matter what language you’re in.
I’m not sure what you mean by unstable ecosystem. I can presume you mean it’s easy to gain tech debt since there’s such velocity in the node/JS/TS ecosystem (and I agree not all of it is good).
I haven’t found it to be an issue. My job is a contract system engineer guiding companies in fixing tech debt, so I am very attuned to it.
Specifically I’d say the tooling in the last year or two has gotten much better at stabilizing an environment for node/deno development in particular. Tools like fnm, projen, and esbuild mixed with installing tools per-project (using
npxto run them) instead of globally for development allows flow project to project on the same machine without having conflicts of tooling versions. Combine that with Docker for deployment and something built today should last 4-5 years with little maintenance and not having to make any changes except for security patches.Not that there’s not hiccups. The whole CJS/ESM nightmare is still going (but near an end I feel).
I also feel like 4-5 years without maintenance is not something you really want. In the rare case you do, then I’d say JS is likely not for you. I’m not sure what language is. C or C++ most likely. Those have been around forever, and will never go away. Modern C++ has a lot of great features to handle memory management automatically, functional programming capabilities, compile-time metaprogramming, and OS abstraction, so that’s what I’d recommend for something that needs to last forever with minimal changes. (Thinking like a COBOL replacement.) After all, that’s what node and the JavaScript engines are written in.
My biggest issue with Java in particular is the predatory enterprise ecosystem. I spend a lot of time helping companies get away from that for cost reduction and lock-in issues.
One more point for node: it’s hands-down the most optimized interpreted engine in the world. This can be determined simply by the size of the companies that work on it and that absolutely depend on it being it’s best for their bottom line. Google, Apple, Facebook, and Microsoft among them. Billions spent on that optimization. Just sayin.
You can do cdk in a bunch of languages. You can also use Kotlin for frontend, but that doesn’t mean it’s the right choice. Leave TS and JS to the frontend, other languages to the backend. Please stop building nodejs applications. Please please please. It’s the absolute worst language to debug and fix. And inevitably I’ll have to come along and fix whatever it was.
If I may, I think C++ is the worst language to debug. Template errors are just out of this world
lol ok you got me there.
Python is already popular so Mojo making that ecosystem much faster, safer and easier to deploy could be game changing when it’s fully formed. There are also armies of existing Python developers out there for businesses to tap into and it’s an easy language to pick up.
On their roadmap page, it looks like C++ interop is going to be a first class citizen too, further opening up the ecosystem to existing high performance libraries:
Integration to transparently import Clang C/C++ modules. Mojo’s type system and C++’s are pretty compatible, so we should be able to have something pretty nice here. Mojo can leverage Clang to transparently generate a foreign function interface between C/C++ and Mojo, with the ability to directly import functions:
from "math.h" import cos print(cos(0))In my opinion, Python is still missing one key feature: the removal of the Global Interpreter Lock, which is finally starting in Python 3.13.
I also think Mojo will be quite a strong player everywhere
I don’t think many large established companies will be taking the risk on newer languages, but there are plenty of new companies that will mature based on a foundation of writing their backend in Rust or some other new language.
Probably some Rust contingents will form on internal teams within large companies, and they will build new products or services in X new language.
I give typescript running a decent shot of being a major force in backend APIs. There’s a draw to being able to code the same language on front and backend. It’s got a stronger type system than Java in strict mode as well.
It also has quick boot time which can help in cloud functions that may eventually become the preferred method of APIs. No server or os to maintain and they are close to the customers location
Yeah, JavaScript/TS doesn’t get a great rep being used on the backend. But I use it on quite a few of my projects, one of which gets thousands of requests per minute. I was skeptical of whether or not using Node on the backend would hold up, but the performance has been stellar… pretty surprising, actually.
I really like TS and Python as a backend language but only for projects that are under 5k lines. As soon as it gets above that refactoring, reference counting and type safety falls off for TS imo.
I’m still a TS fanboy. You can do some crazy type acrobatics in it.
Thousands of requests per minute can mean many things so maybe you’re referring to several hundred requests per minute, but one of our services at work gets 300 requests/second which is ~18K requests per minute and it’s really not that much. We’re using pretty cheap cloud services. Even thrice the traffic is pretty much a slow walk for your average production-grade web framework.
Web frameworks are built to support an insane amount of incoming requests, including node. The issue with node is the single threading and having to scale with worker threads AFAIK.
edit: our runtime is C#
The issue with node is the single threading and having to scale with worker threads AFAIK
People always say this but its not technically correct and can be misleading.
Technically, JavaScript runs single threaded but not Node.js itself and certainly not when using it on the backend in something like Express. IO operations and other things tooling libraries do can cause you to run out of a thread pool. But Node.js, when handling requests, gives you much of the benefit of multithreading without having to deal with multithreaded code.
Aaaahh so libuv actually runs a thread pool, TIL. I’m another victim of internet propaganda I guess 😅 . You know, I never actually checked libuv docs until now and they seem quite welt built.
The silliest thing I’ve just realized is that I knew that the first implementation of a web server in dotnet core was using libuv, and I still didn’t think twice about the single threaded meme.
It doesn’t get a great rep? Would love to hear from that perspective. I’m only seeing the opposite.
Many popular node libraries are/have converted to Typescript. I was on the fence last year but now I’m working towards converting my work into Typescript too.
I think they meant JavaScript/TypeScript don’t get a great rap in comparison to others like Java, Rust, C#, etc.
I think everyone who works with JavaScript/TypeScript professionally will come to prefer TypeScript given a bit of time.
My team is trying to shift away from Java towards a TS backend. Call us stupid but our current Java stack is a nightmare to work with.
Personally I would love for us to do a Go or Rust based backend, but we’re basically a startup with a rotating set of employees so I don’t see that happening
In the long run, three players can remain standing:
- The obvious choice - it’s (currently) JavaScript, because some of us will always follow highlander rules. It used to be PHP, when JavaScript wasn’t popular yet, at the dawn of time. Before that it was Perl because CGI. Python and Java arguably each had a moment sometime between Perl and JavaScript.
- Whatever is fastest for high performance - odds favor golang, but I’m just guessing. Could honestly still go to C. Many languages have died before unseating C in high speed contexts.
- Whatever has the best library support. - In my random opinion, there’s currently a run-off between Python and NodeJs to unseat PHP and Java.
Serverless.
Modern DBs (supabase, atlas, firebase) don’t require much, if any, backend code.
I’m talking mainly about serious backends that perform complex logic, not just CRUD operations
FWIW, serverless doesn’t mean “no backend”. Serverless apps can still have backend code using edge functions. Serverless just means “much less backend”.
Most backend code I’ve seen is boilerplate, or reimplementing functionality that already exists in the DB, and serverless libraries just remove the need to write that boilerplate at all.
Serverless will forever be stuck as a tech that’s only good for majority async stuff because of cold boot speed, scaling costs, and general latency.
Good point. That used to be the case, but I think that’s been a solved problem for a while. IIRC, most places cache functions for up to a day, so any site with reasonable traffic won’t have to wait for boot.
Regarding scaling, one cool thing about serverless libraries is that some are open source and provide instructions on how to self-host.
