On Windows, the application will have to be split into two files (client, server), because there is no support at the moment in Crystal for threads under windows (so it will have to be two processes, instead).
This is an alpha version, I have just been working on it for two days, but I believe that with a little bit of efforts it will work on Windows as well.
It works on Mac OS (and in Principe also under Linux, because it contains nothing Mac specific).
As far as the makefile is concerned, it uses exclusively Linux/Mac OS commands; The idea was to use it via MingW on Windows (not from the Windows terminal), but as mentioned before, I’ll have to develop a workaround for the lack of multithreaded support on Windows in a first instance.
Yes, it is just a matter of adding the corresponding entries in the makefile.
I know Vue 3 superficially, but well enough to add basic support for Vue on relatively short term.
I can do it next week if you want.
The advantage of Svelte, beyond the fact that it is very simple to use, is that it comes with its own development server and its own packaging (bundling) utility, so integrating it in the makefile of CrystApp was very easy.
Since Vue can use Vite as well, as you mentioned it, it should be easy.
I am in the process of replacing the Makefile by a command line utility (an executable written in Crystal), so that’s a first step towards making the application more portable (independence from ‘make’).
Well, it compiles in CI, so i just made a fork that allowed to download resulting dll: try4 · konovod/webview@8bc83af · GitHub
It works for me (i’ve slightly changed webview shard too to use dll instead of static compilation), but i understand that proper shard should use more “civilized” approach.
As for a topic app - it was shown in my github recommendations and I thought - wow, so great. But after discovering webview shard i don’t really see a point - if shard allows you to call crystal functions directly from JS world, why use server and communicate through sockets?
then examples work. My usecase is “just for own use” though, as for general case:
I’m not sure it is possible to statically link webview using MSYS2, because Crystal itself uses MSVC linker
I’ve no idea on how to make GUI app (i.e. how to make app that don’t show console window on start). Simply passing @[Link(ldflags: "/subsystem:windows")] isn’t enough, something should be fixed in crystal stdlib.
At this point, I’m wondering if the easiest way to build a portable app using Crystal is not to use a regular browser (in “kiosk” mode) for the front-end app (instead of WebView) and to replace the JS-to-Crystal bindings with simple HTTP communication.
Well, right now i’m using GTK2 + LCL + kipar / No No GUI · GitLab wrapper for some embedded development. Yes, this is madness, but it works. Sadly gtk2 is going to be dead soon.
Idea to use GTK4 or Qt5 bindings is nice, but i would prefer to wrap GUI library in a dll with minimal contact surface, instead of adding pretty big bindings to not-so-fast compile times (and chance that something will be broken after next compiler update).
LibUI would be ideal, but it has way too little features.
Webview2 looks like possible alternative, i’m going to investigate it. I don’t like an approach that uses browser for things that are not related to network communication, but well, if it works it works.
I don’t like Electron-like approach (and approach with kiosk-mode browser) too, but well, that’s just my opinion.