Our team is currently developing a hybrid application. It is similar to Sigma Estimates - a GUI with tables, forms, a sidebar with a tree structure, etc. The software allows a user to work with a database in the cloud - create table structures according to records in the database.

If the connection to Internet is available, then the software, either a web app or a desktop app, has easy access to the database by sending requests. But a user can also make a copy of that database (precisely, a copy of the current version of the database), so that when there's no Internet, he/she can still access records in it. That is why a desktop app is needed.

I think it goes without saying, that both the web app and desktop app should have the same view, same logic regarding its components - tables and so on.

Should we develop a web app and then try to make a desktop version out of it or the other way around? What technologies could be used?

Previously we have looked into JavaFX, but we saw that it's too difficult to create a website out of that. Then we saw Electron, but we are not sure if it is the right choice, because it seams that Electron is only used for desktop. We were intrigued by Slack's desktop app solution, but our software is slightly different and does not require constant connection to Internet.

  • What kind of application do you have in mind? Commented Jun 23, 2016 at 10:32
  • @BasileStarynkevitch something similar to Sigma Estimates: menus, tables, input fields, tree structure in the sidebar.
    – Justas B.
    Commented Jun 23, 2016 at 10:52
  • That should go into the question (you should edit your question), and you'll better explain in a few sentences what Sigma Estimates or your application would do. Commented Jun 23, 2016 at 10:56
  • 4
    Who came up with that ridiculous requirement use our offline identical-to-website desktop application if the Internet is down Commented Jun 23, 2016 at 11:02
  • @AmazingDreams edited my question.
    – Justas B.
    Commented Jun 23, 2016 at 11:38

2 Answers 2


There is a difference between coding only once and compiling/linking/building only once. The former is desirable; the latter (which I think you are suggesting) is usually not worth the bother.

Code the core of your application in a language which exists both on the desktop and on the web server (and on any mobile devices you can see it being ported to in the future). Design a standard API for it.

  1. On the server side, build a program which receives requests, uses your API to process them, and presents the results in whatever way is appropriate.

  2. On the desktop side, build a program which has a graphical user interface and uses your API to do the actual work.

Even though the internal logic may be the same, the server-side and desktop use cases are sufficiently different that "creating the same .exe file" is quixotic and unnecessary.

I've done this with a substantial project where the core is C++ and the periphery is C++ (server and Windows), Objective-C (Mac and iOS), and Java (Android). Properly partitioned, this reduced the development effort enormously without the heroism of making a single multi-purpose executable file.

  • A good answer, but if the Internet is down, the desktop client won't be able to reach the Web API either. Or did you mean uses the same class library that the Web API does?
    – RubberDuck
    Commented Jun 23, 2016 at 15:43
  • 1
    Same class library. Sorry, I should have realised that "API" can imply "Internet" nowadays. No: everything is linked in, statically, into each program, so the desktop side is independent of the Internet (unless it needs access to remote data, which I can't tell). Commented Jun 23, 2016 at 17:03

You could separate the user interface part (be it web or desktop) from the core application part (they could be different processes communicating thru some IPC). The Model View Controller paradigm or design pattern is probably relevant.

A specific issue regarding Web interfaces is that quite often (but not always, e.g. the embedded web interface of your router box or perhaps a printer) you have many simultaneous users (and web sessions, managed thru cookies), and you might give a way for them to cooperate (or at least "chat") - or on the contrary decide to isolate each user session. Also, web interfaces usually have some JavaScript aspect (with AJAX) for code running inside each browser.

If coding in C++, you might use Qt for the desktop version user interface, and Wt or libonion (or some other HTTP server library) for the web interface. You'll find similar libraries for other languages (e.g. for Ocaml: Ocsigen for the Web UI, and LabGtk for the desktop UI)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.