I'm surprised how so many HN posts about graphql just slander it. If you go to the website and look at the use case of why it was made, it makes it pretty clear when it could be a good to use. My experience with it has been very straight forward and a joy

For example, the Pothos library implements this pattern automatically:

    type Error {
      message: String!
    }
    
    type Query {
      hello(name: String!): QueryHelloResult
    }
    
    union QueryHelloResult = Error | QueryHelloSuccess
    
    type QueryHelloSuccess {
      data: String!
    }
    

    query {
      hello(name: "World") {
        __typename
        ... on Error {
          message
        }
        ... on QueryHelloSuccess {
          data
        }
      }
    } 

If someone has solved the asshole corporate middle box problem using GQL, that’s really good news.

You generally don't want to use HTTP error codes with field level errors in GQL.

And bo one is stopping you from returning a response that contains error details.

Most commercial websites want analytics on how users browse and click on the website. So this point goes out the window.

I don’t dispute the thesis of “web pages today are often way too bloated”, but I think it’s important to be realistic about the problem space. The author calls out JavaScript driven carousels as an example of unnecessary bloat… yet the Amazon.com home page features one such carousel prominently. I doubt they would put it there without A/B testing the heck out of it. To be fair, Amazon is way smarter about it than most in how the page paints and is interactive very quickly, but my point is that it seems to me that most web users want something more than what JavaScript-less HTML and CSS can provide.

> The problem? Amazon did not.

The headline is misleading and doesn't make it clear the workers don't directly work for Amazon. They work for Battle-Tested Strategies

> The union’s next step is proving that wrong. Amazon, it says, is a joint employer of the drivers, and in full control of the conditions that caused them to organize—low pay, unsafe heat conditions, and extreme performance requirements—despite the fact that it places those responsibilities on the DSP.

It being commercially successful is not a concern for me. That would be the difference between a hobby and a job for me

I'm running 165hz + 240hz on Xorg with i3vm or KDE Plasma (kwin). OpenGL compositor with Nvidias drivers. Everything works fine.

It goes to show that I got downvoted for my original comment. I used to use Linux as my main os for about 7 years, but now my free time is more limited. I don't care to debug these type of problems when I am trying to just use my computer.

At work I remote into a Linux vm, so I'll do that at home as well whether my host os is windows or mac. It works for me.

Sure, its a lot worse for brand new laptops. But it never entirely works to the level you'd get from macOS.

This is also its disadvantage.

I haven't built SPAs yet, but I'm looking into trying Unicorn: https://www.django-unicorn.com/

In the end I have to write a bit more of boilerplate each time (and with tools like copilot it's a non-issue) but it's 10x faster to understand what a view does and how when reading code.

I just use an IDE which allows me to Ctrl+Click into any symbol and see its implementation and underlying classes (and do so recursively if needed). That saves me from having to lookup the documentation all the time.

What I really like about Django and Python ecosystem in general is the kind of stability that it doesn't move too fast and break things, which happens in JS land too often. And Python is a nicer language of the two, for me at least.

But at the end of the day, you can combine both. I work for Baserow now and we combine Nuxt + Django. You can also simplify it to Vue/React + Vite + serve it with Django, use cookies-base auth etc.

1. build your app in the normal, old way. just doing SSR for showing and editing boring content is so much faster than building it in react.

2. I have a tiny scrap of JS that digs through elements on the page, and if they have a class, creates a React root there and passes in some params. I then wrapped generating those replace-me-with-a-react-root elements in a Rails helper function.

(2 is my "fine I'll do it myself" after Rails 7's new js stuff broke react-rails for me.)

This might be colored by me being a backend dev and data engineer type of person and I have terrifically little patience for writing javascript. But pages where I've followed this "SSR + some React doodads for when you really need special sauce" pattern end up so much easier and faster to write than cramming it all into a huge SPA.

I'm sure if you're building something deeply fancy then doing it all in React makes sense, but I find there's really only a couple pages that actually do end up being 100% react and the rest end up fine just having a text field here or there or a little widget thingy being the React components and the rest just being SSR.

I'm sure this doesn't scale if you're google or something either but even on my most complicated pages this still loads visibly faster than many other sites I use.

Edit: grammar

Overall, I've found it great for prototyping up something really quickly. I think this is where the "batteries-included" helps a lot

I’d pick it for these reasons.

I don't think currenlty there are any solid alternatives beyond Nestjs+Typescript, ruby on rails and laravel. The sentimemt of their community is that these frameworks are built for web development in mind. While I think for Python based web framework like Django the sentiment is that you are using Python already and here is a web framework written in Python. If you look at some of the Rust based web frameworks you will understand what I am saying. The merit of the framework is the language it was written in. This makes hiring web developers difficult as most candidates will be Python Developer who knows Django and not web developers who knows Python. There are very few people who learned Python to use Django. But everyone learned javascript to use nodejs, or ruby to use ruby on rails.

If I am writing enterprise level where Python is used I will pick one of those 3 frameworks and use a Python based API framework like DRF or FastAPI for building internal APIs.

If I need a database and interactivity I pair NextJS with Django Restapi.

Wut? It's more a case of "everyone learned javascript to do button rollovers in the browser, and then nodejs allowed them to do more".