Project modularization with webassembly
Added by Trigve Siver over 5 years ago
Hi,
I have some thoughts about Wt so I managed to post it here.
We're using Wt in our application as "web application plugin". That is, interaction with our application is through the web.
We also have another client-server plugin using custom thin client (small executable connecting to server, all logic in server).
These two plugins does overlap, because a lot of the code is "logically" same in both plugins and therefor we just want to merge it somehow, so that there is only 1 server implementation and one could connect using custom thin client or using web browser. The one option is to create custom front-end using some existing framework. But all the frameworks are based on JavaScript which we want to avoid if possible - the one reason is that we don't want to re-implement the front-end stuff in another language, because it defeats the whole purpose of merging the plugins).
I was also looking for some C GUI libraries that could be compiled to webassembly, but the only one mature is Qt, but there are some caveats for us (licensing, rendering of widgets, ...).
Today Wt is monolithic in a sense, that back-end and front-end are tightly coupled. So I was thinking that if Wt could be separated to front-end (C -> webassembly) and back-end (C), we could use the front-end part only. But I don't know it is really feasible. This is how I imagine, how it could work:
The whole back-end stuff would handle the HTTP/websocket stuff + there would be some "widgets" server layer (C widgets API need to be separated for client and server part). So the server part would have 2 "libraries", the pure back-end and the widgets stuff.
Then the front-end would have some generic widgets layer, which could implement only widgets without any logic (for instance WTableView in front-end would implement rendering the table, WButton would handle also click events). This generic layer which would be compiled to webassembly could be use as a solo front-end, without using Wt back-end.
The second "library" in front-end would be some form of coupling with Wt back-end. So the widgets from the generic library would be reimplemented (inherited) to be able to communicate with Wt back-end - so it would operate in the same manner as todays Wt. For instance, WButton click signal would be handled in this second library and the signal would be forwarded to the Wt widgets back-end where it would be handled accordingly.
Would be something like this even possible?
Thank you
Replies (3)
RE: Project modularization with webassembly - Added by Trigve Siver about 5 years ago
Bumping the question ;)
I've just came across the Blazor (https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor) yesterday, which could be (also) used for client-only UIs in .NET with support for webassembly as output.
I was thinking something like this (in my first post) for Wt, where there is some fronted for creating the client-side UI and then backend (optional, like ASP.NET in case of blazor). Blazor does have some additional syntax for custom stuff in .html.
What do you think?
RE: Project modularization with webassembly - Added by lm at about 5 years ago
Dividing the front end and back end is your business. You're right that with WT, it's very easy to combine business logic and presentation code (like PHP for example), but as always, industry best practices dictate against doing so. If you want to divide into separate processes (for instance, a business logic daemon with which the front end web server process communicates), that's perfectly defensible, and not too difficult once you decide on an inter-process communication mechanism.
I'm not sure why you're talking about web assembly though; it seems tangential to this conversation. Whether WT ships javascript or web assembly to the browser, choices about dividing the code between presentation and business logic will remain unaffected. If you would like to see WT ship web assembly instead of javascript, I don't know of any effort in this direction. Perhaps you would like to start a new C framework for web servers that ships web assembly? I would be interested to see it! Of course, it should be at least as good as WT, and that's a tall order.
RE: Project modularization with webassembly - Added by Trigve Siver about 5 years ago
I don't know if you read my first post carefully, but I'm talking here about the Wt's front-end and back-end separation, not my application (my application is perfectly divided between back-end and front-end, as written in first post). What I'm talking here about, is to be able to take only the front-end (client side of Wt), such as widgets and use it with my custom back-end.
Webassembly is the essential thing here, because if the Wt front-end would be "separate" library in C then webassembly is the only solution to this problem AFAIK.
In short, I would like to use C with Wt client code to build the front-end.