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 < [email protected]> 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 > [email protected] > http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus >
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
