search

hexops / vecty

Vecty lets you build responsive and dynamic web frontends in Go using WebAssembly, competing with modern web frameworks like React & VueJS.
BSD 3-Clause "New" or "Revised" License
2.81k stars 144 forks source link

proposal: Consider moving Vecty under its own GitHub organization #230

Closed slimsag closed 4 years ago

slimsag commented 5 years ago

Currently, Vecty lives under the GopherJS organization. This made sense for multiple reasons at the time, which I will go into further here. However, I believe it may be time for Vecty to move under its own organization and live at https://github.com/vecty/vecty

Vecty: A brief history

Vecty originally started out as me looking into how a React-like framework could be done in Go, with an interesting twist: I didn't know React (and I still consider myself to not know React). This, I think, gave me an interesting perspective on how to achieve the same goals as React without making it feel like React stuffed into Go, but rather a Go developer's take on how component-based webapps could be written.

This idea got shared with @dmitshur, who then shared it with @neelance (author of GopherJS) and as it turned out he was also experimenting with the idea of React-in-GopherJS. After meeting up in person in SF, we came to chat about this significantly and he proved to me various flaws and incorrect assumptions that my (documentation-heavy) implementation at the time would have in comparison to his (undocumented) implementation. So after some discussion it made sense: Add documentation and use his implementation, and use the Vecty project name.

Much experimentation and many significant changes later, and Vecty is ironically not like either of the starting implementations. We're still missing documentation and the actual implementation uses many different core concepts (mainly to remove boilerplate code that was hand-written or auto-generated in @neelance's initial implementation).

In Go 1.11, @neelance added WebAssembly support to Go and support for it in Vecty has always been planned.

Today, the Go WebAssembly community is flourishing more and more, with even alternative Go implementations like @aykevl's tinygo popping up (which aims to produce ultra small binaries, making it an even more viable target for producing web applications).

It makes sense today that Vecty will support three primary compiler targets:

All of these implementations have various tradeoffs between binary sizes, browser compatibility, standard library support, etc. and Vecty can and should support all of them soon.

Should we move to a separate organization?

I think yes, with the main reasons being:

  1. Vecty living under the GopherJS organization implicitly communicates that it is for GopherJS
    • GopherJS is likely to go into a sunsetting state soon, with more and more developers switching over to Go's native WebAssembly support. This may make it look like the "old" technology to newcomers (even if it isn't). Go 2 will be coming eventually and I anticipate there will not be enough developer time spent on GopherJS in the long run to support Go 2 (I would be happy to be wrong about this, however).
  2. Vecty already requires a location to host other related repositories: https://github.com/vecty and putting those in the GopherJS namespace would obviously not make sense (we would pollute it).
  3. My hope is that Vecty can one day be the defacto method of doing web UX's in Go in the long term, and that the Vecty github organization could act as a location for maintaining a set of curated Vecty packages similar to how golang.org/x/ contains curated Go packages.

Notes

pdf commented 5 years ago

Makes sense I think.

mfridman commented 5 years ago

An interesting consideration here is whether vecty would make use of and/or support a wrapper such as gopherwasm.

A while ago @dmitshur published the Future of GopherJS and Go in the browser. In an ideal world packages such as vecty could support multiple compiler targets with a well supported wrapper.

However, if development of such a wrapper were to stop, slowdown or not be able to keep up with the rapid pace of WASM development, what would that mean for the vecty project?

WASM is not yet subject to the Go 1 compatibility promise. So there will likely be breaking changes as development in this space moves forward.

There may be challenges if vecty moves to an organization and attempts to support multiple compiler targets.

For these reasons there can be an argument for keeping vecty coupled to the native implementation (GopherJS) and considering other solutions. This obviously isn't ideal, at all, because being able to make use of both for the near-future is still ideal.

E.g., being able to serve both WASM and JS, to support various browser versions, with JS as a fallback.

If vecty could move to an organization and support multiple compiler targets that would be ideal.

pdf commented 5 years ago

There may be challenges if vecty moves to an organization and attempts to support multiple compiler targets.

I don't believe the two are in any way coupled.

slimsag commented 5 years ago

An interesting consideration here is whether vecty would make use of and/or support a wrapper such as gopherwasm.

A while ago @dmitshur published the Future of GopherJS and Go in the browser. [...]

Thanks for linking me to that, I hadn't seen that blog post of his yet.

I like to think that Vecty can work well with gopherwasm if you want it to, but that we do not enforce that on you. If you want to stay in pure gopherjs/js, or pure syscall/js, that's up to you as a consumer of the library. In specific, see my comment here for how I plan to approach this.

mfridman commented 5 years ago

@slimsag Thanks for linking that comment 👍. I may have gotten some things wrong then.

I think a move to its own organization makes sense.

g5becks commented 5 years ago

Is making vecty work with 3 different backends going to further delay the project becoming production ready? I’ve been keeping my eye on vecty for a long while hoping for the readme to not say “ Vecty is currently considered to be an experimental work-in-progress “ anymore. I’d really love to see where vecty goes when it get to v1 status.

slimsag commented 5 years ago

No, supporting 3 different backend is about 0.5% of the work needed to get a v1 release, and currently not having support for those 3 backends is causing others to consider writing their own web frameworks separately when they could theoretically be contributing to Vecty. For an idea of what we need for v1, see https://github.com/gopherjs/vecty/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0

Me and @pdf are currently the only major contributors to this project, and both of us lack a lot of time to contribute (I for example can only donate a few hours every few months, with all other time going towards work or family). At current pace, a v1 release is a long way out unless we get more major contributors or I start working on Vecty full time which is super unrealistic 😛

g5becks commented 5 years ago

Hey @slimsag that makes perfect sense, I haven't seen any other go client-side frameworks that look worth anything aside from https://github.com/myitcv/x/tree/master/react not sure how many people actually use it though. I'd love to help out in any way that I can with the project, I can maybe only spare a couple of hours a month myself, but I guess every little bit counts. Have to really dig into the code at some point just to get an idea of where to start though.

Hopefully, more people in the community will contribute to the project. Would be cool to write only Go code on the client and the server at some point.

slimsag commented 5 years ago

A great place to start is writing more test cases :)

lunny commented 4 years ago

Just do it and fork github.com/vecty/vecty to github.com/gopherjs/vecty for compitable.

xoviat commented 4 years ago

@slimsag I'd like for you to move the project to github.com/vecty/vecty. Then I'd like to move github.com/vecty-material/material to github.com/vecty/material. That repository would include the 'official' material design components for vecty.

I don't see a reason to put this off any longer; the URLs will break at some time and waiting is going to make things worse in the future.

mpfaff commented 4 years ago

I'd like to add that if you were to transfer the repository, GitHub should handle redirects to the new url.

slimsag commented 4 years ago

Hey folks - it's been a while since I originally proposed this and I wanted to provide an update and explain the next steps here.

Over the past year I've had increasingly less time to work on Vecty due to a number of other things pulling my attention away from it (family, work at Sourcegraph, and other life events.) This has meant Vecty has been, and continues to be, in a bit of maintenance mode.

I think it could become immensely valuable to the Go community and could become the best way to write web UIs in Go - but it'll require a bit of work to get there and, currently, I am the only one devoting time to it.

Outside of Vecty, I have a number of other ambitious projects going on and I would eventually like to have these lead to an organization which is able to fund the development of Vecty (among other open-source projects) - that is still several years away and I hope to do more work on Vecty before then.

In the meantime, I am corralling all of the projects I maintain into a single organization - https://github.com/hexops - and intend to move Vecty there. This should be a space where it can thrive all the same (and hopefully, in the distant future, much more than) as if it was in https://github.com/vecty

What this means is that:

slimsag commented 4 years ago

The above has been done in #268 - please refer to the CHANGELOG to update your import paths.

VinceJnz commented 3 years ago

What is going to happen with the documentation and material. Will they be moved into the new structure? https://pkg.go.dev/github.com/gopherjs/vecty https://github.com/vecty-material/material