4 ms·

I'm not a fan of this type of architecture for many reasons. One of the reasons is the difficuly of organizational coordination, which is funny because a few ye

I'm not a fan of this type of architecture for many reasons. One of the reasons is the difficuly of organizational coordination, which is funny because a few years ago Airbnb had a blog post about how they gave up on React Native and one of the reasons they gave was the difficulty of organizing changes across teams, but with SDUI that problem is worse, you need tight coordination across many teams to push features. One way to think about it as engineers is how we prefer decoupled systems with clear interfaces and boundaries. SDUI is the opposite of that, it's tight coupling between all the clients and the backend, changes to your UI are split across a bunch of teams and systems. There are also a bunch of other problems, off the top of my head: - difficulty caching resulting in bad performance - bad performance because you end up unnecesarily reloading entire screens just in case one small piece of UI changed - difficulty taking advantage of unique platform features - difficulty handling animations or smooth transitions - client engineers lose understanding of the business data model, and motivation since all the action is in the backend. - hard tracing bugs across frontend to backend - doing UI in gql schemas is awful. sdui+gql are opposite goals, sdui wants dumber clients gql wants smarter clients. When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance, youre basically sending your entire UI layout and receiving it back filled with data. - complexity, difficulty hiring, not being able to use the latest best practices and architectures - consistency across platforms is bad as a fundemental goal, users don't care since they typically use one platform. Consistency across mobile and web is actually bad UX in many cases.

whoevercares 5y ago
But we do have a use case for this where the UI has to be scaled up by a total different group of people who are domain experts. Without such abstraction to generate the UI, the velocity will be terrible with a small UI front-end team. I think this makes sense when you have a need to allow pluggable UI components for something that is domain specific, with rather stable interface and has to be scaled up by non-Frontend folks
wonnage 5y ago
It's weird that clients have no idea what a page is supposed to look like until the server tells them. I mean, they could guess or cache the last layout they got, but it makes stuff like partial loading states a lot harder. This kinda defeats the purpose of a SPA - a SPA lets you have instant page transitions through client-side rendering, but now you can't do that without a bunch of complicated prefetching because you need the server to tell you what the next page is. > When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance I think the first part of your sentence solves the second - if the client is always requesting the same set of fields, you can probably give the query a name and pass that to the API instead of the actual giant schema. Overall I think this sort of pattern is still valuable because shipping around fragments of HTML to update an existing document sucks, especially if multiple branches of the DOM are changing. And it won't work on mobile. Also at the end of the day, this "server driven" UI is still a lifeless JSON blob that needs to be converted into HTML through giant JS blobs on the client. It seems really convoluted to download a description of the UI, convert it to React components, and then let React convert that to HTML. The new React Server Components project is intriguing, since it lets server-side React code render updates directly to the React runtime running in the client.
hitekker 5y ago
This comment on SDUI is the most insightful one I've read yet, and I'm surprised it isn't at the top of the page.

whoevercares 5y ago

But we do have a use case for this where the UI has to be scaled up by a total different group of people who are domain experts. Without such abstraction to generate the UI, the velocity will be terrible with a small UI front-end team. I think this makes sense when you have a need to allow pluggable UI components for something that is domain specific, with rather stable interface and has to be scaled up by non-Frontend folks

wonnage 5y ago

It's weird that clients have no idea what a page is supposed to look like until the server tells them. I mean, they could guess or cache the last layout they got, but it makes stuff like partial loading states a lot harder. This kinda defeats the purpose of a SPA - a SPA lets you have instant page transitions through client-side rendering, but now you can't do that without a bunch of complicated prefetching because you need the server to tell you what the next page is. > When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance I think the first part of your sentence solves the second - if the client is always requesting the same set of fields, you can probably give the query a name and pass that to the API instead of the actual giant schema. Overall I think this sort of pattern is still valuable because shipping around fragments of HTML to update an existing document sucks, especially if multiple branches of the DOM are changing. And it won't work on mobile. Also at the end of the day, this "server driven" UI is still a lifeless JSON blob that needs to be converted into HTML through giant JS blobs on the client. It seems really convoluted to download a description of the UI, convert it to React components, and then let React convert that to HTML. The new React Server Components project is intriguing, since it lets server-side React code render updates directly to the React runtime running in the client.

hitekker 5y ago

This comment on SDUI is the most insightful one I've read yet, and I'm surprised it isn't at the top of the page.