Open owenwaller opened 7 months ago
Lord-Y
commented
7 months ago I'm also interest to see Vugu go to version 1.0. @owenwaller I'm also interest to know if you'be been able to build a fully dynamic website with Vugu as a replacement to any javascript frameworks?
owenwaller
commented
7 months ago @Lord-Y Vugu works just fine. We never used Javascript to build the UI so we never had to replace an existing Javascript UI/framework..
We have a UI that is dynamic based on the server responses we get from the http requests we make to the server.
As the project is closed source I can't show you how we did it, but everything you need is in the vugu documentation.
Lord-Y
commented
7 months ago Thx for the answer @owenwaller . I can wait to see the website once it goes public.
bradleypeabody
commented
7 months ago @owenwaller Thanks very much for this message. I agree it would make a lot of sense to round off Vugu to a 1.0 release. I've been using it in production to on some closed source projects and it works well. (And yes reusing data types across front end and back is awesome, saves a lot of time.)
Integration with other JavaScript frameworks is a great example of something that should be done, but I don't think is necessary to release v1.0.
On the component library, unfortunately this never materialized. A lot of simple components are easy to implement, but there are certainly some tricky things might make sense to abstract away, or at the very least document what the recommended solution is. Also, with TailwindCSS on the rise, there is a good argument against trying to over-wrap various UI components. A lot of UI libraries try to make various assumptions about how exactly a component widget is laid out: E.g. you'll have a text box and a label, error message, hint text, etc. and these all have these little built-in interactions. These have some convenience but almost always also eventually get in your way as styling is tuned and tweaked. So there is some advantage to just steering clear of all of these and maybe just sticking to a place where examples can be dropped - various solution-problem posts, and leave it at that.
Maybe a good next step is to go through and categorize the issues on the project. Off the top of my. head some useful categories would be:
With that categorization done, it would start narrowing down a specific list of items to tackle before labelling v1.0. @owenwaller is this something you would be able to help do work on?
owenwaller
commented
7 months ago @bradleypeabody thanks for the reply
As there are only 96 issues at the minute I can start to work though them. Can you create the three labels you suggested and a 4th of TBD, which I'll use for anything which I'm really not sure about or that I think needs someone to look at, esp as I am not a Javascript expert by any means.
I think you might need to change your repo permissions to give me the ability to change the issue labels and close issues where necessary.
On the component library, I can see where you are coming from. We haven't needed one per say, what we have created so far has been easy enough. So it may not be necessary after all.
TailwindCSS is new to me and has raised an interesting question. But I'll open a new issue on that.
But, I've very glad to hear you have put vugu into production. Can we take that knowledge and document it, or tun it into examples etc as that would really help us.
BTW when you put vugu into production did you use TinyGo or the Go standard compiler? We have been using the later, but could maybe switch to the former, if it can make an HTTPS request from the browser. The TinyGo home page is ambiguous on this point as it says no, but in WASM AFAIK the Go HTTP client maps into the browsers Fetch API.
owenwaller
commented
7 months ago And just to add to my personal v1.0 wish list...
Can we put together a complete example of the full HTML mode?
There is already an issue open on this #217. but we've not be able to get this to work either. We are injecting the bootstrap CSS stylesheets into the HTML header in code ATM. Which works but probably isn't the best way to do this.
Turning the Tacos Store example into an best practice for v1.0 example might be an idea.
bradleypeabody
commented
7 months ago @owenwaller Great and thanks.
I looked at the issue labels and there is already "bug" (anything busted), "enhancement" (feature request) and "maybe-someday" (feature request but a lot of work and no clear quick solution). What I did was added a "before-v1" and "tbd" labels. So I think go ahead and just label with bug or enhancement as appropriate and then also add before-v1 to any of them that seem appropriate to you, or "tbd" to mean "maybe this should be before-v1, not sure yet".
I'm going to see about getting you the access to assign labels to issues, still trying to find where that is configured...
But, I've very glad to hear you have put vugu into production. Can we take that knowledge and document it, or tun it into examples etc as that would really help us.
We'll need to be in touch on this. I agree at least one good example that shows all the best practices would be very useful and apropos for v1.
Can we put together a complete example of the full HTML mode?
Please make an issue for this one, I agree it should be done.
BTW when you put vugu into production did you use TinyGo or the Go standard compiler?
I've been using the regular Go compiler, but TinyGo has come a long way since I originally put in the work to make Vugu functional with it, I'm honestly not sure what functionality works vs doesn't currently. Maybe when we get this example together we can see about attempting to make it work with TinyGo see if it's no problem or if we run into things. I agree the output of TinyGo in terms of size is awesome.
owenwaller
commented
7 months ago @bradleypeabody thanks for the access, as you can see I've started triaging the issues.
I've added a new issue for full HTML mode #217
For the production usage I think this will end up being a combination of an example and documentation.
TinyGo we need to make a v1.0 decision on. I've not tried it so far. We do have open issues in relation to TinyGo though.
owenwaller
commented
7 months ago And just to add to the growing ToDo list for v1.0....
We need to lint the source tree. I've been using the golangci-lint meta-linter which is pedantic but works, so it may need tuning.
We also need to run the Gosec security scanning tool. I've also been using this. The golangci linter includes it, but it always seems to be many versions behind so I've been running it as a separate tool.
Lord-Y
commented
7 months ago And just to add to the growing ToDo list for v1.0....
We need to lint the source tree. I've been using the golangci-lint meta-linter which is pedantic but works, so it may need tuning.
We also need to run the Gosec security scanning tool. I've also been using this. The golangci linter includes it, but it always seems to be many versions behind so I've been running it as a separate tool.
@owenwaller you should check my pull request regarding golangci-lint.
Lord-Y
commented
7 months ago I think that a discord channel will also be needed to connect more people using vugu.
powerman
commented
7 months ago The golangci linter includes it, but it always seems to be many versions behind so I've been running it as a separate tool.
Maybe it was this way in the past, but right now golangci-lint uses latest gosec, so there is no need in using gosec as a separate tool.
alvonwong
commented
7 months ago Best news for me this year . Thanks .
owenwaller
commented
7 months ago @powerman
Ah yes, I just checked. You are correct the latest version of golangci-lint (v1.55.1) is using the latest Gosec (v2.18.2). So, yes no need to run gosec as a separate tool any more.
owenwaller
commented
7 months ago We will need to make a decision on which versions of Go vugu supports. At the minute the in the github action go.yml file we are supporting:
Go versions 1.16.12, 1.17.6 and after @Lord-Y proposed PR 1.21.3 as well.
What I propose is that we do what the Go team does and only support the last two major versions, so in this case go 1.20 and go 1.21. I think we'd then support all of the patch versions implicitly - as they should e forward compatible.
I don't know what this means for the CI though e.g. do we need to build against a major release and all of its patches?
Lord-Y
commented
7 months ago Adding this into the list https://github.com/vugu/vgrun/pull/10
Lord-Y
commented
7 months ago So @bradleypeabody @owenwaller as said in https://github.com/vugu/vugu/pull/248#issuecomment-1806518180 , I made a series of new PR. I'll wait for their approvable or not before creating a new one for go 1.21.x.
Lord-Y
commented
6 months ago @bradleypeabody @owenwaller any news regarding my PRs?
owenwaller
commented
6 months ago Just to keep everyone on this thread in the loop.
@bradleypeabody and I have come up with a new next steps.
See #260
Can you please feedback via this issue (246)? and not the new issue (260)
Thanks.
Hi,
Following up on issue #243
I am working on a project (it is commercial and closed source), that is using Vugu. We are at this point 100% Go based, backing onto a Postgres DB. Using Vugu has given us a substantial amount of code reuse in the browser which would have been difficult to achieve using any other approach.
Our use of Vugu will start to grow over the coming months as we begin to connect the UI to the back end.
We are interested in getting Vugu to a state where we can safely put Vugu into production. The project has now reached the point where we need the understand the effort required achieve this..
At this point we are not looking at new features in Vugu. We want stability.
I think we are more likely to want to focus on areas such as
1) Advice, examples etc on putting Vugu into production beyond what is already in the documentation. It looks like the simplehttp package that the docs suggest is calling the Go tool chain, which we wouldn't do in production for example. So we need to workout and document an alternative approach. 2) At the minute our UI is based around a simple FSM rather than the wiring/routing approach suggested in the documentation. As the number of controls in the page grows the FMS becomes more complex (more states), so it is not clear if (or how) we switch to the component wiring approach. So advice and documentation would be helpful.
3) General housekeeping e.g. closing any outstanding defects, bumping any dependencies to the latest versions so we pick up any security updates. Likewise umping the minimum version of the Go tool chain itself
The one "feature" we would be interesting in seeing is the component library mentioned in the Vugu Readme from November 2020. Without having nay knowledge of what this includes we can't say it it would help us or not. Some visibility of this package would be appreciated.
I appreciate other members of the community may want other features from a v1.0 release. The above list is simply our starting point and not a firm list for a v1.0 feature set. We want to hear what others in the community want.
Can we please use this issue to discuss what work would be required to move Vugu to a v1.0 release and what features, bug fixes etc should be included for everyone's benefit.
Many thanks
Owen