It would be hard to imagine a worse model for user interface development than HTTP. Would you use a GUI framework where every event from every widget in your application was handed to you at once, periodically, as a large hashtable full of strings? Where every time a single piece of data changed you had to regenerate a textual description of the entire interface? Where the event-based architecture was so strict that you couldn't ever, under any circumstances, open a modal dialog box and wait for it to return an answer? Those are the costs of using the web browser as a client platform, and, by and large, we accept them. The dominant paradigms of web development -- CGI, Servlets, Server Pages -- do very little to hide or circumvent the low level realities of HTTP, and as a result, web applications are fragile, verbose, and ill-suited to reuse. Smalltalk can do better. More than that -- Smalltalk is uniquely suited to do better. To date, we've followed conventional wisdom and built Smalltalk implementations of the same old paradigms, providing familiarity and compatibility. But by throwing these away, Smalltalk can instead provide an overwhelming competitive advantage. By leveraging Smalltalk's particular strengths, we can abstract away the ugliness of browser/server interaction in ways that simply aren't possible in other environments, and profit greatly by it. For all its limitations, the web is fast becoming the most important deployment platform for many classes of application. The Java, Perl, PHP, and .NET worlds, to name a few, are pursuing it agressively. Many of us are going to have to play their game -- but we don't have to play by their rules.