Skip Navigation

The future of back-end development

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.

87 comments
  • 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’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 npx to 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.

  • 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.

87 comments