Your point is valid, but Liaison allows you to build different layers if you wish.
If you worry about cluttering the business logic and want to clearly separate the exposed API, you can expose subclasses of your domain models instead.
If you worry about cluttering the business logic and want to clearly separate the exposed API, you can expose subclasses of your domain models instead.
Liaison and tools like it essentially create a monolith exactly where something is screaming to be two separate services. You want to be able to deploy versions of server side and client side code independently. You want to be able to ensure you don't break clients that have web pages open when you deploy the new server version. You want clients to be able to run where JS isn't available.
About interoperability with non-JS environments, I wrote an article about that: https://liaison.dev/blog/articles/How-about-interoperability...
If your goal is just a brain workout then by all means keep going with it. But if you're looking to do something that gets some larger adoption, then I'd probably wrap this up and move on to the next thing.
(Not that you asked my advice, or that I'm in any way qualified to give it)