The \"classic\" approach to web development has been for some time a thin client and a thick server: the server generates HTML and spits it out for the browser to render only. B
If I understand your question correctly I think you're referring to the kind of development one does with something like ExtJS. With Ext you no longer really write any HTML, but rather design the entire application in mostly JavaScript, using techniques similar to development GUI apps on the desktop.
For the most part modern toolkits have almost eliminated most browser quirks. Although you can certainly still run into cross-browser rendering issues occasionally, it's not nearly as a big of a problem as it would be if you tried to write all the JS yourself. Speed should be acceptable even in IE6, although you will general get better performance in a recent version of Safari, Chrome or Firefox. (I don't know enough about IE7 or 8 to comment).
You brought up a valid point however about URLs and their share-ability. Even outside of the use-case of sharing data this is important for bookmarking locations within the application. There are techniques available for storing application state and being able to reconstruct it, but as far as I know it's still not easy to do. For this reason it makes sense to avoid rich web applications in situations where they are not necessary. Simpler web applications can be simpler to debug, test and maintain.
That said, there are situations where rich web applications make a lot of sense. For example a lot of internal enterprise desktop applications can be rewritten to be rich web applications. They can provide similar look and feel, widgets and interaction patterns as desktop applications making the transition to a web application easier. External facing applications that involve manipulating data (like email/news readers, accounting applications, etc) can also be a great fit.
I've done it by hand. It was kind of a pain, but there is some upside. This is only appropriate for rich Internet apps where a fallback makes little sense. I think we'll see more and more apps that require JavaScript, especially after frameworks like Cappuccino Atlas arrives.
I think it's horrible. Hard to develop. Hard to debug. Hard to get the functionallity you want. I prefer to keep web applications as simple as possible, and go for ordinary GUI applications when anything more complex is needed.
Tools such as Google GWT do what you describe - render much of the client side in javascript. Some of the coarse-grained layout still gets down using HTML, but the interesting bits are done dynamically, client-side.
But GWT uses generated javascript, not hand-written. Doing this by hand is painful.