server : (web ui) Various improvements, now use vite as bundler

[ngxson]

Motivation

The new web UI has received significantly more positive feedback than anticipated, prompting consideration for further enhancements.

Currently, we operate without a bundler, running code directly from index.html and 3rd party libraries from deps.sh. However, this approach has limitations, particularly with daisyui component compatibility. It also leave a big binary size with many redundant parts inside.

Given that many llama.cpp contributors have a lower-level programming background, here's a brief overview of the current UI tech stack and why we need to use them:

• Tailwindcss: A CSS framework that simplifies styling, used by major platforms like ChatGPT, Claude, and Hugging Face
• Daisyui: A tailwindcss-based component library offering ready-to-use elements like chat bubbles, buttons, and themes
• Due to the large size of these libraries (up to 2MB for pre-compiled versions), we need vite as a bundler to eliminate unused code. This also enables compilation into a single .html file, eliminating runtime dependencies.

Improvements

Key updates in this PR:

• Project relocated to server/webui using npm for dependency management (with deps.sh script removed)
• Integration of vite bundler (build instructions in server/README.md). Output index.html size is just under 500kb, which is smaller than the old approach with deps.sh (Remind: this new index.html contains everything needed)
• Enhanced mobile compatibility (screenshots below)

For binary size, this PR recudes 1MB of the final compiled binary compared to master:

# master
$ ls -lah llama-server
-rwxr-xr-x  1 ngxson  staff   5.5M Nov 30 15:02 llama-server

# PR
-rwxr-xr-x  1 ngxson  staff   4.5M Nov 30 14:52 llama-server

|

[ggerganov]

Do I need to do any extra steps? I pulled your branch and run llama-server like this:

cd build
make -j && ./bin/llama-server -m ../models/qwen2.5-32b-instruct/ggml-model-q8_0.gguf

...

0.01.190.151 I srv          init: initializing slots, n_slots = 1
0.01.190.163 I slot         init: id  0 | task -1 | new slot n_ctx_slot = 4096
0.01.190.233 I main: model loaded
0.01.190.255 I main: chat template, built_in: 1, chat_example: '<|im_start|>system
You are a helpful assistant<|im_end|>
<|im_start|>user
Hello<|im_end|>
<|im_start|>assistant
Hi there<|im_end|>
<|im_start|>user
How are you?<|im_end|>
<|im_start|>assistant
'
0.01.190.257 I main: server is listening on http://127.0.0.1:8080 - starting the main loop
0.01.190.259 I srv  update_slots: all slots are idle

But it renders like this in the browser:

If I go back to master, it renders OK.

[ngxson]

@ggerganov Could you try make clean? In the initial PR, some users reported that the generated .hpp files are not up-to-date. I added some rules to clean it in Makefile

	find examples/server -type f -name "*.js.hpp"   -delete
	find examples/server -type f -name "*.mjs.hpp"  -delete
	find examples/server -type f -name "*.css.hpp"  -delete
	find examples/server -type f -name "*.html.hpp" -delete

[slaren]

I had the same issue as @ggerganov. Running make clean and reconfiguring the cmake build fixed it for me.

However, just reconfiguring cmake is not enough to fix it. That should be fixed, or it is going to be very confusing.

[ggerganov]

Yes, make clean in the root folder and then reconfiguring the cmake build did it.

[ngxson]

I think I have found a fix, after playing around a bit more with Makefile's .PHONY and cmake's set_source_files_properties (Not sure if this is the correct way, but feel free to suggest other improvements)

[ggerganov]

The CMake build still requires to run make clean in the root folder if you have used the Makefile build previously. Can we update the CMake to do the find ... -delete stuff? We will soon remove the Makefile build so no need to worry about it, but the CMake build is affected as it is.

[ngxson]

I added a pre-build step to remove the generated .hpp files

[pothitos]

Many thanks for the new awesome front-end 🙏

I added a pre-build step to remove the generated .hpp files

Unfortunately, this change causes llama-server to recompile every time you run CMake, even when no files have changed.

I don't know if it's correct to write here this comment or should I open an issue?

[ngxson]

I don't observe the same behavior on my side (running cmake --build the second time does not rebuild everything)

cmake --build build -j --target llama-server
[  4%] Built target build_info
[ 20%] Built target ggml-base
[ 28%] Built target ggml-metal
[ 32%] Built target ggml-blas
[ 52%] Built target ggml-cpu
[ 56%] Built target ggml
[ 72%] Built target llama
[ 92%] Built target common
[100%] Built target llama-server

[slaren]

It does rebuild server.cpp, since it depends on the generated file. You should be able to see it with -v. I think the cleaner solution would be to move all the generated files to the cmake directory, and do not delete them. cmake should be able to regenerate them automatically when necessary, and removing the build directory always results in a clean start.

I imagine that the reason it doesn't work like that in the first place is because we needed to support the Makefile, but that's no longer the case.