Deprecate (remove?) HEADLESS option

[RReverser]

During #20531 I noticed that we have headless.js & headlessCanvas.js, which led me to discovering HEADLESS option I didn't even know existed:

If 1, will include shim code that tries to 'fake' a browser environment, in
order to let you run a browser program (say, using SDL) in the shell.
Obviously nothing is rendered, but this can be useful for benchmarking and
debugging if actual rendering is not the issue. Note that the shim code is
very partial - it is hard to fake a whole browser! - so keep your
expectations low for this to work.

It seems it has bare-bones support for emulating browser environment and it was added before browsers provided their own headless variants. Last update (not counting syntax modernisation or licenses) to the relevant code was in 2015.

Nowadays Chrome and Firefox provide headless mode out of the box, which will be much more feature-complete and representative of real-world behaviour for stated goals ("benchmarking and debugging") because, well, it runs in real browser.

Hence, I wonder if it makes sense to deprecate and remove this option and point users to real headless solution instead?

[sbc100]

I personally don't use the HEADLESS settting.. but I do vastly prefer working with node compared to chrome --headless. For example just being able to easily see stdout and stderr is really nice. chrome --headless spews all kind of other crap to stdout and IIRC you don't even get to see the console message (or am I wrong about that?)

[sbc100]

Having said that I'm always a huge fan of removing unused/underused features!

[kripken]

I'd be happy to remove this, good idea, but only if it can work as easily as headless does right now. E.g. today

$ emcc [..] -sHEADLESS
$ nodejs a.out.js

Perhaps we can add a headless flag to emrun?

$ emcc [..]
$ emrun --headless a.out.js

[RReverser]

I'd be happy to remove this, good idea, but only if it can work as easily as headless does right now. E.g. today

Yeah that sounds sensible.

FWIW another alternative can be to point users to or include JSDOM - which is the most feature-complete project out there doing what HEADLESS option tried to do before (emulating browser environment in Node.js).

That said, I don't like that option as much because there are still differences compared to real browser environment so I don't think any such emulation will help with the stated goals of benchmarking and debugging as much as the real thing.

[RReverser]

For example just being able to easily see stdout and stderr is really nice

Yeah but if you're testing stdout/stderr you can already just use Node.js instead. IIUC, HEADLESS option was more targeted for users who want to automate testing of things like drawing to canvas via SDL (w/o actually implementing the drawing) and for that browser is the more suitable environment (because with that option you will be able to even test canvas output).

[sbc100]

Still, given the choice between working with a headless browser and working with node.. I'll always choose node. So much nicer.

Having said that, I don't use HEADLESS myself...

[RReverser]

Still, given the choice between working with a headless browser and working with node.. I'll always choose node. So much nicer.

Sure, but the thing is this option is specifically for testing browser-specific APIs which don't exist in Node.

So when you need such testing, alternatives are either provide shims for all possible required browser APIs in Node.js and hope it will behave similarly enough to real browser - which is what HEADLESS option was doing at a very minimum and JSDOM tries to do at maximum, but they both have discrepancies from real browser - or use actual real browser.

IMO when you need a browser, you need a browser. I can totally understand why this option was added when HEADLESS didn't exist, just saying nowadays headless browser is the better environment for this specific class of tests. Even Emscripten's own CI uses headless browsers for the same class of tests.

[kripken]

Yeah, this is for cases that use browser APIs. I agree browser headless mode is better for it.

Note that another use case back in the day was for benchmarking: we took a browser benchmark like BananaBread and made a headless version that isolated CPU execution (because all GL operations became no-ops), and which was easy to run in the shell. I guess that would still render in browser headless mode, so it would no longer isolate the CPU, but I think that's fine to remove.