I haven't used it myself but someone's working on QuickJS debugging,
including VSCode integration
- https://github.com/koush/quickjs ;(fork with debugging support)
- https://github.com/koush/vscode-quickjs-debug ;(VSCode integration)
Last update: 3 months ago
On Tue, Feb 15, 2022 at 7:18 AM John Gardner <gardnerjohng@xxxxxxxxx> wrote:
but I'd like to know if there are things that developers can do in V8 that
are not possible in QuickJS.
1. *Native coverage*.
V8 can output coverage data natively, eliminating the need to
instrument one's codebase before running tests. Node.js generates coverage
data in JSON format, but the standalone `d8` executable (V8's
debugging shell) can generate lcov(1)-compatible output using the
undocumented --lcov= switch (*Nota bene:* the equals-sign here is
mandatory; `--lcov /path/to/coverage.info` will *NOT* work):
d8 --lcov=/path/to/coverage.info script.js
QuickJS doesn't have *any* native coverage generation.
2.
*Full stack traces *V8 enables authors to examine each frame of an
execution stack (via Error.captureStackTrace
<https://v8.dev/docs/stack-trace-api>). QuickJS has only limited
stack-trace support.
3.
*Internationalisation *V8 supports the Intl
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl>
global, whereas QuickJS does not (this is a deliberate omission for the
sake of simplicity; supporting the world's locales is NOT trivial).
4.
*Debugging and profiling *This is a given; V8 has excellent features for
debugging and performance profiling, whereas QuickJS doesn't.
5.
*WebAssembly *V8 supports WebAssembly
<https://developer.mozilla.org/en-US/docs/WebAssembly>; QuickJS does
*not*.
On Tue, 15 Feb 2022 at 20:59, Alex <alexinbeijing@xxxxxxxxx> wrote:
Dear Marco,
Well, the API for extension is different. Node.JS includes a number of
C++ extension libraries which are linked with V8 and accessible from JS
code. (See the Node.JS API docs.) If you wanted to use some of those, then
there might be a reason to go for V8.
V8 is *wildly* more complex than QuickJS, though. It will probably bring
you more headaches.
If I were you, my personal preference would be to go for the simple
solution until it is proven that the complex solution is really needed.
Thanks
Alex
On Tue, Feb 15, 2022 at 10:56 AM Marco Bambini <marco@xxxxxxxxxx> wrote:
Hello,
I am considering adopting V8 or QuickJS for a project I am working on.
The project is developed in C, so my preference would be for QuickJS.
I am not interested in the speed that a JIT-based javascript engine can
have, but I'd like to know if there are things that developers can do in V8
that are not possible in QuickJS.
Any help would be really appreciated.
Thanks a lot,
Marco Bambini
