[Lazarus] The future of desktop

[Dariusz Mazur]

> 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
> javascripts to the client. No objection, I don't think it's a big deal
> to send javascript libraries to the client, as long as it is transparent
> for me as developer. What I intend to avoid, when I write an
> application, is having to write half application in pascal and half
> application using javascript. I want to write the whole application in
> pascal and let the libraries use javascript or whatever they want.
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
> will convert this few lines of code into a javascript and send it to the
> client"
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 
chk('aF5C5E030','faF5FB9B20');" value=""></div></td>

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
> byte,  must send a lot header information, let alone if you use cookies
> 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)


Darek