I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS.

You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM efficient than the baseline you can manage with Chrome, where an empty renderer process takes 23 MB of RAM to achieve nothing and starts so slowly the browser has to cache them in the background.

On the other hand, delivering features your users expect might be a bit harder. Shipping and updating that app will be painful for me, unless I use [plug] https://hydraulic.dev/ to make it easy [/plug], and the styling options are limited to setting solid color backgrounds on things. Things the product manager views as basic, like adding a dark mode, will take a surprising amount of effort. The app is likely to be more crash prone than the web app due to all the manual memory management required. Text zoom won't work. I'll have to write in C or maybe C++ if I'm feeling extravagent.

So there's got to be a balance somewhere. Features do matter.

But what even is good code?

As an infrastructure guy i see my fellow software engineers endlessly debating and bikeshedding on anything but speed and memory consumption.

I see them arguing about functional vs object oriented, immutable data structures, test driven development, agentic bs, this or that interpreted language… never about reducing memory consumption .

If you ask your boss, it will most likely be whatever spaghetti code which ensures the contract gets signed on time.

The boss doesn't care if the developer needs 10000 libraries for the submit button.