Donald Knuth is credited as once saying "Premature optimization is the root of all evil". I think the question you're asking here is well intentioned John, however misguided. Whilst performance is important we're often blinded by it's supposed benefits as developers and forget more important concepts like separation of concerns. This is the key design principle that should be considered here, not performance. As you'll also see though there are some nice performance benefits in taking steps to keep things separate.
Setting a style in CSS allows for the presentation aspects of the application to be nicely decoupled from the application code. Using CSS over code however is beneficial for a number of reasons: 1. It reduces the amount of code you have to write. This cannot be understated enough. In browser land less code == better performance. The vast majority of AJAX/RIA performance shortcomings have nothing to do with running code, but rather the time taken to download and parse your JS (check out the YSlow plugin for Firebug if you're in any doubt as to the truth of this statement...oh but I must warn you, it will hurt your feelings). So by doing the right thing in keeping your different concerns separate you actually win when it comes to performance. 2. It keeps your code clean and focused on solving the business problem at hand. When it comes to maintenance (which we all learn at uni is actually 80% of any application's total cost over its lifetime) there's nothing worse than trying to pick your way through a veritable minefield of presentation related cruft in an attempt to fix a logical problem. One wrong move, one misunderstood line and BAM, you've broken your carefully crafted interface. This is part of the reason why separating your concerns is so valuable, in a way it's your insurance against complexity. If you can adequately separate things you're effectively confining the risk to a single discrete, and usually well understood unit of functionality. 3. You can modify the look of your application without touching your code. >From a straight development perspective this is a real time saver. If you're like me and have to develop large parts of your app in situ inside an existing web application you don't have the luxury of using the Hosted Mode browser for the home stretch. If you insist on putting all of your styles inside your code you're stuck with a total recompile (which for me takes up to a minute) before you can see if your change was successful. Painful. Further down the track if your client changes their mind and wants something changed, say a particular color or font, it's really nice if you can make the change without a recompile. With every code change/ recompile there's always the possibility that you will break something that was previously working. Not good when you're working on something mission critical, or high availability. 4. CSS style are computed natively. Again this is a performance win. Anything that can be carried out natively by the browser is going to win over interpreted code. Sure some JS VMs like TraceMonkey and Squirrelfish can analyse your code and improve execution speed (and in some cases surpass native performance), however the issue here is that this on the fly optimisation doesn't come free. This is really only beneficial for repetitive or frequently run pieces of code which may be aggressively optimised. Styles for the most part, bar dynamic ones (e.g. setting width in animations), don't change often enough for this to be of use. A common strategy which I use in real life is to apply classes to absolutely everything that could require styling. Then when I start the process of pulling together the look and feel I simply load the page, start analysing the page structure and the class names, then write my CSS. You'd be surprised how much flexibility you have and how quickly it all comes together. Regards, Dave On Mar 10, 5:59 pm, Vitali Lovich <[email protected]> wrote: > GWT is fairly complex - I'm guess the compiler does a lot of optimization > for you and will make that decision for you. For instance, if you set the > width to a constant, it might decide it's better to have that in a css style > sheet, or as actual javascript manipulating the DOM. > > I'm not saying that's whats going on (I haven't looked at the all the > specific optimization techniques the compiler does), but that it's > possible. From a maintenance point of view though, I think (which means > little given my limited web-dev experience) is that it's better to maintain > your CSS separate. > > As for dynamically applying styles, it is called *cascading* style sheets > for a reason. As far as I know, it's easy to overlay additional CSS to a > page. This also why some people like to maintain their own stylesheets > within their browser. > > On Tue, Mar 10, 2009 at 1:02 AM, Ian Bambury <[email protected]> wrote: > > My approach is to set in code if it would screw things up if anyone were to > > play about with the settings, and set in style sheets if you would want to > > let people play about with them. > > So if you need a widget in a cell-panel to fill the cell, set it to 100% in > > code, but set the background colour in a style sheet, for example. > > > You don't want designers messing with stuff which they can only screw up, > > but on the other hand, you don't want to have to recompile and upload > > everything if you are asked to make some heading a bit bigger. > > > Performance wise, I couldn't tell you, but I've never noticed a difference. > > > Ian > > >http://examples.roughian.com > > > 2009/3/10 John H <[email protected]> > > >> In general, for better performance. Would you rather > > >> public SomePanel extends Panel { > > >> public SomePanel() { > >> setWidth("100px"); > >> setWidth("100px"); > >> ............ > >> } > >> .......... > >> } > > >> OR > > >> panel-style { > >> width: 100px; > >> height: 100px; > >> } > > >> I tend to try setting every css style attribute during the creation of > >> a panel object just cause I think it's more readable and more flexible > >> to organize code outside of CSS style sheets. But is this a better > >> approach trying to achieve better performance or not or does it really > >> matter? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
