[Lazarus] The future of desktop
darekm at emadar.com
Fri Nov 29 23:15:53 CET 2013
> I have made a small test program, by hand, with no LCL and no RAD
> utilities. It is boring and a lot of dirty work, but not difficult (If I
> could do it, it can't be difficult, my programming skills are rusted
> after years of programming sales reports). I have taken a look at QT
> widget, and perhaps it shouldn't be that difficult integrating web with LCL.
I've made myself such web widget set, which have the same API as LCL.
Thus its simple to recompile desktop application to gain web application
its huge (>1000 forms) program which is use by hundreds user day by day .
I've mention about it a few times, i work with it from years, and I
think that HTML5 + Pascal is the best tool to web application.
> Nevertheless I have found issues that have little to do with RAD, they
> are related to the concept of remote GUI itself.
> Let's suppose you have a checkbox that when cheked must enable some
> controls. In a common desktop the event is sent to the application, and
> application process the event and tells the GUI which controls must
> enable. But if the application is remote, the roundtrip may take 30 ms,
> add a cascade of events triggered and you get that you uncheking a
> chekbox the application gets stalled for a moment or more (I read
> somewhere that to get the "no time" perception it must react in less
> than 100ms). I said 30ms but it could be 200ms depending on the
> connection, and then the moment may become a second.
No time perception is under 300ms.
No one controls must wait to response from server to change its look,
this do JS lying under each. But of course, each user action is
transmitted to server and respond carry information of look other
controls. In other words: each control take care only of itself, no
business logic is include in JS, rest is done by server.
> The solution to this problem is quite easy, and it is what many web-GUI
> interfaces do: Move part of program to the client side, so they send big
> for me as developer. What I intend to avoid, when I write an
> application, is having to write half application in pascal and half
This is outlined, as I do: 95% in pascal and 5 in JS+CSS+HTML
> Probably I'm demanding too much, there is no way a component can say "I
I dont send JS for controls, only some HTML like (real copy)
<td colspan="2" xcol="19"><div id="dfaF5FB9B20" class=" fieldhint
fieldliczba"><input id="faF5FB9B20" type="text" onchange="return
rest is done by JS + CSS
by the way: CSS id great, allows for separation of look and behavior,
its far better than LCL
> Beside this, there are concerns with http protocol, it is document
> oriented, not connection oriented. For example, unless you keep the
> connection open, every event from GUI to application, even a single
> that are sent with every connection. There are workarounds, comet, html5
> websockets, perhaps with some drawbacks.
This is not problem. Today network is fast, sending packet information
under size of frame (<1400bytes) has no overhead.
Pooling : only 1 request for 15 s, its under 0.001% overhead.
Much difficult is architecture of HTTP server. I need modal windows,
thus I use 3 levels of thread. If add logging, timers or background task
then levels count. But its work the same as on desktop (only nicer)
More information about the Lazarus