7 ms·

ToDesktop – Web app to desktop app in minutes

71 points by herbertl 3y ago

supermatt 3y ago
This seems like a quick and easy way for me to have an interim version of my desktop app. I have a few questions: 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? The pricing feels a bit off to me. Its just below the "ill just wrap it in electron" cost for a one-off, but I am not sure if i would be happy to pay it as an ongoing fee given the lack of apparent value-add at the basic tier.
- davej 3y ago
  > 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. 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.
  - devmor 3y ago
    >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.
    - davej 3y ago
      To clarify: we host the initial download of the app on our CDN so we would most likely block the initial download of the app. It seems pretty reasonable to me that if a customer doesn't pay for a sub then they can no longer offer it as a download to their customers.
      - devmor 3y ago
        That is much less horrible than your wording made it sound - so if a customer is hosting the download on their own website, you are not trying to stop that in any way, correct?
mulhoon 3y ago
This has been on my radar for a while. It's so impressive. Bundling electron for all platforms can be a real headache. 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)
- davej 3y ago
  Feel free to drop me an email dave[at]todesktop or dm @davej on Twitter. I started ToDesktop as an indie hacker, so I understand where you're coming from. Hopefully can figure out something that works for you. :)
- mike_hearn 3y ago
  What do you think is a fair price for a solo dev trialling a small app? 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. [1] https://hydraulic.dev/ https://hydraulic.dev/
  - devmor 3y ago
    Sounds to me like "trial" apps skipping the signing process is a good option. A dev team can click the "Run Untrusted Program" button, and it serves as an incentive to upgrade before distributing.
    - mike_hearn 3y ago
      Well, Conveyor can already self sign and produce a download page with instructions telling the users what to do. It's fine for internal demos and dev teams indeed. But browsers/operating systems will generate security warnings, and so that might be offputting to end users. You'd be unsure if your app was struggling due to that, or due to some product flaw. 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.
TruthWillHurt 3y ago
Yo dawg I hear you like apps, so we put an app in the browser in your app...
resonious 3y ago
I gotta say, I'm not super convinced by a lot of the points on here. > 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?
- NikolaNovak 3y ago
  Strictly fwiw - There is a subset of people, myself included, who have old fashioned preference for native apps. In particular, a few likely obsolete perspectives : 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 :-)
  - philote 3y ago
    I'm curious, what native apps that are also available a web app do you store an offline copy of on your NAS? And which do you deny access to in your firewall?
  - resonious 3y ago
    This is totally good. But I do wonder how much these points apply to a native app generated from a website using the tool in the link. I get the feeling it will still be very SaaSy (a la Slack's "native app").
dusted 3y ago
Stop trying to make desktop software with web technologies, they are all slower and suckier than their counterparts. 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.
- ttyyzz 3y ago
  I fully agree and very much like vs code at the same time.
- franga2000 3y ago
  I hate Electron apps as much as the next guy, but I'll take a cross-platform wrapped web app any day over a native app that is available only on Windows because the developers didn't have the time do make three separate apps.
- stevepike 3y ago
  So I'm sitting here on a linux (KDE) desktop machine with the following apps open: 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?
  - peterkelly 3y ago
    All these apps could be written in Qt and would then work on all platforms.
    - lawgimenez 3y ago
      Like Telegram.
  - voidpepe 3y ago
    You are correct, but I still feel like we need a better way of making cross-platform desktop applications than just wrapping a webapp into a bunch of bloat. Web technologies were never meant for this and it pains me to see a messaging desktop app clog up 100s of MB of memory
cloudengineer94 3y ago
I'd rather have a pure web app than a janky desktop app made with Electron or some other tech that eats my RAM.
ToucanLoucan 3y ago
I'll be honest: I make a concentrated effort to avoid these apps that are just a website stuffed into a (usually quite gigantic) executable for a number of reasons: - 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.
- loremchecksum 3y ago
  I sometimes wonder what the total emission cost of these non-native developments amounts to.
  - mble 3y ago
    Huge most probably. The fact that we need to upgrade our hardware every three or so years, not because our workflow changed, but because every app is written as cheaply as possible shows how much of an impact it has.
- JSavageOne 3y ago
  Some benefits of websites as apps - 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
kevsim 3y ago
Unsolicited praise - we've been using ToDesktop at Kitemaker for a while now and we're super happy with it. The team is always super responsive to our requests and the product has been very stable. We were rolling our own Electron app before and it was an annoying headache. Just having a tool that takes care of all the updates, Apple signing and is consistently adding new/useful APIs for us to tap into is a big win. I get that some teams aren't interested in having an Electron app, and that's cool, but if you are, give this a shot because it'll for sure save you time.
egonschiele 3y ago
This looks interesting to me, but the cheapest tier is $99/month. Why is it so expensive? Isn't this just building an Electron app for you?
- jillesvangurp 3y ago
  This is aimed at people who lack the ability to do that. Lots of not so technical people that operate small websites that don't employ developers. 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.
  - egonschiele 3y ago
    To that point, though, aren't those services $10 - $30 per month? If they're able to sell this for $99 - $240/month, surely they'll see competition, leading to a race to the bottom?
TimMeade 3y ago
This seems really expensive to just wrap in electron. I do not see anything about app store insertion either. Am i missing something?
davej 3y ago
Oh wow, It's exciting to see this pop up on HN. I'm Dave, founder of ToDesktop. Feel free to reply to this and I'm happy to answer any questions :).
- Lightbody 3y ago
  Nice work! Do you have plans to bring the same low friction deployment to mobile?
  - davej 3y ago
    Not currently, there's still a lot to do with the desktop platform!
- ChrisMarshallNY 3y ago
  Good luck, Dave. 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.
  - davej 3y ago
    Thanks for the kind words Chris! I completely agree.
- gwbas1c 3y ago
  > Is ToDesktop For Me? > 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/ https://fluidapp.com/ for years until I switched to the techniques built into Chrome / Edge / Brave.
AshleysBrain 3y ago
It looks like a well executed product, but I believe the future is to move towards running in the browser only, rather than browser wrappers for the desktop. For example, isn't just visiting a URL in your browser so much more easy and convenient than having to have an installer? Isn't it nice to use the already-installed browser rather than ship a full browser engine with the app? 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. [1] https://www.construct.net https://www.construct.net
- phalangion 3y ago
  Sometimes yes, sometimes no. A web app having its own icon and spot in the dock/task bar makes it easier to switch to.
  - twism 3y ago
    Safari supports this if you install a web app as a standalone app. I'm I missing something here?
- rmilejczz 3y ago
  This is my thought as well, if you want your web app to function as a native app then make it progressive. Perhaps ToDesktop offers us something the PWA does not
philote 3y ago
For those more knowledgeable than me, why use something like this over making your web app into a PWA?
- devmor 3y ago
  Most people don't know PWAs exist due to poor platform support/advertisement.
  - philote 3y ago
    What do you mean by poor platform support?
    - lefixx 3y ago
      Mozilla prism has been discontinued. Firefox first removed the feature by default and then removed it completely. IOS-add-to-home-screen always sucked. 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.
- jillesvangurp 3y ago
  The installation experience for PWAs is still pretty poor. I've seen very few good examples of PWAs (probably because of this). And I've even bothered implementing a few. My conclusion after doing that: waste of time, users mostly ignore PWAs.
  - philote 3y ago
    I thought you could publish them on app stores. What makes the installation process poor?
devmor 3y ago
A monthly fee for a build tool that provides no ongoing benefit other than continuing to exist is a ridiculous pricing strategy. Especially $99 for solo. 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?
lawgimenez 3y ago
Creating a calendar app with web technologies is a mortal sin.
whelton 3y ago
I use ToDesktop for Conjure[0], and I love it. Given the nature of Conjure (Habit and Time Tracking), having a desktop app was important to many users, and many now use it instead of the web version (myself included). 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. [0] https://conjure.so https://conjure.so
lefixx 3y ago
What happened to SSBs :(
butz 3y ago
Funny, when Firefox still does not have "add to desktop" support, while all major (and some minor, like GNOME Web) browsers are shipping it for quite a while now. And there won't be a better solution to run web applications safely, other than browser that gets regular updates.
kbd 3y ago
It's been frustrating that for years Mac has had no native way to create a site-specific browser. Chrome can do it for you on Windows. On Mac there is stuff like Fluid, but for reasons I don't remember every time I try it I wind up being frustrated. Finally the Mac is getting a built-in way to create a SSB in Sonoma.
- mthoms 3y ago
  Orion Browser works pretty well for SSBs. But I can’t wait for native support.
  - kbd 3y ago
    > Orion Browser works pretty well for SSBs. 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!

71 points by herbertl 3y ago

This seems like a quick and easy way for me to have an interim version of my desktop app. I have a few questions: 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? The pricing feels a bit off to me. Its just below the "ill just wrap it in electron" cost for a one-off, but I am not sure if i would be happy to pay it as an ongoing fee given the lack of apparent value-add at the basic tier.

davej 3y ago
> 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. 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.
- devmor 3y ago
  >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.
  - davej 3y ago
    To clarify: we host the initial download of the app on our CDN so we would most likely block the initial download of the app. It seems pretty reasonable to me that if a customer doesn't pay for a sub then they can no longer offer it as a download to their customers.
    - devmor 3y ago
      That is much less horrible than your wording made it sound - so if a customer is hosting the download on their own website, you are not trying to stop that in any way, correct?

mulhoon 3y ago

This has been on my radar for a while. It's so impressive. Bundling electron for all platforms can be a real headache. 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)

davej 3y ago
Feel free to drop me an email dave[at]todesktop or dm @davej on Twitter. I started ToDesktop as an indie hacker, so I understand where you're coming from. Hopefully can figure out something that works for you. :)
mike_hearn 3y ago
What do you think is a fair price for a solo dev trialling a small app? 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. [1] https://hydraulic.dev/ https://hydraulic.dev/
- devmor 3y ago
  Sounds to me like "trial" apps skipping the signing process is a good option. A dev team can click the "Run Untrusted Program" button, and it serves as an incentive to upgrade before distributing.
  - mike_hearn 3y ago
    Well, Conveyor can already self sign and produce a download page with instructions telling the users what to do. It's fine for internal demos and dev teams indeed. But browsers/operating systems will generate security warnings, and so that might be offputting to end users. You'd be unsure if your app was struggling due to that, or due to some product flaw. 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.

TruthWillHurt 3y ago

Yo dawg I hear you like apps, so we put an app in the browser in your app...

resonious 3y ago

I gotta say, I'm not super convinced by a lot of the points on here. > 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?

NikolaNovak 3y ago
Strictly fwiw - There is a subset of people, myself included, who have old fashioned preference for native apps. In particular, a few likely obsolete perspectives : 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 :-)
- philote 3y ago
  I'm curious, what native apps that are also available a web app do you store an offline copy of on your NAS? And which do you deny access to in your firewall?
- resonious 3y ago
  This is totally good. But I do wonder how much these points apply to a native app generated from a website using the tool in the link. I get the feeling it will still be very SaaSy (a la Slack's "native app").

dusted 3y ago

Stop trying to make desktop software with web technologies, they are all slower and suckier than their counterparts. 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.

ttyyzz 3y ago
I fully agree and very much like vs code at the same time.
franga2000 3y ago
I hate Electron apps as much as the next guy, but I'll take a cross-platform wrapped web app any day over a native app that is available only on Windows because the developers didn't have the time do make three separate apps.
stevepike 3y ago
So I'm sitting here on a linux (KDE) desktop machine with the following apps open: 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?
- peterkelly 3y ago
  All these apps could be written in Qt and would then work on all platforms.
  - lawgimenez 3y ago
    Like Telegram.
- voidpepe 3y ago
  You are correct, but I still feel like we need a better way of making cross-platform desktop applications than just wrapping a webapp into a bunch of bloat. Web technologies were never meant for this and it pains me to see a messaging desktop app clog up 100s of MB of memory

cloudengineer94 3y ago

I'd rather have a pure web app than a janky desktop app made with Electron or some other tech that eats my RAM.

ToucanLoucan 3y ago

I'll be honest: I make a concentrated effort to avoid these apps that are just a website stuffed into a (usually quite gigantic) executable for a number of reasons: - 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.

loremchecksum 3y ago
I sometimes wonder what the total emission cost of these non-native developments amounts to.
- mble 3y ago
  Huge most probably. The fact that we need to upgrade our hardware every three or so years, not because our workflow changed, but because every app is written as cheaply as possible shows how much of an impact it has.
JSavageOne 3y ago
Some benefits of websites as apps - 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

kevsim 3y ago

Unsolicited praise - we've been using ToDesktop at Kitemaker for a while now and we're super happy with it. The team is always super responsive to our requests and the product has been very stable. We were rolling our own Electron app before and it was an annoying headache. Just having a tool that takes care of all the updates, Apple signing and is consistently adding new/useful APIs for us to tap into is a big win. I get that some teams aren't interested in having an Electron app, and that's cool, but if you are, give this a shot because it'll for sure save you time.

egonschiele 3y ago

This looks interesting to me, but the cheapest tier is $99/month. Why is it so expensive? Isn't this just building an Electron app for you?

jillesvangurp 3y ago
This is aimed at people who lack the ability to do that. Lots of not so technical people that operate small websites that don't employ developers. 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.
- egonschiele 3y ago
  To that point, though, aren't those services $10 - $30 per month? If they're able to sell this for $99 - $240/month, surely they'll see competition, leading to a race to the bottom?

TimMeade 3y ago

This seems really expensive to just wrap in electron. I do not see anything about app store insertion either. Am i missing something?

davej 3y ago

Oh wow, It's exciting to see this pop up on HN. I'm Dave, founder of ToDesktop. Feel free to reply to this and I'm happy to answer any questions :).

Lightbody 3y ago
Nice work! Do you have plans to bring the same low friction deployment to mobile?
- davej 3y ago
  Not currently, there's still a lot to do with the desktop platform!
ChrisMarshallNY 3y ago
Good luck, Dave. 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.
- davej 3y ago
  Thanks for the kind words Chris! I completely agree.
gwbas1c 3y ago
> Is ToDesktop For Me? > 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/ https://fluidapp.com/ for years until I switched to the techniques built into Chrome / Edge / Brave.

AshleysBrain 3y ago

It looks like a well executed product, but I believe the future is to move towards running in the browser only, rather than browser wrappers for the desktop. For example, isn't just visiting a URL in your browser so much more easy and convenient than having to have an installer? Isn't it nice to use the already-installed browser rather than ship a full browser engine with the app? 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. [1] https://www.construct.net https://www.construct.net

phalangion 3y ago
Sometimes yes, sometimes no. A web app having its own icon and spot in the dock/task bar makes it easier to switch to.
- twism 3y ago
  Safari supports this if you install a web app as a standalone app. I'm I missing something here?
rmilejczz 3y ago
This is my thought as well, if you want your web app to function as a native app then make it progressive. Perhaps ToDesktop offers us something the PWA does not

philote 3y ago

For those more knowledgeable than me, why use something like this over making your web app into a PWA?

devmor 3y ago
Most people don't know PWAs exist due to poor platform support/advertisement.
- philote 3y ago
  What do you mean by poor platform support?
  - lefixx 3y ago
    Mozilla prism has been discontinued. Firefox first removed the feature by default and then removed it completely. IOS-add-to-home-screen always sucked. 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.
jillesvangurp 3y ago
The installation experience for PWAs is still pretty poor. I've seen very few good examples of PWAs (probably because of this). And I've even bothered implementing a few. My conclusion after doing that: waste of time, users mostly ignore PWAs.
- philote 3y ago
  I thought you could publish them on app stores. What makes the installation process poor?

devmor 3y ago

A monthly fee for a build tool that provides no ongoing benefit other than continuing to exist is a ridiculous pricing strategy. Especially $99 for solo. 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?

lawgimenez 3y ago

Creating a calendar app with web technologies is a mortal sin.

whelton 3y ago

I use ToDesktop for Conjure[0], and I love it. Given the nature of Conjure (Habit and Time Tracking), having a desktop app was important to many users, and many now use it instead of the web version (myself included). 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. [0] https://conjure.so https://conjure.so

lefixx 3y ago

What happened to SSBs :(

butz 3y ago

Funny, when Firefox still does not have "add to desktop" support, while all major (and some minor, like GNOME Web) browsers are shipping it for quite a while now. And there won't be a better solution to run web applications safely, other than browser that gets regular updates.

kbd 3y ago

It's been frustrating that for years Mac has had no native way to create a site-specific browser. Chrome can do it for you on Windows. On Mac there is stuff like Fluid, but for reasons I don't remember every time I try it I wind up being frustrated. Finally the Mac is getting a built-in way to create a SSB in Sonoma.

mthoms 3y ago
Orion Browser works pretty well for SSBs. But I can’t wait for native support.
- kbd 3y ago
  > Orion Browser works pretty well for SSBs. 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!