1

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.

  1. You could save parsing time at client. Parsing is fast, but it may be worth to do it for low-end devices.
  2. 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.

jray319
  • 31
  • 4
  • 1
    What if a browser is pushing an update and the internal bytecode format changes? – Bergi Feb 21 '15 at 18:21
  • 4
    What's the problem you think this solves? – Matt Ball Feb 21 '15 at 18:21
  • 2
    It would be a terrible thing for the architects of the browser JavaScript runtimes to have to pin down their virtual machines on a specific instruction set. As it stands now, parsing JavaScript is astoundingly fast and completely worth the price (in my opinion). – Pointy Feb 21 '15 at 18:21
  • What advantages do you see over the current approach? I don't see any reason to put more workload on the servers. – Bergi Feb 21 '15 at 18:22
  • 1
    Also think about what sort of nightmare it'd be for a large site to deal with all the active versions of all major browsers, *including mobile device browsers*. – Pointy Feb 21 '15 at 18:22
  • Distributing .pyc files is a terrible idea. Please don't do this. – Antimony Feb 21 '15 at 18:50
  • Thanks for all comments. Please read the updated question. – jray319 Feb 21 '15 at 19:30
  • @Antimony Why is distributing .pyc files a bad idea? – jray319 Feb 21 '15 at 19:30
  • 2
    @jray319 Because they're version and implementation specific, meaning that they can only be run correctly from the same interpreter that compiled them. Also, it breaks some of the introspection tools. Python isn't Java, where bytecode is the platform. In Python, source code is the platform and bytecode is just an undocumented implementation detail. – Antimony Feb 21 '15 at 23:49

1 Answers1

3
  • 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)
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335