Keeping webui.js

[AlbertShown]

We moved to TypeScript, which gave us many new possibilities. But many users that want to build WebUI wish if they can build it in a few steps as possible.

For those who do not have the ts-to-js converter tool, I suggest creating a new folder, generated in the src folder, to keep our generated webui.js there. So the TS/JS developers can rerun it to re-generate webui.js, while others can easily skip this step as the repo will have an already generated one.

Suggestion: src/client/generated/webui.js

Or simply generate or js.

[JOTSR]

I'm not sure that tracking build output is a good solution as it could introduce confusion and mistakes into the build process. If builds are included in tracking, we can't guarantee that they strictly follow the sources. For example, if you push a tagged version without rebuilding the bridge, you could push an outdated API. Or, if someone edits only the JS and pushes it, it could add divergence between the sources and the dists, which could lead to code loss.

One solution, as suggested in #134, is to release JS within the source code archive.

For the same reason, we should ignore binary tracking in the repo and leave it only for the release archive.

[AlbertShown]

We have two main regular scenarios:

1: Someone wants to download WebUI and embed it into his project. In this case, he can download it from the release section.

2: Someone wants to build WebUI from the source. In this case, he needs to install a C compiler, npm, xxd, and esbuild.

Right now, WebUI v2.0.3 people need only one simple C99 compiler, making the experience straightforward. I'm trying to make the coming version simple too.

I'm a C++/Go developer, and my manager allowed me to contribute to the WebUI during working hours as we are using WebUI in our products. I'm updating the core anyways to serve our needs, so at the end, I simply drop our contribution into this repo. And, no one here has npm, xxd, or esbuild installed.

[AlbertShown]

it could add divergence between the sources and the dists

I agree, but hopefully, a folder name like output or generated can solve the problem.

[AlbertShown]

could introduce confusion and mistakes into the build process

I'm not sure. The build process can simply run esbuild to generate output\webui.js. If esbuild is not installed, then this step is simply skipped and the C-Build process is going to take the old existing webui.js.

Don't forget that only people who have esbuild installed can update webui.js. It's kind of you to update webui.js for us, and we just simply using it :-)

[JOTSR]

I believe that we should not track build files in the repository, as this can lead to consistency and synchronization issues. However, I think that we should add the esbuild and xxd outputs (webui.js and webui.h) directly to the source code archive, so that users who want to build from source can do so without having to install those tools separately.

Currently, the source code archive is just a mirror of the repository, but we can add rebuild files with a GitHub Action before each release.

So, any user can build a release from source without any tools other than a C99 compiler. However, those who want to build the upstream code will need build tools such as esbuild and xxd. These tools are only necessary for contributors, and there is already a .devcontainer that makes it easy to install them. Additionally, esbuild is a very lightweight tool that is available via npm or a bash script. Therefore, I am not sure that it is worth the cost of complicating the repository management to track these build tools, as they do not impact end users who only need to use the releases.

I only mentioned that as a suggestion, and I don't want to impose any constraints on the choices of others as I only want to improve the developer experience. Perhaps getting the thoughts of other contributors can help us make a decision.

[ttytm]

I didn't looked enough into how the js part of webui is interweaved so please forgive if I throw a stupid question in here or there.

Where is the webui.js needed, is it only necessary for the build process? If yes, anyone who just wants use the libary can download the finished builds and don't need to think about the file.

Generally, if some want wants to build something from source, I think it's okay if to require installation of all the dependencies needed to build a project. These are common dependencies to when working with web technologies.

It possible to keep the webui.js in the releases. But if this is that someone can build the library without having to install npm, esbuild and xxd I have trouble immagining the process. The src files are not included when downloading a release, it's just the libary. So users will have to make sure the webui.js file is put into the correct directory in the repository they cloned just to start building without these dependencies. I feel that in the end it's less hassle to just go with the dependencies.

The other way is to keep the generated file in the source code files, so users can get it while cloning the repo. Which I'm also not really a fan of tbh.

[JOTSR]

Where is the webui.js needed, is it only necessary for the build process? If yes, anyone who just wants use the libary can download the finished builds and don't need to think about the file.

Yes it is only for the build process (only for transition from typescript sources to c include) and no js file are keep in the final output. The bridge was rewritten in typescript few times ago and the client build process is:	source code	esbuild bundle output	xxd byte array c header
webui.ts + imports	webui.js	client/webui.h

It possible to keep the webui.js in the releases.

I propose a partially prebuilt project to solve @AlbertShown issue but I also think that dev dependencies are not a big deal, especially if it is popular as npm, but as I'm not aware of common c dev ecosystem and so I take care of not make to fast decisions.

Also, as we plan in #136 (and tested in webui/window_control_api) npm is a good choice to implement git hooks on the repository.

[AlbertShown]

Honestly, you both voted not to keep it, And on top of that even if we leave webui.js in the source code, the end-user still needs to install xxd.

I changed my mind. I vote to simply remove it from the source, but we should work together to write a good Readme instructions to help developers (all of them) to build WebUI from the source.

[ttytm]

I changed my mind. I vote to simply remove it from the source, but we should work together to write a good Readme instructions to help developers (all of them) to build WebUI from the source.

Good point. Related to #155 I'm going to propose an update to the build section in the readme and also wanted to take care of mentioning the dependencies.

[hassandraga]

WebUI Bridge

The new WebUI-Bridge written in TypeScript is impressive. I like it. I already created a dedicated folder, webui/bridge. So, Let's keep this simple, all TypeScript/JavaScript development is inside this folder. While the original webui/src is purely C99.

C/C++ Developers

The C/C++ developers must clone, modify webui/src, and build using any C99 compiler.

TypeScript Developers

The TypeScript developers must clone, modify webui/bridge, transpile, and build using any C99 compiler.

ESBuild

ESBuild is the primary tool to transpile webui/bridge/webui_bridge.ts to webui/bridge/webui_bridge.js.

JS2C.PY

JS2C.PY is the primary script to generate webui/bridge/webui_bridge.h from webui/bridge/webui_bridge.js. I don't like xxd as it is unavailable in all OS. And can not generate webui_bridge.h in the format we want. So I created js2c.py to solve this problem.

I hope you all agree with this.