While I agree in general, I think you're pointing at the wrong target here. It's not that "web programmers are doing something that's definitely not cool for our current RAM budget". The javascript is loaded and probably jitted to a smaller space than its text (depends on the number of paths, etc - I'm ignoring lots of stuff here), the actual text passing through the wire is also pretty small. So where's the memory going? All the supporting stuff...

There's the whole javascript framework with it's own allocator, memory pools which will stay around for a long time. Some of the browser elements use the same kind of vm to actually display the UI to you, adding some more mem usage. Then there's the whole page which had to be read, parsed into a tree, processed to create appropriate model for display (all stages are preserved in an editable way). This has to be a live model for the whole time, since javascript might need to interact with it - you can't just flatten it into a screenshot and display that. Now the images - they also need to be loaded and decompressed for display. Also the text isn't that simple - there's the whole engine behind loading fonts, analysing each letter / pair / triple / ... for special spacing rules to be applied. There are multiple glyphs, font variants, sizes, etc. to rasterise. That text needs to be distributed properly inside of the DOM model generated above. That text flow actually affects the model again - they're linked, so they get processed again (text metrics need to be recomputed on each page resize, which may make some elements longer/shorter). Then the theme goes on top of this - since the application displays itself, the needed libraries / theme elements will be loaded too. But of course not all browsers use the theme from OS for displaying the form elements, so another layer needs to be loaded here. .... I could go on forever about elements which are needed for rendering the page.

So yes - lots of that could be much lighter. Lots of that could be made into modules or pulled some levels higher to make them more general. Lots of that might be just a result of sloppy coding noone ever got to fix.

But just remember that what you're actually using is a system on top of a system on top of a system on top of... If you used gopher on a real 80x25 term you'd use kilobytes. If you used first web browser with no image support and no scripting, you'd be under megabytes. But you don't - you're looking at a realtime rendering of 10 different models coming together and interacting with each other with next to no lag. And it all probably renders with hardware support to give you a very smooth scrolling experience. So no, web developers themselves have almost nothing to do with this whole mess. Unless they made a silly mistake and are leaking memory like crazy... they're not the ones to look at first.

(I simplified in many places, not all facts are relevant to every OS/browser combination, etc. just trying to make a point here)