So I’m building a clojure-based, gui application that will be largely local and thus not requiring an Internet connection. I don’t plan to host a web server to run it.
So that means I’m making a local app. I originally planned to use fn-fx to make the GUI using JavaFX, but the library seems clunky and hard to extend for more complicated solutions. I’m going to be rendering Markdown into HTML anyway, so a browser-based solution could be better since I’ll have to embed a browser instance in the JavaFx to show the HTML.
That left me with Electron vs just having a web server and having users open the application in their browser. Which seems better? I don’t think I need the native features of Electron, but it could provide a smoother experience for my users.
A bit more information about the program, I have a prototype version here, made with fn-fx. It’s a modular program designed to allow different features to be added and removed by the user, so I probably need access to the filesystem to allow different jars to be loaded. I don’t want this to be a web application in the sense that I would need to host a web server, because I’m not sure I have the time/money for that and don’t want the application so tied to me for the rest of its existence, and I don’t want users to have to setup their own web server each time (though a self-contained webserver that opened up a browser page to localhost doesn’t bother me, unless that seems to un-userfriendly).
Did you look at Progressive Web Apps ? Just saying, don’t know if it is useful for you.
I hadn’t heard of those. That could be best, thanks for the suggestion.
So I’ve looked into it a little more, and I don’t think it will work out so well since I don’t want to be in charge of hosting a full web server, I’d rather have them download a single jar/binary. (And I want people to be able to install modules which we’ll differ from install to install, and that’s hard to do with web servers). Thanks for the suggestion though, it’s cool to know about that type of web app.
In this case, if you need to sync clients to a server it means you’ll need a web server anyway. If you want to have each client install so called modules, maybe Electron is a better fit because you’ll have access to the file system to store them.
I don’t understand fully your problem though. Hope this helps!
Yeah I can see I haven’t been the clearest. I edited the post to be a little more detailed, is that clearer?
Embedding a web server inside your application can work really well, using a lightweight framework like http-kit. That is what I did in afterglow. You can even automatically open a web browser window on your UI when the user launches your executable Jar, using
clojure.java.browse/browse-url. My code which starts my embedded web server then optionally opens a new browser window on its home page is here.
I also took the other approach of using desktop UI elements in a spinoff project, beat-link-trigger. (I used seesaw rather than fn-fx, because I was familiar with Swing, heck I helped write a book about it, but have never used JavaFX). This approach also worked great, except I did end up with some frustrated people who wanted to run beat-link-trigger on a small Raspberry Pi on stage where it had easy access to the DJ equipment, and control it remotely from a laptop in the lighting booth, and headless operation via an embedded web server would have made that possible. I may someday refactor the program so the UI is abstracted and it can operate in both modes, but that’d be a lot of work at this point.
So, basically, I’m saying either approach can work well. You can embed a web server and still be a simple single jar/binary like afterglow, or you can build a native UI. Since you are already planning to work with HTML, the embedded web server sounds like it will give you the most flexibility and be easier.
My project is Portable Desktop WebApp.Jar based Luminus:
Luminus + http-kit + clojure + hiccup +clojurescript(only apply to HtmlUI event) + Postgresql + R + core.logic
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.