They use their own UI toolkit called VGUI, the same one they use in HL2 and their other games (https://developer.valvesoftware.com/wiki/VGUI_Documentation). So, there is a layer on top, but in terms of rendering it should be all native. In their games, it uses Direct3D calls, and in Windows I would guess it uses GDI+ or something in the DirectX family.
Edit: Just to be clear, I would consider the VGUI layer to be pretty lightweight. There is no virtual machine for any language runtimes. It is purely a layout engine, with some very basic styling defined mainly by the rendering of images and gradients.
Outside of rendering, from my own experience with using it, there's nothing in particular about it that makes it slow, except that it has no built-in asynchronous facilities in place for you to use. You have to make sure you never block the UI thread.
This is really just a guess of course, but I would pin the slowness on too much IO waiting (ie. poor thread design). To be fair though, Steam in most cases has stayed pretty responsive.
Edit: Just to be clear, I would consider the VGUI layer to be pretty lightweight. There is no virtual machine for any language runtimes. It is purely a layout engine, with some very basic styling defined mainly by the rendering of images and gradients.
Outside of rendering, from my own experience with using it, there's nothing in particular about it that makes it slow, except that it has no built-in asynchronous facilities in place for you to use. You have to make sure you never block the UI thread.
This is really just a guess of course, but I would pin the slowness on too much IO waiting (ie. poor thread design). To be fair though, Steam in most cases has stayed pretty responsive.