Thoughts on the Direction of Gloo

[chinedufn]

Thoughts on the Direction of Gloo

Let me first start by saying that @rustwasm has changed my programmer-life for the better in more ways than I can count. I'm absolutely loving the Rust + WebAssembly story!

I say that so that anything that I say below doesn't sound like dissent. I just want to share feedback which will hopefully help push @rustwasm forwards!

I recognize that some of my thoughts will be wrong and/or misinformed - so feel free to point that out!!!

Also big disclaimer that I maintain some Rust web front-end tools although I'm hoping that that doesn't make my feedback too biased!

---

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.

Just about anyone that needs something that doesn't exist will contribute it back to wasm-bindgen or wasm-pack if it's low level - or just build in top of wasm-bindgen or wasm-pack.

They do an excellent job of focusing on problems that are solvable almost entirely without any material disagreement - and letting the community build on top of that.

---

I'm very afraid of Gloo breaking this mold.

I'm getting the impression that we might be heading in the direction of "Come to Gloo to get modules that you need."

This to me will just lead to "Gloo has some great modules, but there are 14 other people building similar modules because they disagree with how Gloo did it."

---

I think that a better direction would be for Gloo to focus on being the glue between modules that the community builds.

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.

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.

And the community can very easily try out the options since they all are compatible with these Gloo traits / generic methods.

And all of these maintainers are contributing back to Gloo as they learn.

Rust on the web is still young - so there will certainly be a lot of learning around what patterns allow us to build production grade applications the fastest.

I want to trust the community to discovery these things, and I want to trust @rustwasm to empower the community on that journey by building out the most lowest-common-denominator libraries and tooling.

---

What I think Gloo should do

Look at what people are already doing and try to be the glue between them.

What do the virtual-dom's look like today? What do the procedural macros for HTML parsing look like today? What do the diff/patch algorithms look like?

Can Gloo provide traits / generic methods that almost every single one of these libraries would build on top of?

Thereby unifying the community and giving people with different ideas the room to explore them while contributing what they find back to the super-low-level Gloo crates?

Which - I know is the goal! I just think that some of the issues that I see are far too high level. So I'll give some examples below of what I mean by low level, least common denominator.

Things I would find immediately useful

Validation for DOM nodes and attributes.

I maintain an html-macro - and it looks like there are a few others in the community - each with their own advantages / disadvantages.

A disadvantage of my macro is that there isn't nearly as much type checking as in typed-html. But I can't switch to typed-html even when they have wasm-bindgen support because I personally prefer not having to wrap text in quotation marks.

It'd be nice if Gloo provided the validation that typed-html html-macro and any other macros could build on top of.

"Is this string a valid class". "Is this href valid?". etc

A VirtualNode Trait

People will have different thoughts and ideas on how a diff/patch algorithm should look.. But one thing that is pretty consistent is that virtual nodes all have properties ... events ... and basically look like real DOM elements.

As people explore diff/patch algorithms and their own virtual dom's it would be nice if they were all building on top of Gloo.

Don't like one diff/patch algorithm that someone provides? Switch to another one pain free since they're both generic on top of Gloo's VirtualNode trait!

I probably have other ideas

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.

In Summary

I think that the best path forwards for Gloo right now for a lot of these issues that are open is to look at unifying/being the glue between all libraries that exist now and will exist in the future.

Gloo should spur innovation by being the foundation for all future experimentation.

Gloo should focus on the bits of the stack and the problems that will have nearly zero opinion on how to do them properly - and let the community build on top of those solutions (just like wasm-bindgen and wasm-pack).

---

Just my thoughts! Hope it helps!

[luover]

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 .

[David-OConnor]

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.

[Pauan]

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.

[chinedufn]

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!

[Pauan]

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?

[chinedufn]

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 (:

[Pauan]

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).

[chinedufn]

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

[fitzgen]

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!

[chinedufn]

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!!

[chinedufn]

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.