Second, If you decide to create a desktop application, then make it native. I must strongly advise against using any of these "web frameworks" e.g. Electron, QTwebkit etc. to create desktop applications. They are slow, bloated and probably contain many security holes because of the huge complexity of browser engines.

They only exists because many developers don't know anything else than web development, instead of learning new skills they created this abomination. One earlier post said that minumum an i3 was required for the apps to remain snappy, think about it, that is just ridiculous especially in a time where PC's are upgraded much less frequently than they used to be. I would NEVER install an application created using a web framework.

I have good experinces with Rust and Golang when creating native applications for multiple OS.

I know how to write native apps in C# with WPF, Obj-C with Cocoa, C++ with Qt, Erlang with WxWidgets, and even in pure Tcl/Tk. I still prefer using HTML5 to any/all of those. It's about multi-platform portability, where "the web" is itself one of the targeted platforms.

> I would NEVER install an application created using a web framework.

Do you use web apps in a browser? Gmail or Outlook.com, say? Why would them adopting more native UX controls make you stop using them, then?

If it's about the cost in non-shared runtime memory (i.e. basically running 5 separate instances of Chromium for five "apps"), this can be fixed; look, for example, at how the Chrome App Launcher works in Canary. Window-mode Chrome Apps are basically equivalent to Electron apps, but run as sandboxes under a common single-process runtime (Chrome) rather than each being a process of their own.

There are also other GUI toolkit choices which are less mainstream and some may be less stable/documented/maintained.

Edit to add: Don't know about PyQt which is a wrapper for Qt, like wxPython is for wxWidgets.

Update: both Wikipedia and the wxWidgets site show a release this Feb 2016.

We are team of two: I am sole developer and there is another person doing sales, support, training and all the rest of stuff.

- running Paradox in network is quite difficult. Whole database was written in 80s before things like tcp/ip was thought as a good thing and all the networking part was hacked inside and it shows. Because of weird architectural choices made 20+ years ago I am not able to migrate out to sane database without rewriting whole application. (250+k lines of code)

- BDE could be quite unstable in various scenarios and you spend quite a lot of time fiddling with memory space, memory size and other variables to make it work.

My big problem is I have so many code paths that I can’t fully test the interactions between the different modules and functions (there are over 10^25 different possible paths). I am not sure what can be done about this given the functionality of the software is critically dependent on this flexibility. The best I have been able to come up with is testing 99.99% of the most popular paths and building in a lot of error recovery code.

Interesting. Have you considered the pros and cons of writing a custom fuzzer for your app, and whether it may help?

But don't all those paths depend on the inputs, ultimately? Trying to understand this here. Can a fuzzer that generates lots of different inputs, not be used to exercise all those paths?

Can this functionality be separated out into a different process, or called from a DLL compiled using Visual Studio?

The big problem with legacy software without huge user base and limited space for growth is that it just don't make sense to invest huge amount of time and money in it.

Reports are added as an afterthought. Then the resulting spaghetti code patterns are replicated cut & paste, where they then slowly melt into surrounding code in a way that makes them impossible to extricate. After some years, it then becomes obvious that reports are the primary driver of value for those clients.

How big is the EXE?

Currently I am also doing some freelancing (iOS apps) and run my other tiny software company.

Starting this partnership is actually funny story: one day I seen an ad which says "Looking for programmer" and there was no other information or text, no company info nothing. At that time I was product manager with big team reporting to me and I feel quite unhappy, missing my days as a programmer, waking up at 5 am to do some coding for fun. I seen it as a sign, so I just replied, quit my job and the rest is history.

How do you handle patches for prior games into your workflow (i.e. long-term maintenance)? Do you build up an issue queue and then work on patches in between major releases?

Check it out: http://esotericsoftware.com/

[0]: https://www.nngroup.com/articles/response-times-3-important-...

Usually I will middle-click any link to open it in a new tab, then immediately switch back to the original tab while that one is loading. Only when I see that it is loaded (text on the tab turns red) will I switch to it.

All too often I see web-apps as a regression. We have super-fast machines now, but we're choosing to make ourselves dependent on the slowest link in the chain, the network. Might as well go to Pluto. https://blog.codinghorror.com/the-infinite-space-between-wor...

> I have to think about the future, and so I have to try to make the right choice on this..

You don't have to make the right choice right now. For now, focus on getting something complete so that you can prove the idea out.

My problem is with the choice of the best frontend approach, and since I'm only one guy working on this, I am trying to find my "best" decision..

EX: File system tools, AAA FPS, etc.

Concretely, if you create a web-based API, then you can put any front-end on it. If you layer the application correctly, you can move some of the layers closer to the client as needed, adding caching for performance. If the problem is one that can only be solved through a desktop application, then the whole question was moot to begin with.

I've seen enough Excel-spreadsheets-as-million-dollar-business to know that the only thing standing between you and your completed product is yourself, especially when you have technical skills to actually do the work.

In my experience, this is pretty much the same thing as being unable to change your mind.

Get a product out and then figure out where you could have done better.

That's a good place to start. That's 80's and 90's best practice, though. (Most of the industry is stuck in this mindset, to be fair.) I'd say the 21st century version of this would be to structure your code in such a way that transformation tools can be easily applied.

I'm just trying to encourage OP to finish a product and we've gone pretty far from that starting point with this discussion.

Choosing this tech stack lets you postpone web vs desktop app decision and keep both options open. While recurring web app revenue sounds appealing it requires servers and responsibility to secure user data. With desktop app you'll never receive a 3am call that your service is down.

Btw. Subscriptions and desktop apps are not mutually exclusive. We give both options (one-time license purchase or monthly subscription) to our customers and the split is about even.

We had no choice technically-we need to use audio APIs on Win/Mac to get our job done.

Based on my experience, I would not recommend building a desktop app unless there is a technical reason to do so.

Data storage, building installers, signing your app for target OS's, and dealing with auto-update are all technical problems that I'd prefer to avoid if I could. Building cross-platform code is also a pain and, while totally doable, will slow down a team that is not familiar with it, I think.

If I really needed to build a desktop app in the future, I'd investigate building building a headless app that hosts a websocket, and use the user's browser to connect to a localhost websocket to communicate with it. (i.e., a technical choice freeing my from Qt)

My application must draw one SVG chart, and the SVG support on Qt is quite bad although I can render my SVG there..

We do have a tray icon too, though.

So when you browse to our site via the desktop app, certain OS-only features turn on.

So it made a bunch of sense to use QtWebkit. I welcome the switch to QWebEngine though, if for nothing else in the hopes that the underlying browser code gets a update and the app will hopefully then feel more responsive.

Atm we use a mix of QtQuick/QML and some widget code mainly when wrapping QtWebKit it for some parts of the app furniture that need it.

Although the guts of our app requires native code (for clipboard monitoring and websocket message receiving), were considering ditching much of the UI in favour of a webapp.

[1]https://gumroad.com/l/ADWm/tasktopus

The problem is that I know how far I can go with Qt Widgets, but on the same way, I would like to build something more "modern" and Qt Widgets may be quite limited..

My advice - just do it :-). If you want to build a cross-platform desktop app then go for QtQuick/QML/C++. QtCreator has a bunch of example projects. Use those as reference. The Qt docs are solid. Worst case - you will learn that Qt/C++.

I am not a big fan of PyQt/PySide, especially when starting fresh with Qt - you would have a hard time figuring out how everything fits and where the issues are.

[1] https://github.com/papyros/qml-material

Paraphrasing a previous comment:

I have used web-based task/todo lists (trello, asana, etc.) but I wanted something that could be used offline - my work does not allow storing company sensitive data on 3rd-party servers.

Started the project with Electron, using AngularJS and Angular Material. That allowed rapid prototyping with a slick UI and it was fairly easy to find additional Angular-based plugins. My main motivation in selecting Electron and Angular was to learn the two technologies (easier to learn something by doing a project in it). Screenshot: http://imgur.com/NZzEFKX

Had a few issues with the Electron app - big download size (50-70MB zipped), no print functionality, app felt non-native, very convoluted process to get it published on the Mac App Store.

Decided to change the tech stack to Qt/QML. I have published C++-based games, built on Cocos2dx. Wanted to try Qt to build a serious app.

Gumroad has been a slick experience - I have opted for the fully functional trial option and let the user buy a license to use beyond the trial period. Gumroad's onboarding (buy workflow) and tech (license key generation and validation) have been a revelation.

Note that the LGPL version of Qt doesn't contain everything the commercial version does. But there isn't a lot missing.

IMO, if you think you'll ever have edge cases where users might struggle to stay connected to the Web, think about doing a desktop app - but even then, consider using eg Electron/QTWebKit/similar so you can continue to use HTML.

The only situation I would shy away from using the HTML/CSS/JS approach with new general-purpose PC-centric applications is supporting older hardware - I like my apps to remain snappy, but sadly even Webkit tends to lag (generally speaking) on anything older than an i3 or so.

But when you see normal folks totally confused because the developer decided to "upgrade" their experience in a way that was totally out of the users hands, it can be cringey.

I will admit that I far prefer software that runs fully locally; if I don't like the direction a particular program has gone, I can either just use an older version.

And I do also find it jarring to open an app and be met with some new layout or design, or discover a new feature buried in a menu that wasn't there before. It would be really nice if app design was at the point where we could go "okay, here's a bunch of new features, click this button to switch over!"...

Do you really think users will be doing Photoshop and AutoCAD in a browser? No matter if you have a fibre op connection, the lag is always there.

Recently the main player in this ___domain moved to Web apps. There was an overwhelming protest from its customers, who insisted they prefer the desktop version.

The beauty of AutoCAD was that it was designed for power users only. The learning curve was almost vertical...but to me, that's the true sign of a powerful application. Fortunately, I had a high-school drafting class and then took a class at my local community college...having a real-life instructor was invaluable. It was exclusively designed around a "one hand on keyboard, one hand on mouse" stance, but you could do _everything_ from that position.

Once I got over the the initial learning hump and most of the commands became second nature, I could work almost as fast as I could think. I was working on something like a 500Mhz PIII running Win98, and I cannot remember it ever lagging or crashing while I was working.

But the most important thing to me? Since it was a desktop app, it had 100% control over the keyboard and mouse inputs.

  No accidentally closing a tab or refreshing the page.  
  No browser updates f'ing with my right click menu.  
  No scroll-jacking.  
  No zoom-jacking.  
  No shortcut-key overlap with plugins (looking at you, 1Password/google docs)
  No input lag...EVER.

Also if you are offloading stuff to the cloud you need low latency.

https://www.onshape.com/

and as a Photoshop replacement, you have things like :

https://pixlr.com/

And yes, there are people using these online tools.

I don't think this is the case. Facebook never needed desktop apps, did they? The web worked great for them.

On a side-note, didn't Facebook just release a new UWP app and didn't they regret going the HTML5 route to start with (not focusing on native apps)?

I'd add while mobile seems to be the trendy place to start a startup, most productivity apps are still easier and faster to use with a keyboard and mouse. So desktop-first can make sense sometimes.

Initially, it was going to be only desktop, because we were targeting big enterprises who still rely solely on phone for customer service. So, pretty backward companies. A Desktop app would have been perfect and not too "revolutionary".

But, then, we decided to not limit ourselves to that market alone, and have since made the transition to include web and even mobile solutions.

My advice is to: Stop hesitating. Write code (MVP?). Run private and open betas. Collect feedback. Make predictions. Make decisions. Maybe your market will rejoice over your desktop app and maybe they won't. The point is, you won't find out until you actually test it. If it works then that's great. Now, you can focus on marketing and growth. But if the feedback that you get points that your customers would rather get web, then that's also great. Because, now, you've gained an important insight about your customers, and will have a choice of either to switch to web (if it's a true market need (also from customer feedback)) or to start something new.

TLDR: Based on our market research alone, you CAN definitely make a living off of a desktop application; it depends on your customers, that's why it's paramount that real customers test your app asap. Don't worry about the future too much. If your desktop app is successful and somewhere along the line, customers demand a web app instead, you can always scale and adapt.

A couple of days ago I went to an administration worker at a university and asked her to help me with getting the vpn to connect to the net via university wi-fi. She told me to google the vpn to download it. I said: well, this is the very problem, I want to connect to the Internet, I cannot google it while I'm offline. People no longer distinguish between the address bar and google search, searching for files on your local drive or looking for them online. It's become one blob of "computer stuff". And you might think that when we moved from command line in DOS to Windows that was creating a new kind "stupid user". There is the next level, certainly.

We didn't make a living out of it because we wanted to keep it as a hobby project but it paid out well enough to be considered a small business.

I don't have any advice on whether your app should be a desktop or web, it all depends on what is the app, who your users are, where are your users using it, what are your competitors, what is easier to develop, etc.

All I can say is that desktop apps can still be profitable in recent years, but I can't say it will be profitable for your project.

For me, a successful desktop application has the following traits:

-- A nice specific vertical that is deep and complex to process,

-- Complex entry screens with lots of necessary rules and data validation,

-- Lots of manual data manipulation during the events,

-- Substantial benefit from ability to take advantage of desktop level mouse and keyboard actions,

-- Some complex grid based screens that can be tailored by each user,

-- Fairly complex reporting after the events.

These requirements are still too much for browsers to handle well. The grid based screens are especially horrible in browsers. And browser apps are still pretty horrible for complex data entry screens that want to be customized by the user.

That said, I'm porting the first to a mixed mode where the engine will be internet based but the primary interface will still be the "normal" download and install desktop model. This is to allow some portions to be used in a browser, but the main application still keep the full desktop power.

FWIW: my original apps were Delphi based, but the language long ago stagnated and had become tedious (comparatively). Since I'd switched to .NET for contract work, I started my rewrite in C#. But but I ended up hating the server deployment crap with .NET and also of got really tired the direction Microsoft is going in general. I've now switched C# for the desktop side and Google's Go language for the web/model portion. I picked Go primarily for the trivial single executable deployment. While I don't really get much enjoyment out of coding in Go, it is eminently practical for this type of work. (Note for Gophers: I don't think Go is bad either ... just sort of there. I do use it quite a bit these day and do get the "fun vs practical" trade-offs the Go team made.)

But the future may be bleak with Microsoft moving to an app store. Why the F do I want Microsoft sitting between me and my customers. It adds no benefit to me and provides no benefit to my customers for a portable or unzip and go desktop application. Plus they, like Apple and Google, want to become effectively the worlds most expensive payment processors.

It seems that his customers share a lot of characteristics with your ones.

I can't really say I'm making a "living" off of it but for a student I do have a /really/ nice income.

It's a /very/ specific application though. It swims along with the bigger fish like Open Broadcaster Service and xsplit, when they go down, I go down.

What I want to say to you and the others in the thread is: maybe you can extract more money at a different price point by reading that book.

Regardless, it's interesting to look into

I just wish more people shared their experiences on their blogs, because here where I live it is pretty hard to find someone working for themselves..

If you want to retain the name, I recommend looking into how you capitalize / kern / otherwise present the name to try and get you the association you're going for.

1. You can package your web app into electron or similar 2. You can use a portable platform like QT or Xamarin

But more importantly, you should chose the one that will help you conclude that this is a good idea sooner. You'll probably end up rewriting the tool once you get feedback about where it rules and where it sucks.

So I'd say that unless you want to do that side project to learn something new, stick to what you know best (and what you know will work). That'll get you to the point where you can decide whether this is worth pursuing faster.

[1] https://twitter.com/successfulsw

[2] http://www.perfecttableplan.com/

[3] https://successfulsoftware.net/

Subscribed, rooting for your project.

How are you shipping the application to users without Qt or Python installed? Are you using something like cx_freeze?

Whether to go desktop or web really depends on the application itself. Don't try and shoehorn it into one or the other. Ultimately, you'll need to find the right niche. Like in most industries, most people will fail (you usually don't hear their stories) and success will most likely not be immediate.

Doing things solo is tough so some general advice:

- You are going to be wearing many different hats but if you can afford it, contract out what you don't do well (like design, for many programmers). - You have fewer resources but also a lower bottom line. Don't expand without taking that into account, not just for the moment, but for the long term. It will affect how desperate you get with your revenue model. - Don't undercharge (especially if you go desktop). As mentioned, people still appreciate the value of desktop software.

Probably a lot more but those are the main ones plus I have support emails to deal with.

This is incredibly important advice! Marketing & actually finding customers is the hardest part of the business, so if you only need a few customers, you'll be way ahead of the pack.

I know someone who is selling a Photoshop Plugin for $100 and seems to be doing okay from it, even though that's more than the price of Photoshop Elements itself! If your product is valuable enough to your customer, they'll pay for it. If they're earning $100/hour & your product saves them even two hours of work, it's a no-brainer.

> ... plus I have support emails to deal with.

Don't forget this when considering your pricing. Some percentage of your customers will always need support, and you need to account for all those 15 minute blocks where you're helping people. If you're selling a $2 app, a single support email wipes out your earnings from several sales.

I have tested SAAS but have seen that:

* People trust a desktop app more. * People value a desktop app more as they feel they "own" it and will pay more

YMMV

Web Apps immediately invoke an entire side set of knowledge of sysadmin and management that, unless you're comfortable doing that - are a pain.

There are reasons to do web apps, but I don't think ease of operating or development are one of them.

Is this a joke? Or possibly a comment somehow posted from 8 years ago?

Unless you're doing what Jetbrains do (and ship an embedded JRE) relying on Java is adding a barrier to entry on top of "wtf, java? it's 2016 not 1999".

In my career i've had reason to use a small handful of jvm desktop applications. In every case, it was because there is no good alternative, and they were used in spite of being jvm based - if a non-jvm alternative comes along, it gets an instant boost in any comparison, because it isn't tied to the jvm.

However, if you ship your own JVM and use SWT instead of Swing, most of the problems with using Java on the desktop go away.

stephenr - maybe the reason you've only seen crappy Java desktop applications is because you didn't recognise the good ones as Java? For example, here are screenshots of my Java desktop accounting application I've been developing for 9 years:

Mac: http://www.solaraccounts.co.uk/images/screenshots/invoices_m...

Windows: http://www.solaraccounts.co.uk/images/screenshots/invoices.j...

Java with SWT uses native widgets and makes it easy to call platform-specific UI code, so the result can be almost identical to a native application.

I have had good experiences developing JVM apps and then using them. Age of technology has nothing to do prima facie with quality.

If you're interested in shipping a reliable desktop application, you'll take the time to handle the runtime and the associated dependency chain. Similarly to the web, you have to understand your system to do the job well. Unlike the web, you don't immediately confront distributed system operation and maintenance problems.

And, finally, I'd actually suggest Clojure/seesaw for the mode of desktop GUI development, not Java/Swing. And, of course, the customer doesn't care whether you hand-crafted it with magnetic tweezers or used Node 9 Ember Rock Stars. They just want it to work, and work reliably.

It is for a rather small customer group but still works great and is growing modestly.

In my experience the customers expect a subscription based pricing especially with an application that required high-frequency updates (I release a new version once or twice a month).

I mean look at the native mobile apps for FB and everything; I'm sure the majority of users prefer opening the apps to using the browser, so there must be something going for them.

Webapps NEVER feel as responsive or powerful or fit into the look-and-feel of a platform, compared to native apps.

To me, most of the alleged advantages of webapps just look like the excuses of lazy developers, not to mention also a bit of hypocrisy: Would YOU prefer most of your IDEs and development tools to be webapps, or native apps?

- no update process

- support is easier, because you don't have to dig in the users specific setup

- monthly subscription model might be easier to accept for people, if they don't have the feeling of "owning" the software like with traditional desktop apps

- no multiple platforms (although people want apps, but at least, you don't have to also provide Linux and OS X versions)

Disadvantages:

- no offline mode (some people want that)

- some people want the feeling of ownership and privacy

I think as a one-man business, it's easier to maintain a web app than a desktop app.

Rule of thumb #1: if you can build the same application for the desktop or the web, choose the web. Don't think more. My company does Windows drivers and some other operating system internals stuff that is impossible to offer as a web app and this is the reason I can't follow this rule.

My last suggestion is trying to attach your app to other revenue streams such as trainings, customization, integration with other apps, and any other service that make you escape from selling individual (and probably cheap) units of your product.

One thing that makes me want to stay way from web is that if this thing does not work, I would like people to continue using the application, even if I don't update it anymore. If it runs on a server, I will not be able to stop the server until everyone stops using the application for some time. I know some people kill services without thinking too much, but this is a very small niche and my name is relatively known there..

The other reasons of wanting to stay way from web-only is that then I have to take care myself of everyones' data (think application data, settings, etc.); front-end web developments is a pain for me (too many options, none good) as I'm mainly a backend developer; and then there's the latency problem.

As I think I said above, my application is something like a productivity application, where everyone does his own thing and there's no intrinsic need for "social" or "sharing" things. The only reason I can think for web is discoverability, hence my doubts, if "discoverability" beats everything else (for desktop apps)..

Again, I think it is very difficult to attack the desktop market even if you target a niche market for end users. Enteprises uses are a different story.

One more thing if you insist: look at the OSX desktop market too because the dynamics of the end user consumption are different from Windows.

Definitely, even more as I develop primarily on a Mac.. Thanks!

If it works well, then plan for the upgrade circus, or if your market allows it, subscriptions. If it goes south and you get tired of it, just release a final free "sunset" edition.

My experience when I went to look for a job was that I got about 10 interviews and was turned down for all of them because I didn't know about JavaScript, Distributed systems (e.g. load balancers, HTTP caching), WebSockets, deployment pipelines, web services, etc. Don't get my wrong I spent a lot of time reading about all these types of things but until I built an actual API/website it was hard to answer questions about them.

About all I can say to sum up is, yes, pick your app carefully, but solve a problem you've researched and haven't found an easy solution to, and then ... see if you can build that into a business? :) It'd also be fun to build a meta-app: e.g. gamify learning about OS X, such as the activity monitor. Maybe it could be social, where you get points for being the first to get something set up amongst friends on the same wifi? That sounds like an incredibly niche market though...

https://news.ycombinator.com/item?id=11656443

If I go the desktop way, I will probably use Qt (PyQt5) so there's some degree of freedom for cross-platform.

Initially I built this to archive indy music and prevent losing tracks that people removed from their soundcloud pages.

This project would require some major legal hurdles, which is why I've never really built it as a proper desktop app.

Anyhow, my strategy was to make both the web app and the desktop app.

The web app is free, which drives users to the site, a small percentage of which buy the desktop app. The strategy works well, in the sense that I can run everything on autopilot for a few months at a time if I need to.

On the other hand, I sometimes feel like the relative profits are kind of low for the number of users that I have.

Then if you decide later you want it to be a web app its not that big of a job to convert it.

I have worked on a surprising number of desktop apps over the years, including Visual Studio and Internet Explorer. But even before that, a lot of businesses rely on desktop applications for a lot of their internal applications.

[1] http://thehorcrux.com/

Desktop apps make you think a lot more about the release cycle and minimizing potential errors before releasing.

Both have their place. I'll go to a web app for asynchronous communication (e-mail, forums, social media), for one-time reference or reference to things that change often (wikis, imdb), and things that I intend to use for a short amount of time, or which wouldn't be worthwhile to download and install on a couple machines.

Putting things on the web has always felt to me like a compromise of usability and predictability in favor of convenience of access[0]. I like storing my data locally until such time as I explicitly decide to store it online. I like knowing that I can continue using the software, regardless of the fate of the developer.

[0] Given internet connectivity and continued operation of the company providing the software