[dsabanin]

What's with the GraphQL luddism on HN? I'm as much opposed to adding more incidental complexity to the frontend as the next guy, but GraphQL has objective purpose and makes a lot of things much simpler than they would be without it.

Learning new things and doing things better than they were done a year before is an essential part of being a professional software engineer, it's what makes this field hard and that's why we're paid so much. It's what makes us able to tackle so much added complexity of the world, new use cases, new platforms and paradigm shifts over the years. To me, it's also what makes it so challenging and rewarding.

[ritchiea]

It’s dismissive to call it luddism. I am a big anti-GraphQL voice but in the specific cases where I tend to work: on small cross functional, often full stack dev teams. It’s a layer of formal promises about the API that I find extremely unnecessary & unproductive for small teams that I can see the appeal for at a huge corp like Facebook where frontend devs probably don’t write much or any backend code.

The problem usually isn’t the library itself and that’s true of GraohQL. It’s the cargo culting of GraphQL & other new tech that might be unnecessary or overengineering for your specific use case.

[dmitriid]

> I'm as much opposed to adding more incidental complexity to the frontend as the next guy, but GraphQL has objective purpose and makes a lot of things much simpler

By moving all that complexity to the backend. It's not luddism to call this out.

> Learning new things and doing things better than they were done a year before is an essential part of being a professional software engineer

Yeah, no. It's not "better than they were done a year ago". It's just dumping all the complexity in somebody else's lap, reimplements a bunch of things from scratch, poorly, and calls it progress.