ToDesktop – Web app to desktop app in minutes
todesktop.com
todesktop.com
- They always feel sluggish. Animations are jittery. Text input that does things (contextual search for example) jitters and jumps instead of smoothly performing it's task.
- Scrolling, especially scrolling that loads content, is also often jittery and laggy, if it doesn't just stop working abruptly and require a reload.
- I can't help but feel it's incredibly unnecessary for these apps to be as MASSIVE as they are. Usually several hundred megabytes at a go. I know storage is cheap these days but I own several games on steam that aren't that pudgy on the disk.
I just don't like them. Every time I download a new app and I realize it's electron or node or react or whatever the new shiny framework is everyone likes, I will remove it unless I absolutely 100% need it to perform a task. And I will likely be groaning and complaining the entire time as I listen to my PC clock up it's fans to deal with running 150MB of bloody javascript to show it's UI.
I know this is largely a me problem, I'm aware of that. But I just don't like them. And especially given that a whole lot of these apps aren't built by scrappy underdog devs but massive firms that could extremely easily afford native developers... I dunno. It rubs me the wrong way.
Like I don't know how else to say this: If you want to make software, make software. If you want to make websites, make websites. Stop trying to make software out of website tools.
- Instantly supports all operating systems and mobile devices
- No need to download/install some .exe files (or your OS equivalent) with all the associated security risks
- A web app will likely get updated more frequently since it's easier to develop and update
I think VS Code proves that web apps can deliver
I look at it this way: Any app deploying to four platforms (web, Mac, Linux, Windows) is going to involve some level of non-native abstraction. (Whatever Adobe seems doing for their UI kit is equally terrible if not worse.)
Also: Websites are indeed software in 2023. I realized the other day that my favorite design app is Figma, and I NEVER thought I'd say that about a non-native app.
I think the optimization here is to have browsers themselves make the "desktop mode" experience much better, removing the need for Electron style projects. You shouldn't have to re-bundle the entire browser to get to it. You shouldn't have to pay $250/mo to have a reasonable installer. There should just be an install for desktop button on the web app. I believe Safari is headed this direction in the upcoming Mac OS release.
Personally, I think we need to figure out a better cross-platform UI API. I'm still surprised that almost 30 years into the Windows / Mac duopoly that we haven't figured out yet.
I understand why someone would think that, but in my experience the economics for product owners aren't significantly different between scrappy underdogs and massive firms.
First, most new products start as a web app. If the product is profitable (or convinces someone with money that it will be profitable) the product owner is granted additional headcount to allocate.
In my experience, adding more user-requested functionality almost always has a higher expected return on investment than making fully native versions of the product for iOS, Android, or Windows. (I have no experience making software for Mac.) As much as I like using native apps myself, there are plenty of cases where I couldn't make a case that creating native versions would have a positive return on investment at all.
In summary, the number of products that are profitable enough to afford native development teams is small, and the number of those products where the native development team would pay for itself in increased profits is smaller still.
There are plenty of exceptions like games, legacy software, realtime systems, libre software, low-level utilities, Mac-only dev shops etc. But otherwise the economics don't seem to work out.
Now we certainly have more options but like, what good is more options that suck? I would personally love to have more software that is more expensive, is updated less frequently, and is made by people who use proper tooling to create and maintain it rather than an avalanche of programs that all do the same thing, badly.
The fact that slack runs worse on an M1 mac than MSN messenger did on a Core 2 Duo in 2007 in my bedroom is a travesty and everyone involved in it should be ashamed of the product they're turning out.
Precisely. In some domains most customers will always choose the cheaper option. In those cases web apps resulted in a race to the bottom. Companies in those domains simply could not afford to cling to native software if they wanted to remain competitive.
But of course you still find lots of native software in domains where a critical mass of customers are willing to pay more (or sacrifice functionality) for qualities like performance, security, reliability, etc. For example: games, fintech, military, virtual reality, video production, realtime controllers. I've worked in a couple of those domains and in those cases I am confident that web apps are a very long way away from displacing native applications.
> everyone involved in it should be ashamed of the product they're turning out
Before judging people for their decisions it's worth understanding why they make them.
I know many developers who take pride in writing extremely performant software. All of them have either shifted to work for companies that are willing to pay them to do that or they've swallowed their pride to feed their kids and they scratch that itch by tinkering with open source or game dev on the weekends.
> Now we certainly have more options but like, what good is more options that suck?
I am not arguing that this situation makes your life better. It doesn't. I sympathize with your frustration and I also like using (and making) performant software.
What I am trying to do is explain how we got here because I think it could help us find a way out. We either have to make performant software significantly cheaper to build or we have to convince customers to pay significantly more for it.
I do understand. I understand it's infinitely cheaper to build a shitty webapp and port it to every platform. I know exactly why this stuff is so ubiquitous. Hell, I've even tried it over a few weekends here and there. There was a time I was looking to get into React simply because everyone and their mother is using it for all the reasons you've outlined here. Eventually though I found a job where a native app is much preferred for exactly the reasons you outline here: It runs better, and our leadership is one that's prepared to lay out a chunk of change to have software they're proud to show off and sell.
In short: I know exactly what the tradeoffs are and why they're made. Doesn't mean I'm not going to judge them for it. It's great web tooling but when used this way it results in mediocre garbage applications that are magnitudes larger than they need to be, more often than not by some combination of developers or management that fundamentally don't care that it runs and feels like shit, and that tells me something about their long term product viability.
> Native notifications
Web browsers already let you create these.
> Auto updates
Browsers usually already do this too! And also they will fetch your app fresh on each visit by default... So I'm not sure why this is a problem we need to solve for web apps.
> Native installers
So, more friction? Just visiting the webpage was too simple?
Anyway some of the other stuff like messing with the dock icon and badge is unique and maybe good. But I genuinely do not understand the appeal of shipping new copies of Chrome for each web service. The browser lets you do everything you need, 99% of the time. The install friction and increased trust burden of native apps is actually a downside that normally would be justified by something like "the app is faster and leaner than a browser". But when you're just shipping a browser that fetches JS and HTML from your server, what's the justification?
1. I can have more ownership of the native app. I can make a copy on my NAS and install as needed
2. I can have more control over what it does. I can deny the firewall and whatever it does it'll do only locally.
3. Native app feels more "once and done". Web app feels more SaaSy. And many of us are getting allergic to everything under the sun wanting five bucks a months for 2 min of use.
For such people as myself, native installer isn't a point of friction, it's an inherent advantage.
Of course there are counterarguments! Native app can have a activation requirement or internet requirement and can do horrible things directly on my file system. Just offering a glimpse of alternate perspectives fwiw :-)
>So, more friction? Just visiting the webpage was too simple?
I've been asked several times by the sales team to add an installer to our web app. They think this adds a feeling of ownership to the user.
Do you have plans to bring the same low friction deployment to mobile?
For myself, I develop native (Swift) apps for Apple devices, and have not found hybrid approaches practical in my own work, but there have been great points made by folks from all sides, in this post.
> If you want to make a desktop app of a website for your personal use, ToDesktop is overkill.
I just want to point out that a lot of us "pros" learn how to use tools like this by semi-personal use.
Therefore, you might want to consider a free personal version that's crippled in a mildly annoying way: For example, no installer, don't sign the app, and have an easily-ignorable nag. (Therefore creating a situation where if I tried to distribute one of these applications for a commercial product it looks unprofessional.)
It creates a great way to "try before you buy," and it has another effect: Free consumer use of ToDesktop can make it a "household name" when developers need to use a tool like this.
I should point out that I've been doing this for at least a decade: I used to use https://fluidapp.com/ for years until I switched to the techniques built into Chrome / Edge / Brave.
We basically do this. You can download ToDesktop Builder and create an app for free on your computer. You just can't sign it and distribute it to your customers.
This is a good point though. We will make it more clear on our landing page.
We put our money where our mouth is as we develop Construct[1], a fully browser-based game development editor. It's only available in the browser. You can install it in Chrome and Edge so it looks much like a locally installed app. We actually used to have an NW.js wrapper for things like file system access, but browsers now support enough features (including the File System Access API in Chrome/Edge) that we retired the NW.js wrapper and just do everything 100% in the browser now. It works great for us and I think it will only get better.
The only issue is, it's hard to commit $99/mo for a solo developer to trial a small app. (I know it's pennies for businesses)
I'm asking because my firm makes a competitor to ToDesktop (sort of) [1], and this is a question we often get. It's free for open source apps and cheaper than ToDesktop, but the "I just want to trial an idea and not spend any money on it" use case isn't well supported by this pricing model.
One possibility is a trial period, but then how long should it be? Alternatively some mechanism that limits the number of installs, and which therefore has a lower price point attached.
However it seems a bit pointless because signing certificates cost on the order of hundreds of dollars a year anyway, and then file hosting also adds cost. So if you aren't willing to commit on the order of that much up front, then it may be a lost cause. To drive costs lower you need to take signing out of the equation entirely, which means someone else signs and sandboxes the resulting code.
A dev team can click the "Run Untrusted Program" button, and it serves as an incentive to upgrade before distributing.
Then there's the question of how long a trial would last. It could take months until someone decides whether their app is going to fly or not.
If I were trialing your service, it'd be to figure out how it works into my dev process and the decision to purchase would come before I'm sending executable out to anyone but my dev team.
At that point, it's locked in to an extent - I'm not going to want to tell my users "Actually, don't update the app using the automatic updater, go download a new exe instead and use the automatic updater on that one from now on." since that kind of friction can cost a lot of users.
Now, what if you want to distribute within your team? Well, then your compadres would need to run a localhost server too if they want to see updates working. But that's probably OK.
This lets you run the purchasing process in parallel with getting it set up if your company is slow to authorize payments (the tool will give you a payment link you can send to anyone).
From my view, as a solo dev with a lot of small clients and personal projects, I start a lot of projects that make their way into the hands of collaborators but never make it to a project that's ready to finish. I would loathe to pay that kind of price for those.
But if I'm at the point where I have beta testers and other kinds of non-client/dev personnel, I'm a lot more ready to put down significant cash for dev tooling.
1) What are the "plugins" a pro subscription gives me. I could only see info on filesystem access in the docs.
2) Likewise, what is the "restricted API" that pro subscription brings.
3) Do I have any control over the "updates". For example, when I release a native app, I would want it to "update" to that.
4) I am curious of the choice of electron over using the native browser libraries, given that the applications it targets are always web-first. Is there any reason you decided to go that route?
5) What happens in the event I cancel the subscription? Will the apps cease to work? How is this presented to the end user?
We have a bunch of plugins and are adding more all the time. Currently we have: * Active Window - Retrieve app metadata from the currently-active window of the OS. * Selected Text - Retrieve the currently-selected text from any application. * Active Icon - Retrieve the OS icon for a target file or application. * File System * File Exec - Bundle java/python/whatever binaries with your app and run them as a background server * Communication Server - Communicate between your app running in the web browser and your desktop app.
Usually a customer will ask "can I do x" and if the answer is no then usually we will build it out as a plugin.
> 3) Do I have any control over the "updates". For example, when I release a native app, I would want it to "update" to that.
By default we automatically update apps but we also have an API if customers want to programmatically control the update flow.
> 4) I am curious of the choice of electron over using the native browser libraries, given that the applications it targets are always web-first. Is there any reason you decided to go that route?
Electron is remarkably solid with a very mature API. It's much more battle-tested than the alternatives given that a lot of the most popular desktop apps use Electron.
> 5) What happens in the event I cancel the subscription? Will the apps cease to work? How is this presented to the end user?
Updates will stop working so you can't update your app. We don't currently block apps when subs are cancelled (except in cases of abuse) but we will likely do something in the future if a customer has cancelled their subscription but are still actively advertising their app on their site for example.
Wow, it'd take a witness stand to get me to admit something like this.
Actively seeking a method to stop your former customers from offering their finished product because they no longer see a need to pay for your service is a good reason to never use your service.
Wow! I've been a fan of Orion for a while and I didn't know it did that. Lo and behold, "Tools -> Install This Site as an App". Thank you for the pointer!
As a solo developer, I avoided building a desktop app for months, mainly due to worrying about the maintenance overhead. I built the desktop app within a single day with ToDesktop Builder, and there has been no notable maintenance/overhead since (other than me over-engineering some features/enhancements).
ToDesktop's deployments are super smooth. The API and docs are pleasant to work with, which made integrating Conjure's habit and time tracking through the menu bar, native notifications, and multiple windows fairly straightforward.
I did worry about the performance and resource consumption with Electron-based apps, but the Apple M1/M2 Chips absolved that concern. Most of my users (mainly Mac and Windows) don't seem to mind/care/notice the Electron nature of the app.
Disclaimer: I'm also friends with the founder, he's from the same town as me in Ireland.
And what is this "download links on your domain" feature for the $240/month option? Are you really advertising a URL rewrite as a paid feature?
We deserve a better SSB implementation. Stuff like 1-click-install would be dead simple if a browser would do it properly. Notifications, multiple instances, extensions and without the overhead from atom or toDesktop or whatever.
If you know what you are doing, making websites is easy. But most people don't and that's why things like wordpress, squarespace, webflow, tumblr, medium, substack, etc. exist.
I'm not saying it's impossible to make a good native app with web technologies, only that you can _ALWAYS_ make a better one using native tech.
1. Slack 2. Discord 3. Signal 4. Mullvad VPN 5. Kate 6. 1Password 7. Emacs 8. Chrome 9. Spotify 10. Konsole
How many of these wouldn't exist on Linux if they had to be written with native SDKs? Konsole and Kate use QT and are clearly the best UX, but it's not like emacs (gtk) integrates natively in KDE any better than Slack does. Zoom is clearly the worst experience of all of them, and I think that's actually a QT app?
I don't think the concept of wanting to used this advanced interface is wrong, just that the implementation of Electron is bloated - and that web programming culture is far too wasteful because the premise there will only be one important app on the computer.
I have not tried sciter, but making a fast, light Electron alternative is the right way to go. To go with that, I would like to see a new emphasis on fast and light js/css libraries and frameworks that treat desktop as a first class citizen, using light SVGs instead of big raster images, automatically generating stripped down icon packs rather than loading all of fontawesome etc.
That looks like a much more promising way forward than any other UI framework I have seen. The interface with a myriad of languages for actual hardware access and local file/data manipulation are already there for the most part.
Because of this overwhelming benefit in my opinion, it is worth it to go through the development pains to get there as the easiest path to a better dev experience, rather than trying to use some other tech and bring it up to web UI quality and flexibility.
• Very few core widgets. Everyone has to supply their own.
• Poor/non-existent support for menus.
• Poor support for keyboard accelerators.
• Rich text editing is ropey, and you have to supply your own UI.
• No table views, tree views, or virtualized list views.
• Multiple incompatible DSLs all of which get wrapped in practice.
• Only accessible from one programming language.
• Only recently got any built-in notion of components.
Electron is convenient because lots of people know HTML and because it lets you incrementally upgrade a pre-existing web app. But if you know you'll be on the desktop anyway there are toolkits that solve the above problems, some of which meet your requirement of being lighter whilst still using stuff like CSS or SVG. Qt fits the bill and if you're not a C++/Qt person, JavaFX also uses a dialect of CSS (which can be compiled to binary even) whilst still offering a fairly complete widget set out of the box. It can be compiled down to a fully native binary these days, and even streamed over the web (see https://www.jfx-central.com/ for a demo).
So once you leave the browser you have a far greater array of UI options available to you. Power users in particular tend to appreciate the productivity of standard desktop UI paradigms.
And they're all equally easy to distribute these days. Conveyor will ship anything, it just has some sensible defaults for Electron/JVM/Flutter apps. Fully native apps work too, though.
There are many additional features a web app is capable of when installed, like native notifications, file system access, file associations, etc.
They do offer benefits to the app purveyor, because apps have access to your system that you'd never allow a web site to have.