Higher level web UI components?

[srowles]

A feature request / request for comment:

I've picked up using Vecty as a great way of avoiding having to think about Javascript or write HTML directly.. However to use it still requires a large amount of html / javascript knowledge. You need to understand the various HTML components and structure your code appropriately.

A long time ago I used to use GWT to develop web applications, one great thing that GWT did was provide higher level components that allowed you to construct UI's with higher level components that worrying too much about the low level html.

See:

http://www.gwtapps.com/doc/html/com.google.gwt.doc.DeveloperGuide.UserInterface.WidgetGallery.html

I think it would be really helpful for back end developers, who might want to write a UI but don't understand HTML or CSS, to be able to construct pages in a similar way.

This is effectively what aiming to do with my internal code, building components that I will then assemble together, it would just be really nice to have some out-of-the-box components that would then serve as a) a reference to building my own and b) allow re-use

[pdf]

I have a work-in-progress that wraps Material Components Web in Vecty Components, but there is quite a bit to do before that will be ready (since there's quite a bit to do on the Vecty side, too).

That said, I think that while Vecty is aimed at writing web applications in Go, it is at least currently designed around doing so very in a way that's very closely tied to web fundamentals. Think more like React than like GWT - they have quite different design philosophies.

[srowles]

Material components would be great, that would be a big leg-up from my point of view. I guess my impression was that: "instead of writing JavaScript/HTML/CSS." in the readme meant I could get away from knowing so much about the underlying web fundamentals, but maybe I do need to care.

[pdf]

It might be possible to write some sort of highly-opinionated framework on top of Vecty, but as it stands, Vecty is not equivalent to your GWTs or Vaadins.

[slimsag]

I haven't had a chance to read everything here yet, so I'm just skimming & replying to a few things here.

instead of writing JavaScript/HTML/CSS.

Well, at the end of the day you are writing a web application. We won't try to completely abstract away the entire browser. Perhaps a better way to read that line would be:

instead of writing JavaScript/HTML/CSS [syntax].

Of course it's not just syntactual, there are other benefits like composability, perhaps the ability to deeply associate CSS with components instead of in one big global namespace like CSS is, etc.

---

So yes, @pdf is completely right here that Vecty is more like React than GWT. But I would like Vecty long term to offer (as an option) highly-opinionated subpackages built on top of Vecty core ("react").

• github.com/gopherjs/vecty/router - like React router.
• github.com/gopherjs/vecty/ui (package name TBD), something like bootstrap or a themeable set of base components, similar to what you're speaking of here.
• ...

Basically, things that exist in the JavaScript ecosystem today and play well with React, but are kind of scattered about or there are multiple competing options to achieve the same goal. Of course, users of vecty core ("react") would not be required to use the subpackages and could write their own router, base components, etc.

[srowles]

Thank you for all the comments

github.com/gopherjs/vecty/ui (package name TBD), something like bootstrap or a themeable set of base components, similar to what you're speaking of here.

Sounds exactly what I'm after, for now I'll work on my own wrappers and try and keep an eye here in case there is something I can contribute back :)

[bzub]

@pdf

I've been working on a MDC wrapper + vecty implementation as well, here.

Could I see your work as well? Hopefully avoid duplication at least. Thanks!

I have a work-in-progress that wraps Material Components Web in Vecty Components, but there is quite a bit to do before that will be ready (since there's quite a bit to do on the Vecty side, too).

[pdf]

I've not quite settled on an API I'm happy with yet @bzub, so I've not published it. By all means go ahead - I probably won't have any time for another couple of months to look at it again.

[gernest]

While we are at this, I have been experimenting a lot with vecty. One of my efforts for material design lite https://github.com/wizenerd/ui but I have since moved on so it isn't in the best state but I had alot of things already working. See sample of rendering grid components here https://wizenerd.github.io/grid/

But I would like Vecty long term to offer (as an option) highly-opinionated subpackages built on top of Vecty core ("react")

Well, I think it will be nice to let the opinionated component be separate from the main vecty project. That way maintaining will be easy and brings a much room for experimentation without tying it much with the main repo.

One example is vue-router , it is defactor for vue but doesn't necessarily live under vue, so it gets its own releases.

[slimsag]

@gernest Personally, I think that is a mistake commonly made in the javascript ecosystem and not an advantage.

• Want a build tool for your javascript project? take your pick: you've got Makefiles, RequireJS, npm scripts, grunt, gulp, yarn, brunch, webpack, and more every day.
• Want a router for your React project? Try react-router, react-mini-router, react-router-component, universal-router, router5, or maybe write your own!

My (very blunt) point is this: If you want to use something separate, you absolutely can, and we'll do everything we can to enable that. These are subpackages in the most pure sense, and entirely separate from the Vecty core codebase. If you want to use something else with the Vecty core codebase, you 100% can, but for users who are starting out and asking "what should I be using for ?" we should have an answer, and "here's a list of options, good luck figuring out how to use them together!" isn't good enough for me.

This is similar to how Go offers net/http or encoding/json. You can absolutely use a different HTTP or JSON implementation, it's not like either of these are inherently linked to Go itself -- but most people will not, because standardization is good and the implementations of these packages are pretty dang good.

[ghost]

Any news on vecty material. It's great that 3 different ones got started.
The amigo one looks the furthest along to me.

Can anyone comment on the impact on vecty code base to make it work under WASM. I have been building some basic golang WASM stuff and I can see there will be an impact but curious if it's going to be huge or not.

Thanks again everyone. I feel that with golang getting official WASM support from the Google team is going to mean that more Devs trust the investment in building their web GUI with vecty. I want to help move it forward too.

[xoviat]

@bzub I've submitted pull requests on gitlab to add compatibility for wasm, but haven't heard back.

[slimsag]

@xoviat Can you link to what you are talking about?

[xoviat]

I'm talking about adding wasm compatibility for @bzub's material implementation:

https://gitlab.com/groups/agamigo/-/merge_requests

The problem is that it makes heavy use of gopherjs/js, which has a different interface to syscall/js. What I'd like to to, if @bzub no longer has the time to maintain those projects, is move them to github.com/vecty/material as part of #230 because they are quite frankly the most promising components available for vecty.

[soypat]

Any news on this front? I'm about to start a new project and was wondering if there's some material design bindings, WIP or finished product

[VinceJnz]

There's a material project here...
https://github.com/vecty-components/material