Including javascripts for web?

[0pcom]

Describe the feature

I really like the look and feel of cogentcore .

One use case I had in mind is as a framework for a webstore. Has such a use case been considered?

While it might work well for displaying a product inventory, keeping track of a shopping cart, etc. it won't be possible to actually integrate a payment into this without the ability to add arbitrary scripts used for stripe or other payment processors.

I'm unsure of the practicality of permitting scripts to be added to the web version of a cogentcore app. It would undoubtedly break the non-web version of the app or at least there would be a divergence in the behavior of the desktop vs web app.

If it were possible to easily or automatically convert javascript directly to golang webassembly, this might be a better route to take. However it's almost guaranteed to not work the same on desktop as in the browser even if that were possible.

If such a payment integration were possible, or an example existed, it would not be a difficult decision to use cogentcore for such an application in production.

Relevant code

No response

[kkoreilly]

If you only need to support running on web, you could link arbitrary JS scripts in the index.html and call necessary JS functions using syscall/js. However, for cross-platform support, it would probably be easier to use a Stripe payment link. At some point, our htmlcore package will support JS to such an extent that you could manage everything directly in the app through that, but until then you can use one of the other two options. If you decide you want to do any of those options and need help implementing it, I can help you figure it out.

[0pcom]

I am tempted to attempt one of those alternatives ; perhaps you are right that a payment link might be easier.

the only thing it appears will not be possible for the cogent web app is animation. But if, as you say, it is possible to include arbitrary scripts, then perhaps it may further be possible to include basically my existing animation wasm and run that alongside the cogentcore app?

The animation in question is somewhat similar to this: https://0magnet.github.io/wasm-stuff/

It would be best if cogent core could directly support that type of animation

[kkoreilly]

You could try using a canvas for the animation, which would be easier than trying to superimpose an existing wasm animation on an app.

[0pcom]

ok I will see what I can do on it and file a ticket if I find any bugs. I sincerely appreciate your time in answering my questions

[0pcom]

After spending some time playing with core, running some example apps, and building the desktop / web version of apps It is not immediately apparent if there is a way to do client / server web apps. The web view (core build web && core run web) compiles to basically static html with a (sizable) wasm binary.

Am I missing something?

I'm not sure that I explicitly need this for my current project (involving stripe payment integration) - though this is my current setup ; but in considering some of my other projects where a cogent core app might be useful or advantageous over the existing web interface, I would likely need a dynamic application or client-server connection. (Or to reconsider how I'm implementing this.)

Basically, there is some non-public data that the server filters in order to create a public view of the data - on both projects where I'm considering using cogent core. The server application looks at files on a disk which are not otherwise served as they exist. These files shouldn't be filtered on the client side or exposed publicly.

For both of these projects, the files in question are basically some .csv files where I don't want to show every column.

On the latter project, the server side may interact with a blockchain using external dependencies / cli interface (basically via os.Exec).

Both projects are currently self-hosted.

The size of the webassembly binary that core build web creates is much much larger than what is currently being served by either project, so I'm unsure it would be feasible to self-host this if I rewrite it to use cogent core, because of the increase in bandwidth usage. Which might be ok ; I might get by with hosting it on github. There are just some significant trade-offs to consider.

I like a dynamic server, self-hosted approach because the data being viewed can 'live update', i.e. any changes made on the csv will basically be immediately reflected on the web interface.

Your insights are sincerely appreciated, thanks.

[kkoreilly]

Thank you for asking about this. Cogent Core apps are served statically, but that does not limit your ability to interact with a dynamic server.

For example, based on your situation, I would recommend serving the wasm binary on GitHub Pages or some other static site host, and then separately hosting a dynamic server that you make http requests to. You can easily use the standard http library or any other http request package to send requests to your server from the Cogent Core app and then use that http response data to populate the GUI. In that sense, Cogent Core serves the role that HTML/CSS/JS would normally serve, and then you still have a separate server that you make requests to.

So, for example, you could have an example.com/api/getInfo API endpoint that you host using a separate dynamic server, and then you make requests to that endpoint in Cogent Core, parse the CSV, and display it in a table. You could also have some streaming API endpoint where you leave the connection open to get live data updates.

In other words, you can have a client-server connection where the client is Cogent Core and the server is hosted separately. If you want, you could also host the Cogent Core app files on the same server, since they are just static files that you can easily serve, but there is no advantage to that over using a separate static site host.

In terms of the wasm binary size that you mentioned, we are working on reducing that (#733), with a future transition to GopherJS likely to cause significant size reductions (#974).

Please let me know if you have any other questions or concerns.