The ideal solution in that case is NOT frameworks. It's to have runtime patches available that make your code run predictably on all browsers. That way if you need to support a new browser, you just add a new patch so that it functions predictably. (If necessary.) Since such patches tend to function based on whether or not a particular feature exists rather than the browser itself, they automatically deactivate when the browser maker finally gets it right.
So how do you know what DOM elements you need to write run-time patches for? Most likely the answer is you either (A) had a problem with something behaving correctly in browser X or (B) you know browser X has certain deficiencies when it comes to supporting the JavaScript standard. In both cases the developer has to have knowledge about how different browsers behave for different elements in order to know that they need to write a run-time patch to test if a particular DOM element exists or not. Otherwise if you just assume you are going to write run-time patches for all DOM elements you are "not quite sure about" then you will have a lot of extraneous code.
The point of a lot of frameworks including GWT is that the application developer does not need to keep up with the rapidly changing compatibility issues of all the different browsers. This significantly decreases development time and ensures that the code the developer writes is widely compatible across the major browsers.
Now there still might be compatibility issues even using a framework, b/c a framework may not have knowledge of all browser compatibility issues and in these cases you will still have to track down the issue yourself. The point is that these cases are pretty rare using the frameworks and across a whole project the time savings benefits will outweigh the time developers spend tracking down these rare issues.
I'm a big believer in the 80/20 or 90/10 rule, and I think the odds are actually a lot better than that when using frameworks for your code.
