[Lazarus] The future of desktop

[Dmitry Boyarintsev]

The sad thing about HTML that it is destroying itself.
A web-framework consists of probably 4 tags:
<div> (everything is a div)
<a> (just for browser look)
<input type=hidden> (and yes, every other control is just a div, rather
than an input)
<img> is to be replace by <canvas>
Forms are being used just as an ad-hoc data sending mechanism. No-one
relies on browser implementation (due to the war), just write its own JS
engine.

Let's wait for an alternative to the web as it is right now :)
(some other scripting+code language than HTML+JS, that will satisfy
glam-looking requirements better?)
...or build one using Lazarus.

thanks,
Dmitry


On Thu, Nov 28, 2013 at 11:40 AM, Mark Morgan Lloyd <
markMLl.lazarus at telemetry.co.uk> wrote:

> Michael Schnell wrote:
>
>> On 11/28/2013 02:18 PM, Santiago A. wrote:
>>
>>> Perhaps Lazarus should start thinking about a widget "html+javascript"
>>>
>> Some years ago I did some (limited) testing on that behalf, but gave up
>> after some days, seeing that the necessary effort is not limited at all. I
>> do hope that Michael v C is more successful.
>>
>>
>> At home I have a NAS by QNAP..
>> Since the latest update it features a really nice HTML GUI.
>>
>> It nicely can do forms and many Lazarus-like GUI elements and -functions,
>> and it can show status changes really fast (which is not easy with a
>> HTTP-connected, browser-based GUI).
>>
>> I do suppose, they use a "standard" "widget set" for this (EXTJS or
>> something), but I never saw such a thing working this great.
>>
>> No idea how they designed the GUI. It is so complex that I would be
>> astonished if they did not use a GUI designer tool for this.
>>
>> If Lazarus would be able to offer such a capability, driven by the
>> standard GUI design tool (of course taking some limitations into account in
>> that mode), this would be a major argument for doing embedded application
>> with Lazarus. (This was why I did the research at that time.)
>>
>
> Both Borland and Netscape (later Sun) had visual HTML/Javascript builders,
> both got buried. Part of the problem was that both assumed that the backend
> would be their own database and transaction manager, and we all know how
> much corporates like to charge for that sort of thing once they've got
> their foot in the door.
>
> If you're designing a headless system like a NAS, then the terminal type
> that you can rely on people having is pretty limited: an HTML browser or a
> VT-100 terminal (including telnet). A significant advantage of this
> approach is that with care it can be designed to do something sensible even
> if the client can't or won't run Javascript or Java, other alternatives
> such as a desktop app served by VNC fail dismally by comparison.
>
> Once you're talking about an app that runs on the desktop or handheld
> system then the rules are completely different. Perhaps we can make a
> difference by constantly reminding people that it's still possible to write
> portable apps for that environment, and that there can be significant
> performance advantages doing so.
>
> --
> Mark Morgan Lloyd
> markMLl .AT. telemetry.co .DOT. uk
>
> [Opinions above are the author's, not those of his employers or colleagues]
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20131128/65ecbb2b/attachment-0003.html>