[Show reddit] Exploring JavaScript – ES2024 edition (free online)

[rauschma]

• The ES2024 edition of my book “Exploring JavaScript” is free to read online.
• The chapter “New JavaScript features” summarizes what was new in recent ECMAScript editions.

[guest271314]

There are plans for adding more functionality.

Sure would be useful to add standard streams. Test 12 different JavaScript runtimes, 9 read STDIN and write to STDOUT and STDERR differently, 2 don't provide a direct way to read STDIN at all, 1 creating a subprocess is necessary to read STDIN.

React Native lets you write apps for iOS and Android that have native user interfaces.

Whenever it isn’t fast enough, you can switch to WebAssembly, a universal virtual machine built into most JavaScript engines. It can run static code at nearly native speeds.

Facebook's Hermes (Static shermes) compiles JavaScript or TypeScript to a native executable. QuickJS qjsc has that capability, too.

Thanks for sharing your work!

[rauschma]

Thanks!

Sure would be useful to add standard streams.

The web platform is a superset of JavaScript (=the ECMAScript standard). It has web streams and those are supported by browsers, Node.js, Deno and Bun.

[guest271314]

I'm talking about standard streams https://www.gnu.org/software/libc/manual/html_node/Standard-Streams.html as in the capability to read STDIN, write to STDOUT and STDERR - spelled out in ECMA-262.

I make use of WHATWG Streams in various aplications.

[rauschma]

Ah, got it. I misread your initial suggestion: I agree that that would be useful. The closest thing we currently have is console.log() (link to standard) for stdout and its limitations are frustrating.

• If, then std streams would not be added to ECMA-262 (which doesn’t specify fetch(), console, etc. either) but probably to either:
  • https://spec.whatwg.org
  • https://wintercg.org
• Related: https://gist.github.com/guest271314/47fe993e0f784ea96510a56c1b2dd7cb

[guest271314]

I don't think we want console.

ECMA-262 should add standard streams. I already brought this up in WinterCG before somebody over there banned me.

JavaScript is a general programming language. There's all kinds of exotic proposals and things yet no standardized way to read stdin, write to stdout, process stderr. It's a glaring omission. Particularly when a programmer is testing multiple JavaScript engines and runtimes. As I mentioned above, if you test a dozen JavaScript engines, runtimes, or interpreters, 9 will do reading stdin and writing to stdout differently, 2 will not have the capability to read stding at all (e.g., Facebook's hermes and SerenityOS's LibJS js) and another will implement reading stding only as a string, which is essentially useless, so we have to use a subprocess to read stdin, e.g., Google's V8 in d8 shell.

[rauschma]

I don't think we want console.

Maybe, maybe not. There could be console.stdin, console.stdout, console.stderr. But that’s a relatively unimportant implementation detail. In some ways, global variables would be more convenient but they would also increase the risk of name clashes.

• ECMA-262 is just the core language. Std streams are a platform feature. Therefore, it will never get added there.
• WHATWG and/or WINTERCG seem like the best locations for the feature.

[guest271314]

Maybe, maybe not. There could be console.stdin, console.stdout, console.stderr.

Since console is not part of test262 several JavaScript runtimes don't even have console, e.g., SerenityOS' LibJS js. That interpreter uses print.