This is a great idea, and this is part of an overall trend to use compilers to solve application-level problems (e.g. Svelte), which I think is a very powerful trend overall. It also is similar to something like Apollo for GraphQL, though that just handles the client + managed networking part.
In this particular case, the ultimate problem being solved is that a relatively simple application can become overly complicated when split across a network into a client and server. This one problem has many different solutions, and you can see it at the root of many arguments. For example, this is the same problem at the root of SPAs vs. server rendering. With server rendering, you simply avoid this problem, which sounds like it would be an obvious choice except there is a major downside: you lose out on all control of the client state. That may or may not bother you, in which case that tradeoff might be worth it.
But for those that want control over the client, this is a great alternative. You give up direct control to the DSL, but it’s still managing a richer client state under the hood.
What I would love to see out of this is to not have to annotate with the client and server parts, and have that also be detected automatically. That’s a much harder problem, there’s been a lot of research there, but that would allow the application developer to think less about the underlying architecture and have that be handled entirely by the compiler.
I imagine you’d want to have explicit control of what’s running on the server or client for at least some cases. Authentication and authorization are a couple of examples that come to mind. However, I definitely agree that having the compiler figure that out by default would be handy. That way you could opt into marking these things explicitly as needed, and not worry about it otherwise.
Not sure what the limitations there are, but there is a fundamental limitation in UIs which is how much info a user can effectively process. I imagine that UX would become a problem long before there would be a technical limitation here.
This is a great idea, and this is part of an overall trend to use compilers to solve application-level problems (e.g. Svelte), which I think is a very powerful trend overall. It also is similar to something like Apollo for GraphQL, though that just handles the client + managed networking part.
In this particular case, the ultimate problem being solved is that a relatively simple application can become overly complicated when split across a network into a client and server. This one problem has many different solutions, and you can see it at the root of many arguments. For example, this is the same problem at the root of SPAs vs. server rendering. With server rendering, you simply avoid this problem, which sounds like it would be an obvious choice except there is a major downside: you lose out on all control of the client state. That may or may not bother you, in which case that tradeoff might be worth it.
But for those that want control over the client, this is a great alternative. You give up direct control to the DSL, but it’s still managing a richer client state under the hood.
What I would love to see out of this is to not have to annotate with the
clientandserverparts, and have that also be detected automatically. That’s a much harder problem, there’s been a lot of research there, but that would allow the application developer to think less about the underlying architecture and have that be handled entirely by the compiler.I imagine you’d want to have explicit control of what’s running on the server or client for at least some cases. Authentication and authorization are a couple of examples that come to mind. However, I definitely agree that having the compiler figure that out by default would be handy. That way you could opt into marking these things explicitly as needed, and not worry about it otherwise.
I am cautiously optimistic that this is going to be really big. I guess the real question is: does it scale to arbitrary domain complexity?
Not sure what the limitations there are, but there is a fundamental limitation in UIs which is how much info a user can effectively process. I imagine that UX would become a problem long before there would be a technical limitation here.