This is an architectural question pertaining to distributing desktop applications on Windows, Mac and/or Linux - not looking for software/framework recommendations.


Much has been written on the various advantages/disadvantages of Single Page Applications (SPA - React, Vue, Svelte, etc...) vs Server Side Rendering (SSR - Ruby on Rails with TurboLinks, Django, Node, Elixir/Phoenix etc...) approaches.

Some starting points for this debate:



Taking the usual risks inherent in summarizing a complex topic:

SPAs offer great client side performance & the ability to carry on working offline with the downsides (for some) of having to navigate a complex node web development world and (again only for some) of having to use lots of javascript.

SSRs offer great developer ergonomics as people can develop most of their application in their favorite back-end language of choice and their are clever workarounds to keep performance good enough for nearly all use cases BUT a weakness is that full offline usage cannot be catered for!

Potential Solution for Critiquing

Deploy a small embedded web/http server in your desktop application written in your backend language of choice (Elixir, Ruby, Python, Node, Deno,....) and then you will have the advantage that (1) performance will be even better than SSR (can't beat localhost) and (2) you will be able to continue working when offline.

Some downsides that I can think of would be:

  1. You would need to package a full runtime with your app or at least ensure that the client has (say for example) Python version 3.x.y installed on his machine and that it is in the Path etc...
  2. Distributing updates will be more difficult than just deploying to your own web server - but whatever update script is run is largely just copying new text files over old text files so this seems achievable
  3. Data will have to be kept client side (for true offline availability) in some sort of synchronizing database like CouchDb but there seem to be a number of potential master-master syncing database available. This may not be feasible for a large db or sensitive information.

In practice I would see this being achieved by launching a "controller" executable that (1) starts up your web server on a free port and then (2) launches your default web-browser in a similar style to how PWAs are launched (in a dedicated window sans browser ornamentation). The same "controller" would be responsible for stopping the web server when the user exits the browser window.

Are there any other disadvantages that I am not thinking of above?

  • Have you taken a look at FossilSCM? It does exactly what you are considering, and has a model for synchronisation built in. – Kain0_0 Jul 29 at 9:07
  • 2
    Maybe I am being dumb: How is this different from what all those "pseudo-native" frameworks like Electron already do? – Jörg W Mittag Jul 29 at 9:15
  • 2
    What is the usecase you are trying to solve with such a set up? Is it instead of developing a "normal" desktop application or something else? – Frederik Banke Jul 29 at 10:32
  • 2
    It isn't easy to discuss without having a use case. All solutions are just tools with tradeoffs. I think that the main issue is complexity. Developing a native desktop app is less complicated than browser, Javascript, webserver, backend, database. Så unless there is a particular reason for it, I would probably go with the desktop app. – Frederik Banke Jul 29 at 12:12
  • 2
    can't beat localhost I would caution against this assumption and say that it depends heavily on your application and target users. On more than one occasion I've had to deal with issues caused by customers giving their employees five-year-old junk machines that could barely run a web browser, let alone any kind of server. – Dan Wilson Jul 29 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.