WebAssembly support not easy to find

Version: 9.0.0, 9.0.1, 8.3.0
Platform: Kubuntu 14.04, CentOS Linux release 7.2.1511 (Core)
Subsystem: (node versions managed by n package)

node -v
v9.0.0
node
> WebAssembly
{}

node --expose-wasm 
> WebAssembly
{}

=========
[as root] n latest
=========

node -v
v9.1.0

node
> WebAssembly
{}
> 

node --expose-wasm 
> WebAssembly
{}

========
on CentOS:
========

 node -v
v8.3.0
[---]$  node
> WebAssembly
{}
> [---]$  node --expose-wasm
> WebAssembly
{}

Thanks for your time,

--Rob

Hi, thanks for the issue!

Maybe I’m misunderstanding, but WebAssembly support is there in Node 8 & 9, with or without the flag.

All the functions are there:

$ node
> process.version
'v9.0.0'
> WebAssembly.compile
[Function: compile]

So I guess the real issue here is that WebAssembly is displayed as {} in the console?

@addaleax

Yep @addaleax .

WebAssembly (formerly wasm) should show its available API, IMHO.

Just like i.e. console:


console
Console {
  log: [Function: bound consoleCall],
  info: [Function: bound consoleCall],
  warn: [Function: bound consoleCall],
  error: [Function: bound consoleCall],
  dir: [Function: bound consoleCall],
  time: [Function: bound consoleCall],
  timeEnd: [Function: bound consoleCall],
  trace: [Function: bound consoleCall],
  assert: [Function: bound consoleCall],
  clear: [Function: bound consoleCall],
  count: [Function: bound consoleCall],
  countReset: [Function: bound countReset],
  Console: [Function: Console],
  debug: [Function: debug],
  dirxml: [Function: dirxml],
  table: [Function: table],
  group: [Function: group],
  groupCollapsed: [Function: groupCollapsed],
  groupEnd: [Function: groupEnd],
  markTimeline: [Function: markTimeline],
  profile: [Function: profile],
  profileEnd: [Function: profileEnd],
  timeline: [Function: timeline],
  timelineEnd: [Function: timelineEnd],
  timeStamp: [Function: timeStamp],
  [Symbol(counts)]: Map {} }

--R

I think a good solution would be to solve this by taking @@toStringTag into account as a fallback when computing the constructor name in util.inspect. That’s kind of easy to do, so I’m labeling this as a good first issue if anybody wants to grab it.

Is this actually incorrect? It matches what all the browsers do... Chrome is the only one that shows the internals but they're faded like private properties are usually.

@apapirovski

@apapirovski I think not displaying the methods is correct, yes. But I think there really should be output that distinguishes WebAssembly from a simple {}.

@addaleax

@addaleax but it matches browser consoles and that's generally been at least partially our goal.

I feel it as a lack of interactive documentation.

@apapirovski

@apapirovski I think the goal of util.inspect is to be as helpful as possible … if we can be more helpful than browsers I’ll take it. (And yes, helpful is very subjective. 😄)

WebAssembly examples online still use wasm and instantiateModule.
Having a JS object exposing its public methods is a good practice imho.

--R

@RobertoMalatesta

@RobertoMalatesta To be clear, what I’m suggesting is to switch to something like WebAssembly {} as the displayed output, because we generally stick with what the object says – if its properties are not enumerable, then we won’t show them in the console either by default.

The methods are all there, it’s really just a question of how to display the object in question.

Fine for me if there's an easy way to follow its API development (not only for me but for anyone interested).
util.inspect returns {} btw
So, where a user should see the info on WebAssembly module?
(it's not in oficial doc on main site)

Thanks for your work, (just trying to be of help).

--Roberto

I'm still not convinced we should be doing anything differently.

The WebAssembly object is the initial value of the WebAssembly property of the global object. Like the Math and JSON objects, the WebAssembly object is a plain JS object (not a constructor or function) that acts like a namespace and has the following properties:

https://github.com/WebAssembly/design/blob/master/JS.md

It's a plain JS object with non-enumerable properties. It's not a class, constructor, whatever. Naming it as WebAssembly {} seems misleading.

I mean, that's what util.inspect(WebAssembly, true, 0) is for. It would be a bit weird to make an exception for JSON, Math & WebAssembly.

i think we're all in agreement at this point. 👀

Well, I think there's a merit here to saying that showHidden should be on by default in REPL, then this would not be an issue. It would make our logging more similar to what the Chrome console does but less similar to Safari, Firefox & Edge.

+1 to using showHidden in REPL

@apapirovski

@apapirovski i'm not so sure about this behavior, my only thought is to apply separate depth limits to enumerable and non-enumerable properties on util.inspect

@addaleax

The proposal by @addaleax is to have it show Math {}, JSON {} and WebAssembly {} instead of just {}.

-1 The name before the braces should be a class/constructor name, not a namespace, for consistency.

@mscdex

@mscdex It's not a name space, but the @@toStringTag name. IMO I see no harm in displaying those for a better description when constructor.name is too vague.

@joyeecheung

@joyeecheung In these cases, the @@toStringTag is just returning the name of the global variable (e.g. Math, JSON, etc.), so I would call that a namespace, especially since they are not constructors (or functions at all).

@mscdex

@mscdex But this does not have to be about those built-in obejects. Considering this:

var foo = {};
Object.defineProperty(foo, Symbol.toStringTag, { value: 'Foo', enumerable: false })

IMO in this case it's reasonable to display foo as Foo {}. constructor.name is just one way to get the class/type name, but not every object is supposed to be constructed by a constructor or by calling new.

@joyeecheung

@joyeecheung Using the same notation as constructor names is misleading and inconsistent.

@joyeecheung

@joyeecheung @mscdex It would be nice if you could chime in at what’s being discussed in #16956 (comment) as a solution

#16956 landed. Closing.

Navigation Menu

Repository navigation

WebAssembly support not easy to find #16952

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WebAssembly support not easy to find #16952

Description

Activity

addaleax commented on Nov 11, 2017

RobertoMalatesta commented on Nov 11, 2017

addaleax commented on Nov 11, 2017

apapirovski commented on Nov 11, 2017

addaleax commented on Nov 11, 2017

apapirovski commented on Nov 11, 2017

RobertoMalatesta commented on Nov 11, 2017

addaleax commented on Nov 11, 2017

RobertoMalatesta commented on Nov 11, 2017

addaleax commented on Nov 11, 2017

RobertoMalatesta commented on Nov 11, 2017

apapirovski commented on Nov 11, 2017

19 remaining items

apapirovski commented on Nov 11, 2017

devsnek commented on Nov 11, 2017

apapirovski commented on Nov 11, 2017

devsnek commented on Nov 11, 2017

devsnek commented on Nov 11, 2017

mscdex commented on Nov 11, 2017

joyeecheung commented on Nov 12, 2017

mscdex commented on Nov 12, 2017

joyeecheung commented on Nov 12, 2017

mscdex commented on Nov 12, 2017

addaleax commented on Nov 12, 2017

targos commented on Jan 2, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions