Hi, It's a different way of working, and the answer to this mail should be a whitepaper on its own. It's not that I claim that template-based design is bad; there are situations where it is preferred over a GUI style approach. But Wt was the result of frustration with the shortcomings of template based design when you're building highly interactive web applications, the kind of applications that used to be found on the desktop but are now also more and more found on the web. Wt is aimed at complex web applications, and the complexer your interface logic is, the more you'll benifit from Wt's GUI based approach.
As you point out correctly, Wt has a strong advantage when the user interface changes dynamically. That is not just for changing style classes, but also when the widget tree needs changing: actions from the user can have significant implications on the contents of many widgets on the screen, or may change the entire screen layout. I admire the people that bring up the patience to do this kind of DOM tree editing by hand, by issuing JavaScript commands based on data they receive from interaction with both the server and the user, keeping track of string-based ID's and taking into account every browser's quirks, but I think Wt's approach is far more convenient. A programmer should think about the program logic rather than about how to edit a DOM tree and how he organized his DOM element IDs. Most template based frameworks are also page-based frameworks (i.e. the framework generates an entire page), enriched by JavaScript and AJAX components where the user foresees it explicitly for the benefit of better interactivity by avoiding full page reloads. In Wt, every update is always JavaScript and/or AJAX enabled, so you will never have the flicker of full page reloads, nor the associated increased delay, server load or bandwidth. In some cases, you can even optimize the server roundtrip away (like www.webtoolkit.eu does, for example). And, also important, Wt does not depend on JavaScript or AJAX. If it is available, Wt uses it, and otherwise it falls back on full page renderings. Even in times that mobile browsers support JavaScript and AJAX, this is still important, because search engine bots don't, and we all agree that SEO is kind of important to certain applications. SEO means more manual work on page-based frameworks that benefit from JavaScript and AJAX (you're practically writing your site twice), and comes almost for free with Wt. Wt only communicates minimal user interface updates to the browser or to the server. It's pretty natural to implement that in our GUI based approach, much less natural in a template based approach. But why is that important? - Every user event (button click, mouse click) results in 1 request to the server (not counting fetching of new images or possibly other resources), no matter how much is to be updated on the screen. Trans-Atlantic round trip time on the internet is up to +-150ms. Not bad. Often on template-based solutions, you have to issue multiple REST-requests to several databases, which are all serialized one after the other, and then the round trip times adds up quickly to something unpleasantly large. And that's just the round-trip time. You may also consider the load on the servers of these extra requests (if your user base is large enough to make it matter) - Wt minimizes communications with the server in terms of bandwidth. Less communications = less to interpret in the browser = faster response. If it matters: the small JavaScript updates are gzipped by default, which also saves extra bandwidth. - You don't need to design online interfaces for your databases that can be queried from within your JavaScript (AJAX updates through JSON queries, for example). It's less coding work on the server: you simply don't need these components. It's also more secure, because you don't have to worry that a smart kid will query and copy all of your databases by issuing creative queries manually. And you also don't need to implement access control, because the interface is simply not there. Increasing the abstraction level to something we've been using for years in the GUI development world has advantages, some of which we didn't even consider before we started. Wt knows, for example, because it attaches semantics to its widgets, which widgets contain text (as opposed to JavaScript). All text is filtered agains XSS; it is a function that is built into the core of Wt, and you don't have to worry about it as a developer. Talking about security, Wt knows exactly what events can be generated by the browser at any given time, and will reject all events that were not expected from the displayed widgets. You may or may not like the clean OO design of Wt, and the ability to reuse widgets by composing complex widgets in terms of simple ones, and instantiate the complex widgets wherever you want in your widget tree, also without having to worry about double-used DOM IDs and the like. Not having to worry about the underlying technology is, by the way, also a point of Wt, which will probably not appeal to a seasoned web developer, but it matters to many. Do we really want to think about using POST or GET or PUT or whatever? If we want to pass data as form variables or as arguments in the URL? Who wants to be proud of knowing all the browser quirks? Wt successfully hides most browser differences from the developers. Compare it to using Qt on the desktop instead issuing native X11 commands. If you know X11, you (may) not mind to do it, but the alternative is much more appealing. Just like Qt is ported to serveral OSes by now, the users of our toolkit did not change a word in their source code to support Chrome or IE8 - upgrading to a new version of Wt is all it takes. I will stop here, but I don't think I'm halfway through with this post. We'd really have to write the whitepaper that I mentioned at the start of this message ;-) I Hope this answers at least part of your question. In short: you will be able to write more complex applications, you will write them faster, the result will be better and future-proof. Best regards, Wim. 2009/7/8 Shadowcat <[email protected]>: > Ok, first, let me say, this is more a question of comparing two > different approaches than of comparing two different frameworks. I > don't know how many of you are aware of tntnet's existence, but it's > a... competing? framework for using C++ in web design. The biggest > difference between tntnet and witty, and the one I want to explore, is > that it uses a template-based design (like PHP, Ruby on Rails, etc.) > rather than the GUI-based approach of witty. The reason that I'm > sending this message is that, as one more familiar with the tntnet > approach than the Wt approach for web design purposes, I'm having > trouble seeing the advantages of the GUI design. It seems to me that > the template design is faster, for one who already knows HTML, than > learning the Wt API. But, I've been reading some of the list archives, > and I see a lot of you complain about the template design, but no one > has (as far as I've seen) elaborated on WHY the template design is bad. > > I do see one benefit to the GUI design - the ability to dynamically > change the properties of a given widget using (for example) > WWidget->setStyleClass(). I can definitely see the benefits of that, > but I'd like to know more on the pros and cons of GUI-based design for > web, as opposed to template design. And I want to know both "Why is GUI > design good?" and "Why is template design bad?" For those who are > unfamiliar with tntnet, the code is also pre-compiled, just as Wt's is, > so there's no overhead involved in the parsing - or if there is > overhead, it should exist only during the compile. > > I see a lot of good things that I like about Wt - the ability to deploy > under Apache as a FastCGI script, for one. I'd like to continue > exploring Wt as a possibility, but at current, I'm seeing the template > design as an easier option that will shorten development time, and that > alone is making me lean toward tntnet even though I see the > capabilities, documentation, support, deployment options (I don't > believe tntnet can be deployed on win32), community, reputation, > history, amount of development, and so on, all seem to be better on Wt's > end. So, basically, what I'm getting at is... convince me otherwise! I > know everything I hear will be biased toward Wt, but that's a good > thing, because I want to hear arguments in Wt's favor; I'd rather use > Wt, if I can find a way to justify the perceived extra development time > to my employer, or if I can be convinced that the development time would > not, in fact, be that much longer. > > Thanks! > Shadowcat > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
