DaddyFrosty/yoga
1
0
Fork 0
Code Issues 96 Pull Requests 31 Actions Packages Projects Releases 33 Wiki Activity

[JS] Move from embind to manual bindings #1507

New Issue
Open
opened 2023-12-10 15:29:41 -08:00 by NickGerleman · 2 comments
NickGerleman commented 2023-12-10 15:29:41 -08:00 (Migrated from github.com)
Copy Link

embind is convenient but not ideal

  1. Its structure makes it hard to implement garbage collection vs finalization registry because we can’t differentiate JS refererence Vs native pointer
  2. It bloats the binary/bundle and adds required runtime support. Goes in the opposite direction of being able to generate portable wasm targeting only WASI.
  3. Our patching of its interface is hard to reason about or add to.

We should instead add the code for the object representation and have it call Yoga C APIs directly, like the JNI bindings.

embind is convenient but not ideal 1. Its structure makes it hard to implement garbage collection vs finalization registry because we can’t differentiate JS refererence Vs native pointer 2. It bloats the binary/bundle and adds required runtime support. Goes in the opposite direction of being able to generate portable wasm targeting only WASI. 3. Our patching of its interface is hard to reason about or add to. We should instead add the code for the object representation and have it call Yoga C APIs directly, like the JNI bindings.
NickGerleman commented 2023-12-10 15:33:14 -08:00 (Migrated from github.com)
Copy Link

This isn’t something I’m going to prioritize, but might be worth picking up as a next step in evolving the bindings, especially if standalone wasm es modules become well supported.

This isn’t something I’m going to prioritize, but might be worth picking up as a next step in evolving the bindings, especially if standalone wasm es modules become well supported.
6XGate commented 2025-04-05 15:19:44 -07:00 (Migrated from github.com)
Copy Link

Is the use of embind related to why Node#getChild seems to return a new instance of a JavaScript/V8 object wrapping the C++ Node instance? If not, I may need to file another bug due to noticing that any symbols I attached to Yoga Nodes don't come back with them from getChild.

Is the use of embind related to why `Node#getChild` seems to return a new instance of a JavaScript/V8 object wrapping the C++ Node instance? If not, I may need to file another bug due to noticing that any symbols I attached to Yoga Nodes don't come back with them from getChild.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Algorithm
Build and Infrastructure
C#
C++ Enhancement
CLA Signed
Discussion
Documentation
Feature Request
Java
JavaScript
Merged
Question
Reverted
Shared with Meta
Applied via automation to indicate that an Issue or Pull Request has been shared with the team.
YogaKit
YogaLayout ViewGroup
bug
dependencies
Pull requests that update a dependency file
duplicate
enhancement
fb-exported
fh:direct-merge-enabled
invalid
ruby
Pull requests that update Ruby code
wontfix
No Label
JavaScript
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
DaddyFrosty
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#1507
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?