So, other than the annoyance of actual handling animating the GIF, I don't think that adding the image formats to a commercial engine would be that hard. Hell, I'd just link in FreeImage and be done with it. The point, though, is that a web browser pretty much has to support that, whereas a game engine doesn't. For any particular feature X that a browser has and an engine doesn't, sure, you could absolutely add that feature to the engine. Or just embed Awesomium and have a browser in your engine. Doing so, though, is more of "anything you can do we can do" argument instead of the issue at hand of "browsers are required to be more complicated than engines".
To explain my last point: both Python and Ruby there are available in interactive REPLs inside the browser, implemented in JS:
The thing we keep disagreeing on is the basic premise that browsers are more complex than engines because they do more stuff, albeit less efficiently. Game engines, especially commercial ones like Unity or Source or whatever, are very nifty feats of engineering. I'm not disputing that. However, they aren't specified, they aren't standards conformant, they don't really have legacy stuff they have to put up with, they don't have security concerns in the same way browsers do, etc.
If you want to keep claiming that engines are more complicated than browsers, that's fine, but realize that that's a position far from settled. You have yet to, for example, answer any of the points about how much more complicated the operating and compliance environment of a browser codebase is.
s/last/lack
So, other than the annoyance of actual handling animating the GIF, I don't think that adding the image formats to a commercial engine would be that hard. Hell, I'd just link in FreeImage and be done with it. The point, though, is that a web browser pretty much has to support that, whereas a game engine doesn't. For any particular feature X that a browser has and an engine doesn't, sure, you could absolutely add that feature to the engine. Or just embed Awesomium and have a browser in your engine. Doing so, though, is more of "anything you can do we can do" argument instead of the issue at hand of "browsers are required to be more complicated than engines".
To explain my last point: both Python and Ruby there are available in interactive REPLs inside the browser, implemented in JS:
http://www.repl.it/languages/Ruby
http://www.repl.it/languages/Python3
Erlang has also been implemented in Javscript:
http://svahne.github.io/browserl/
The thing we keep disagreeing on is the basic premise that browsers are more complex than engines because they do more stuff, albeit less efficiently. Game engines, especially commercial ones like Unity or Source or whatever, are very nifty feats of engineering. I'm not disputing that. However, they aren't specified, they aren't standards conformant, they don't really have legacy stuff they have to put up with, they don't have security concerns in the same way browsers do, etc.
If you want to keep claiming that engines are more complicated than browsers, that's fine, but realize that that's a position far from settled. You have yet to, for example, answer any of the points about how much more complicated the operating and compliance environment of a browser codebase is.