> the dogma of RESTful APIs consistently push the complexity of data synchronization to the front-end.
Sigh. I guess we'll never clarify this point but... as originally defined, RESTful APIs bear no absolutely no resemblance to modern HTTP APIs that happen to speak content-type: application/json. REST means (quite literally) returning hypermedia representations.
To be clear, the industry adopted a dogma of "HTTP JSON APIs" and called it REST by shear mistake. I'm not just pointing out a naming error - these JSON APIS do not follow REST. They have consistently pushed the complexity of data synchronization to the front end. 100% on purpose in most cases. And we're paying for it. Author nailed that part.
But that's totally different than REST. The REST hypermedia approach has explicitly outlined a viable alternative to this madness! Keep state on the server, make everything a representation of that state, then transfer it as requested over HTTP. The word "REST" had been hijacked to the point where it literally means the opposite of what the author intended.
> The complexity doesn't live inside our tools, it lives inside us
It lives in the requirements of the app. A list with some images is not as complex as a live feed with dynamic popups and smooth page transitions.
The #1 reason FE is too complex is because of the quirkiness of the stack, plus the propensity of companies to scale software using teams of people instead of more software. Web UIs are really extensions of the browser, which has evolved with questionable standards that often seem to be reinventing the wheel. On top of that, as web apps grow in size, companies feel like they need to constantly add more people in order to increase the number of features, but this is only because the non-technical business people are making the decisions.
For any given domain, there are plenty of ways to abstract the problem space in such a way that adding new features becomes a matter of adding some configuration, but this approach is not even considered and instead people are hired and given a smaller slice of the app to work on. This creates improper abstractions that don't "map" well to the requirements, which then adds complexity, which then creates lots of bugs and slows down development, and the response is to add more people, further worsening the problem.
Sigh. I guess we'll never clarify this point but... as originally defined, RESTful APIs bear no absolutely no resemblance to modern HTTP APIs that happen to speak content-type: application/json. REST means (quite literally) returning hypermedia representations.
To be clear, the industry adopted a dogma of "HTTP JSON APIs" and called it REST by shear mistake. I'm not just pointing out a naming error - these JSON APIS do not follow REST. They have consistently pushed the complexity of data synchronization to the front end. 100% on purpose in most cases. And we're paying for it. Author nailed that part.
But that's totally different than REST. The REST hypermedia approach has explicitly outlined a viable alternative to this madness! Keep state on the server, make everything a representation of that state, then transfer it as requested over HTTP. The word "REST" had been hijacked to the point where it literally means the opposite of what the author intended.