We shipped rudimentary support for both HTML/CSS/JS and ECMAScript (QScript) Plasmoids in 4.1. Petri has been working on the HTML based ones and improving that. There is work on a "full" QScript Plasmoid / DataEngine / Runner ScriptEngine set going on in playground, but that work happens in fits and starts at best.
What I'm most concerned about at the moment, however, is the QScript based Plasmoid ScriptEngine currently in kdebase. It's meant to be a minimal approach binding just what is necessary and no more. It currently binds Plasma::DataEngine and provides the basics needed for painting, canvas style.
To take it to where it ought to be bindings for Plasmas::Service, Plasma::Widgets and probably the QGraphicsLayouts are needed. Some additional facilities to load data from the local file system or the network would also be useful.
These facilities can be added one at a time, and given how QScript works they can be done in large part by making sure the proper things are marked as Q_SCRIPTABLE in the Plasma classes. So thankfully making these kinds of "bindings" are far easier and more straightforward than bindings usually are.
The reason this particular ScriptEngine could be rather important is that it comes with no extra dependencies (QScript comes with Qt, after all), quick load times and would enable us to produce a ScriptEngine that is both easily approached (limited API) and easily secured (we can limit what API is available to each Plasmoid at runtime).
If you are interested in helping out with the QScript ScriptEngine, drop me an email. Unlike the MacOS Dashboard work that needed to be done, there are a good number of small targets here that could easily accommodate 3-4 people without problem. Drop me an email if you're interested. (aseigo at kde dot org, in case you don't have it.)
If we can get HTML, ECMAScript and Python together in a good state for 4.2, we will have the ability to offer both flexibility and safety for Plasmoid development. We can start moving people off of C++ in more situations and onto these dynamic languages, both speeding up development time as well as reducing the possibility of crashes.