As a backend developer I can't help but feeling we have gone full circle.
As in, how is this effectively different from regular server side HTML? I know this is rendered on the client, and I'm not doubting it's usefullness, but what advantages does this setup have?
I also guess their demo app isn't representative of what problems this setup intends to solve:
The example whould have been extremely simple to implement in JS/TS on the server side, it would also be much faster and have better concurrency, caching and scalability options.
While ES6 proxies are really nice, I came across this experiment (1) and their tests showed that ES6 proxies can be very bad at performance. I could reproduce the test case. Not sure whether this GraphQL client has some way to optimize.
The "magic" part is only a small portion of gqless. For 1.0, there will be an option to "use plain queries".
I've tried re-inventing everything - but it's also innovating in the reactive, query-optimization, local state and cache areas.
I'm excited about the fluent GraphQL ecosystem and to see where it goes! Using the nice syntax of GraphQL does get lost a little bit ofcourse, but having the benefits of being able to "compose" to some degree and not dealing with strings is nice.
I also guess their demo app isn't representative of what problems this setup intends to solve:
https://youtu.be/wM5KDPG9Ugk?t=2866
The example whould have been extremely simple to implement in JS/TS on the server side, it would also be much faster and have better concurrency, caching and scalability options.