That depends on what you mean by DSL. The term is overused, poorly defined, and I haven't seen very many interesting instances of it anyway. I certainly wouldn't describe HTML as a DSL. It doesn't suck for building UIs to such an extent that it didn't take over the world. Who on earth would want to turn HTML into JS? And what does this have to do with Node? There, I've disagreed with everything you said!
To me a domain specific language is a language that has been created on top of another in order to get 'closer' to the problem that is to be solved. HTML is layered on top of XML so I think that warrants calling it a DSL. It also is domain specific in a secondary sense in that it is targeted specifically at communicating layout to a terminal. (layout being the domain). Today that's handled partly by css by I think the principle remains. Javascript has become popular because of being embedded in HTML, now we see it ported to the server side.
> It doesn't suck for building UIs to such an extent that it didn't take over the world.
That's a lot of negations. It is used for building UIs in the same way that we use C to build operating systems, so far we've yet to find something that does a much better job. But javascript feels like a hack to make the browser do things that HTML currently can not, and to see it on the server feels a bit weird (even though it has obvious advantages, one less language to worry about).
With every new iteration of the HTML standard lots of stuff that previously was only possible using javascript hacks becomes part of the HTML spec. I can imagine for instance a 'validchars' property of an input field that would immediately validate characters typed in and would refuse characters illegal for that field. But I think that right now the only way to do that is to use a bit of javascript, and that may be disabled.
What it has to do with node is that node is yet another way of extending the capabilities of the brower, but this time in concert with server side code in a non-standard way that would be better handled by finding a generalized method.
I spent a lot of time building a javascript powered chat environment that would show users as avatars on other peoples website (so you could go 'group surfing' as well as to give guided tours and to interact with other public visiting a website) only to find it broken beyond repair in the next browser iteration.
Most HTML is here to stay and things that are deprecated are usually easily fixable.
I'm not saying 'node' will break beyond repair next week (it's server side after all) but I've learned my lesson (that was 4 months work down the toilet) well enough to be a bit more weary now, JS is an environment that is still very much in development.
