There is no universal bytecode for JavaScript, but most JavaScript engines have their own bytecode. Since JavaScript files travel as source code string, they have to parse/compile source code string into bytecode at before execution.
However, as we can specify a user agent type (e.g. browser type and version) in HTTP request, can't we make the server keep bytecode for each browser and respond accordingly to save some time at client?
What's preventing us from taking this approach? I don't think browsers will have no problem even if some JavaScript files are given in bytecode and others in source string. Similarly, we have .pyc files in Python, and it runs well with .py files.
[Update] Potential benefits I can think of are below.
- You could save parsing time at client. Parsing is fast, but it may be worth to do it for low-end devices.
- You could put some hints in bytecode. For example, JavaScriptCore (WebKit's JavaScript engine, JSC for short) patches bytecode with information gathered during runtime, such as types. JSC's bytecode is designed in a way that it has slots for such information.
In terms of maintainability, the server can always send the original source code string if the client's browser is unsupported, and there are not so many different JavaScript engines. Supporting four most popular browsers (Chrome, Firefox, IE and Safari) seems feasible to me. In addition, I don't see bytecode instruction set changing frequently.
- All engines would need to make their byte code format public
- The server would need to hold very many different byte code files, or even compile them on the fly
- Browser detection is fraught with peril (user agents lie, proxies cache)
- Bytecode rules might change between minor versions of a browser
- The performance gains probably wouldn't be all that significant (especially when compared to network transfer times)
来源：https://stackoverflow.com/questions/28649467/why-not-sending-javascript-files-in-browser-specific-bytecode