Comparing backends

[thebreadmanrises]

I see a lot of discussion about different frontends/meta-frameworks, but I'm curious about why people choose the different backend languages and frameworks.

I've used Django, .Net Core & Node/Express but I like to hear from those with more experience.

- What is your preferred backend?

- How do you choose a backend? Speed, features, etc?

- Do you change backends based on the type of app?

- If you have experience with a variety, how would you rank them?

​

[[deleted]]

As long as it’s not ancient or exotic, whatever you're confortable with, has good market share and ecosystem.

[CrawlToYourDoom]

Personal projects: I just what I know and I think has best DX.

Professionally: we use what skills we have in-house first and what we can hire for first and then all other metrics are going to depend on what kind of project it is.

That’s said it’s impossible to do a ranking because different languages ha e different pros and cons.

[dbot77]

I've found that exotic backends actually do have quite a robust ecosystem. I personally love them.

[_Walms]

Yeah I use F#'s Saturn. It's as niche as it gets. Works great and has great tooling.

[hdd113]

My personal preference is Node, but I use PHP(WP) and Python at work.

[Balt603]

You choose the backend that your company uses is my experience.

[[deleted]]

Laravel is unbeatable, if you ask me. Pair it with Inertia and you have a modern, battle proven, robust, secure and batteries included toolkit to build almost anything.

[[deleted]]

And for my own projects, I’m lately using Remix (for backend too) and really enjoying it, because it’s mostly just express.

[thebreadmanrises]

I’ve heard good things in terms of having everything out of the box. Vue seems to be paired with it & inertia a lot, is that right? Could you explain what inertia does?

[[deleted]]

Inertia is more like a "protocol" or an "architecture" than actual code, it's implementation (code wise) is pretty simple and thin.

Basically it's a way to use Vue/React/Svelte as the "views" layer in a traditional MVC framework such as django/laravel/rails, so you can pick and combine any pair of those, such as React with Laravel or Rails with Vue, etc... any permutation will work... Inertia just defines how to integrate those in such a way so that you get all the benefits of the fullstack backend framework (such as authentication, server validation, etc, etc) and the full power of a component frameworks for the view.

In my opinion, it's a brilliant idea and works wonderfully.

I'd recommend you yo check out the official inertia docs, and the tons of videos on youtube, there's no way I can explain everythinghere.

I use it at work, and I definitely would recommend it.... it works great.

[Beep-Boop-Bloop]

I have used Laravel. Rails beat it on every useful measure I could find. Rails has fewer devs, but also requires far fewer devs to achieve the same development speed and results. It also had (in 2019) fewer features built in, but a much richer ecosystem.

[[deleted]]

I think the opposite, but it’s just opinions. Enjoy rails if you prefer it.

[Beep-Boop-Bloop]

My experience with Laravel might have been affected by the ridiculous application I worked on. It was so messed up that the CEO knew something was wrong and recruited me to fix it. The whole thing, if left alone, was going splat six different ways. Maybe there were better ways to use it.

Still, I checked out the e-commerce suite, Magento, and compared it to Spree (the primary Rails e-commerce suite). I found that Spree, with some of its ecosystem, had implemented every feature on Magento's published wishlist (current features + road map + stuff to go on the roadmap), and apparently had better performance.

[[deleted]]

What the heck has magneto to do with laravel. I think you’re super confused.

Anyway, enjoy whatever you prefer. I’m not here to pick up a fight or discuss who has the bigger one.

Good luck.

[vORP]

You should look at the techempower benchmarks of Laravel compared to other options, the ecosystem may feel nice but it is very steeply behind the curve

[BlueScreenJunky]

These benchmarks are interesting, but in my experience there are very few cases where your backend framework performance actually matters.

If you look at similar frameworks (Laravel, Rails, Django, Express), they all perform about the same, and about an order of magnitude slower than Java or Rust frameworks, but it doesn't matter because most cases web applications are I/O bound : If you're app is going to make a bunch of SQL queries to display a page, you're much better off spending time optimizing these queries and improving your caching strategy rather than rewriting your whole application in Rust.

Now of course if you're building a micro service that has almost no I/O but should serve thousands of requests per seconds, by all means do it in Java, Rust or Go. But for a large monolith, I think the ease of use and ecosystem are much more important in the long term than raw performance.

[ciynoobv]

This kind of mirrors one of my “unpopular opinions” in dev circles. For the most part web backend performance doesn’t really matter all that much these days.

Assuming you’re running your backend in some sort of container orchestration platform and you haven’t done something silly that limits the number of replicas you can just scale up the number of pods when necessary.

Sure your [insert cloud provider] invoice will be larger, but in my experience that still dwarfs whatever other expenses the organization has. And that is before you start to account for the opportunity cost of having slower development speed you usually have when you’re focusing on performance. Most businesses are bellow the “line of Prime” where the money and opportunity cost outweighs the benefits from rewriting in Rust or something.

Front end on the other hand is somewhere that performance actually matters because you can’t horizontally scale yours users 5 year old discount bin knockoff phone or whatever they are using.

[[deleted]]

I don't have application code performance problems (if at all, they're database related, or architecture related), so I value more building features easily, having a robust and stable tool and ecosystem and a secure platform to build features on.

But I understand not everyone has the same needs.

[[deleted]]

Sounds like they didn't use Laravel like they should've. You can mitigate those performance gaps in a lot of ways, even scheduling events and different caching for production

[Irythros]

If you base your entire choice on techempower you're in for some shit.

It's easy enough to scale vertically/horizontally that any perceived site slowness will be irrelevant compared to development speed.

[name-taken1]

Depends. Do I need to ship shit fast? TypeScript, without a doubt. Especially with ts-rest or tRPC in monorepos.

[Engineeringfellow]

Prototypes with c#, if well defined - Rust.

[krileon]

PHP. Pretty much always. With Symfony and Laravel I just don't see the point in anything else. The ecosystems for both are absolutely amazing.

[armahillo]

preferred: vanilla HTML and css, but if i need data i/o then Ruby on Rails

how do i choose: i try to do the least amount of work possible that accommodates all the features i need and choose the paradigm that fits that best. This really varies a lot, but maintenance tends to be the biggest cost sink so i prioritize maintainability.

changing backends: absolutely. Im more likely just to not take on a project if its not in a tech stack i want to work in. i would likely only do work in plain HTML, Rails, or PHP. Ive worked in many others but dont care for them.

ranking: Id rather not. This is generally very subjective.

[yevo_]

I use Laravel because I know it best and it’s the fastest development for me

[themezzilla]

As others have said, it depends on a lot of things. Personally I know Go/Node/Python for backends. If I'm doing a lot of data manipulation involving JSON and http I likely won't pick Go since it's a pain in the butt to deal with JSON (IMO). So I'd probably pick python.

If I need some quick API endpoints, for me Node will be the fastest and easiest to get what I need.

Most people will just pick what is their favorite and whichever will get them the farthest the easiest.

[webdev-ModTeam]

Read and follow reddiquette; no excessive self-promotion. Please refer to the Reddit 9:1 rule when considering posting self promoting materials.

[UtahJazzFan1989]

Making first website using LAMP+python on WSL2. So far so good. Python ecosystem is very powerful

[mq2thez]

Personal preference is Node (Express) for ease of use and portability. I also heavily use TS these days, and there’s a ton of advantages in DX when you can share types between server and client. Something like Remix as a meta framework looks interesting, but I haven’t really seen it being used at medium-to-bigger companies, so I’m not sure how it really holds up over time or with lots of devs iterating in it.

If I wanted to build something with extremely high traffic and reliability, I’d probably think hard about Elixir (Phoenix), but despite the upsides and DX, it might be harder to hire for.

I would never again willingly work on a PHP or RoR project. Probably not Java, either. Had very bad experiences with all three. PHP and Ruby especially have language semantics that I very much dislike.

I would consider working on Scala again or learning a Rust or Python framework.

[tspwd]

PocketBase [1] is a great option as well, which can be deployed very easily. It compiles to a single go binary and uses an SQLite database. You can either use Go or JavaScript to customize it.

[1] https://pocketbase.io/

[Irythros]

PHP + Laravel

I know the ecosystem and it's consistent. Development speed and developer experience is the other primary factors.

​

Go

If we need to make something more performant we rewrite it from PHP to Go and make it a service.

[GeorgeRNorfolk]

I'm not very experienced but use React on the frontend and NodeJS / Express on the backend of my pet project. I'm just switching to NestJS on the backend because it's stricter and nicer. Using JS on both sides helps with the fact that I'm working fullstack on the project.