Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Port to WASM #27
This is a port to WASM. I'm not sure that, given that this is a gopherjs library, we should officially adopt WASM as the only way of using the library.
Making a library that works in both WASM and GopherJS is a much larger scope than I wanted to take on. There are differences in execution environment and callbacks that make them behave significantly differently.
I've also changed how tests work, given that we can use
This passes all of the current tests.
This is great, thank you for working on this @nightexcessive! I tested this quickly with one of my projects that uses WebSockets substantially, and everything was working as expected when compiled with WebAssembly.
We certainly can't merge this as is and remove the GopherJS support at the same import path, as that would break all existing users. However, I think we can and should support both.
I don't quite understand why it'd be difficult. I'll limit discussion to the high-level bindings package only. We currently have the following API at
// Dial opens a new WebSocket connection. It will block until the connection is // established or fails to connect. func Dial(url string) (net.Conn, error)
I think we need to follow this Go proverb:
That applies to
We can have two implementations of the
(Optionally, we can have the package level
Is this an approach you've considered @nightexcessive?
Edit: To clarify, I'm only suggesting we add WebAssembly support to
referenced this pull request
Sep 30, 2018
Can we discuss that approach?
My understanding is that using
However, I think it would be better for us to choose to use
Here's why I think it's better in this context:
That said, using
What do you think?
Since almost all of the functions in both the
Obviously, the former seems more desirable. Regardless of the way we do it, there will almost certainly be an extra layer of abstraction.
Ok, it sounds like you're feeling pretty strongly about avoiding having two implementations of the high-level
Not sure what extra layer of abstraction you're referring to when
However, let's talk about the package organization first.
We have two packages here right now:
I will argue that we have a hard constraint that we cannot break the API of
That leaves us with these options of what to do about
Option 1 is not great because the same package would have to be used differently depending on which compiler you're trying to use. It feels confusing and hostile (e.g., godoc.org can't even display documentation for different GOOS/GOARCH values).
I think we should pick option 3, and not try to add WebAssembly support for
So my suggestion is we leave
Does that make sense, and what do you think? Let me know if anything's confusing.
I don't have a strong opinion on that, but let me comment...
Interesting. Would you give me some examples (sorry if I missed)?
I tend not to think the overhead is so big that we need to consider, since GopherJS itself's overhead is much bigger.