I have nothing but contempt for the current state of web development. HTML/CSS/JS/DOM/AJAX/MIME, not including your server implementation (JS|.NET|Java|PHP) and SQL/NoSQL. I've been asking the question on why we can't migrate HTML,CSS,DOM, and MIME to JSON. It would be a monumental effort for little gain.
But I've also been using Witty, a C++ web toolkit that mimics Qt. Basically, you only get push a DIV element (automatic) and the library takes care of the rest. This is a great step in the right direction. But it is still subject to limitations of HTML/CSS/JS/DOM/AJAX/MIME, and the browser implementations thereof. (The obsoleting of XP and IE6 and the rejoicing of various web devs at not having to support IE6 is what got me on this particular track.) In Qt we have a webkit implementation. (I told you I was going to tie it back to Qt ;-) ) Webkit is client-side. What I am thinking is if there was a server-side webkit that communicated directly (or as close to) the client webkit as possible, over say websockets. In my mind, this would get us closer to using Qt for web apps. If we could program Qt with server side webkit objects (I'll call these subclasses of QServerWidgets) so that we can create the widget hierarchies which communicate to the standard Webkit client-side libraries. Creating a QServerWidget creates the corresponding WebKit widget. I'm no Webkit expert. But I think this would more elegantly replace HTML/CSS/JS/DOM/AJAX/MIME, without having to go through standards processes. And maybe Webkit is bound to HTML/CSS/JS/DOM/AJAX/MIME internally for the time being. But, in the end, if we handled QWidgets and QServerWidgets the same (QPA?) we could code a Qt application and get a web version, a mobile version, and a desktop version from the same code base. I am no means Webkit person, I only have a basic understanding of webkit. Comments? _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
