Thoughts on the Direction of Gloo about gloo HOT 11 CLOSED

Thanks for starting this thread, @chinedufn :)

I don't have much to add over what @Pauan has already written elsewhere regarding collection of many small crates, plus an umbrella crate that ties them together. That's right on the money.

Build reusable crates that any framework or library author wished had already existed when they were building their project. And make them reusable, standalone, small, fast, best versions of themselves.

I don't think we need to be 100% limited to just-above-web-sys-abstraction-level utility crates. I think building higher-level pieces with the explicit goal of finding pain points or missing libraries that we intend to spin out into standalone crates is a great way to make sure that our crates are actually solving real world use cases.

I also don’t think that intentionally vague is definitely a good starting point - at least for me it’s causing a lot of confusion around what Gloo is and what Gloo isn’t.

There is a delicate balance between filling out a bunch of good first issues and articulating a plan/vision versus creating a space for a bunch of folks to collaborate, help navigate the course, and become technical leaders of the project in their own right. Do too much pre-planning and there isn't much room for others to come and get a sense of ownership/leadership/investment. Don't do enough pre-planning and folks are wandering and lost.

I tried to create something here that was enough to kick off discussion and planning, but yeah its a bit vague because I don't have the whole picture super clear in my head. I hope that by having conversations like this one, we can bring that picture into focus together :)

Thanks again for starting this discussion!

from gloo.

I think rustwasm need a project like faceboo react or google flutter to make rust a good choose for web/wasm.
If not, when most langs can target wasm, why I should choose rust for web/wasm than most easy langs.
and I don't want rust only the choose for wasm librarys.

I also don't think webfront need more framework/library, nows there is only few framework/library can be popular like react/argular/vue. we can build a better one together and make a comunity around it .

from gloo.

I interpret Gloo as providing a common interface to link the important components of frontend web apps together, ie the areas associated with each issue @fitzgen posted. This will involve opinionated decisions, which will lead to the separate projects you mentioned, but we can keep the interface as generic as possible, making this a good starting point.

To get started, we need to establish how Gloo components will interact: They must share something. Perhaps Traits are one way to accomplish this. Eg establish an Element trait, which describes things like tag, attributes, events etc. Looks like we'd need getter methods instead of fields for this due to how Traits work. As much as possible could be left up to the frameworks/modules Gloo uses, but there has to be common ground. Making interchangeable modules sound easy in principle, but I've found it very difficult.

I think Gloo's purpose is to address this by providing a compromise between generic, and framework-specific. Ie frameworks adhere to certain constraints Gloo sets, and with this expense, are able to interchange parts.

from gloo.

wasm-bindgen wasm-pack and the rest of rustwasm are so successful because they provide functionality / solve pain points in a way that is pretty much objectively correct.

You're unlikely to see a second wasm-bindgen or a second wasm-pack because they aren't trying to be much more than exactly what almost anyone would want on the low level.

I disagree with that. They are not objectively correct, and there are alternative designs.

In addition, there are actually other projects which have some advantages compared to wasm-pack and wasm-bindgen. In particular, cargo-web and stdweb.

This would mostly look like Traits and generic methods that ... so long as a community module implements these traits it's compatible with the rest of the ecosystem.

Yes, that is indeed one of the major goals of Gloo.

We don't need one toolkit to rule them all IMO. I think we need Gloo to empower dozens of other developers to iterate on what they think Rust web modules should look like.

Gloo is not intended to be a "one toolkit to rule them all". It's intended to be many small crates, each of which does one thing well, and in addition to that a crate which unifies and re-exports the small crates.

Think of it like how the Futures ecosystem is split into these small crates:

• futures-async-runtime
• futures-channel
• futures-core
• futures-executor
• futures-io
• futures-sink
• futures-stable
• futures-util

And then in addition to that there is the futures crate which re-exports those sub-crates (for convenience).

The intention is that people can mix-and-match the small crates as they wish, or they can use a "unified crate" which re-exports the small crates.

And there might be multiple different "unified crates" depending on people's needs!

I can open issues when they come to mind if useful! But hopefully these were helpful!

In general I think that for a lot of the issues that are open we can zoom in to specific pieces of them that are un-opinionated and focus on that.

Please do! The issues are intentionally vague in order to provide a starting point (since we don't know what the right answer is right now), but you absolutely should mention specifics in the threads.

from gloo.

cargo-web and stdweb aren’t trying to solve the same problem as wasm-bindgen IMO. They have different goals - and I think that wasm-bindgen has executed on its clearly defined goals pretty much flawlessly (expose web APIs in a the rawest way possible that will be compatible with the WebIDL bindings proposal in the future)

My understanding is that stdweb is planning to use wasm-bindgen under the hood - can’t speak for cargo-web though.

I also don’t think that intentionally vague is definitely a good starting point - at least for me it’s causing a lot of confusion around what Gloo is and what Gloo isn’t.

I again think that Gloo is breaking from wasm-bindgen and wasm-pack’s mold of having incredibly clear and low level direction/goals up front that everyone can rally behind and build on top of.

Of course - I recognize that this has all been thought through deeply and with the awesome track record of rustwasm I’m sure that it will all click for me as things come together!

Will be watching the repo and contributing where I can.

Going to leave this issue open for a couple/few days in case anyone else had thoughts - and then I’ll close it out!

from gloo.

I also don’t think that intentionally vague is definitely a good starting point - at least for me it’s causing a lot of confusion around what Gloo is and what Gloo isn’t.

I think the README on the main page is quite clear on Gloo's goals:

https://github.com/rustwasm/gloo#what
https://github.com/rustwasm/gloo#goals

What do you think should be changed to make it more clear to you?

from gloo.

Sorry - let me try to clarify!

You said that the issues are intentionally vague.

I'm saying that the vagueness was the precise reason that I opened this issue. I have concern about Gloo trying to build too high in the stack.

I think that rustwasm / Gloo's primary focus should be putting the low level, nearly un-opinionated blocks in place that empower the community to build out the bigger pieces. gloo-timers is an excellent example of this.

Which is what the README hits on - but some of the issues seem to go higher than that in my opinion (virtual dom, app state management, other opinionated things).

(Emphasis on seem because I know that everything is in the brainstorming phase right now!)

Which all just brings me back to what I'm mainly trying to say:

Some of the issues gave me the impression that Gloo might be working on highly opinionated parts of the web stack and I think that that is better left for user land.

That is the thought that I wanted to share. No change to the README would make that more clear to me - it's the discussion in the issues that I'm talking about.

Again - just to be clear - I love the idea of putting building blocks in place - I'm concerned about choosing blocks that are too large or opinionated. So I wanted to share that concern!

Basically - all of the issues labeled utility-crate make perfect sense to me - but some of the others (an opinionated WebGL library, for example) feel like they should be happening across dozens of different projects in the community to me.

By different people that are scratching their own itch in different ways. Unified by some least common denominator tools and traits that Gloo provides. Each of them pushing the community forwards by exploring different trade-offs in different ways - until the cream of the crop start to rise to the top.

(For the WebGL issue - I know that it's just in the discussion phase and it might not even end up aiming for something at the size and complexity of glium)

That's all! Hopefully I did a better job of clearly communicating what I am trying to say (:

from gloo.

That's all! Hopefully I did a better job of clearly communicating what I am trying to say (:

Yup! I understand clearly now, thanks.

I can't speak for @fitzgen, but I believe the intention of Gloo is indeed to work with multiple other projects to find common ground (which is another reason the issues are vague, because they apply to many different projects).

from gloo.

Awesome! Super excited for the future of all of this!!

from gloo.

Very awesome! I already feel like I have a better understanding of the project so I'm glad that I opened the issue and I'm glad that everyone in here chimed in!!

from gloo.

Also:

I think building higher-level pieces with the explicit goal of finding pain points or missing libraries that we intend to spin out into standalone crates is a great way to make sure that our crates are actually solving real world use cases.

This was a key missing piece for me - as I was a bit afraid of modules being farmed without real world use cases.

I'll re-open this issue for a few more days since it's already helped me get a better (not perfect, but better!) understanding of what Gloo is and what Gloo isn't so maybe others will gain that perspective as well.

from gloo.