Some programming languages achieve epic influence without necessarily achieving universal adoption. Lisp was phenomenally influential, but has remained in an AI niche; APL gave rise to notions of bulk processing and hidden parallelism without having much uptake outside finance. Smalltalk's influence has been similar: it re-defined what it meant to be an interactive programming environment and laid the ground for many modern interface concepts, as well as giving a boost to object-oriented programming that prepared the way for C++ and Java.
So why does no-one use it any more? Partly it's because of its very interactivity. Smalltalk -- and more especially Squeak, its most prominent modern implementation -- are unusual in basing software around complete interactive images rather than collections of source files. This isn't inherently poor -- images start immediately and encourage direct-manipulation design and interfacing -- but it's radically unfamiliar to programmers used to source code and version control. (Squeak provides version-controlled change sets to collect code outside an image, but that's still an unfamiliar structure.)
But a more important issue is the all-or-nothing nature of Squeak in particular, and in fact of novel languages in general. If you want to use Squeak for a project, all the components really need to be in Squeak (although it can also use web services and other component techniques). If you want to integrate web pages, someone needs to write an HTML rendering component, HTTP back-end and the like; for the semantic web someone needs to write XML parsers, triple stores, reasoners and the like. You can't just re-use the ones that're already out there, at least not without violating the spirit of the system somewhat. That means it plays well at the periphery with other tools, but at its core need most of the services to be written again. This is a huge buy-in. Similarly Squeak provides a great user interface for direct manipulation -- but only within its own Squeak window, rendered differently and separately from other windows on the screen. These aren't issues inherent to Smalltalk -- it's perfectly possible to imagine a Smalltalk system that used "standard" rendering (and indeed they exist) -- but the "feel" of the language is rather more isolated than is common for modern systems used to integrating C libraries and the like. At bottom it's not necessarily all that different to Java's integration with the host operating system, but the style is very much more towards separation in pursuit of uniformity and expressive power. This is a shame, because Smalltalk is in many ways a perfect development environment for novice programmers (and especially for children, who find it captivating) who are a vast source of programming innovation for small, focused services such as we find on the web ad on smartphones.
I know purists will scream at this idea, but to me it seems to go along with ideas that Smalltalk's co-inventor, Alan Kay, has expressed, especially with regard to the need to do away with closely-packaged applications and move towards a more fluid style of software:
The "no applications" idea first surfaced for me at PARC, when we realised that you really wanted to freely construct arbitrary combinations (and could do just that with (mostly media) objects). So, instead of going to a place that has specialised tools for doing just a few things, the idea was to be in an "open studio" and pull the resources you wanted to combine to you. This doesn't mean to say that e.g. a text object shouldn't be pretty capable -- so it's a mini app if you will -- but that it and all the other objects that intermingle with each other should have very similar UIs and have their graphics aspect be essentially totally similar as far as the graphics system is concerned -- and this goes also for user constructed objects. The media presentations I do in Squeak for my talks are good examples of the directions this should be taken for the future.(Anyone who has seen one of Kay's talks -- as I did at the ECOOP conference in 2000 -- can attest to how stunningly engaging they are.) To which I would add that it's equally important today that their data work together seamlessly too, and with the other tools that we'll develop along the way.
The use of the browser as a desktop isn't new, of course: it's central to Google Chromium and to cloud-friendly Linux variants like Jolicloud. But it hasn't really been used so much as a development environment, or as the host for a language that lives inside the web's main document data structure. I'm not hung-up on it being Smalltalk -- a direct-manipulation front-end to jQuery UI might be even better -- but some form of highly interactive programming-in-the-web might be interesting to try.