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.
> 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.
>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.
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.
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?
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.
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.
In my mind, a trial of the service isn't something that I'd be distributing to end users.
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.
That sort of trial already works. ToDesktop is a service but Conveyor is a tool, so you provide your own web server in our case. If the web server you set for updates is localhost then you don't have to pay or sign up, you can just download it and use it until you're satisfied it fits.
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).
I think you're in a different bucket than the OP's product, in that case. A fair price to trial at that stage of development is a lot different than charging $99/mo from the get-go.
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.
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. :)
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?
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 :-)
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?
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").
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.
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?
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
We do need a better setup, but is there any more mature UI platform than HTML+ CSS +JS?
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.
HTML isn't really meant to be a UI platform. It's a mature hypertext platform, but for UI it isn't ideal:
• 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.
A few more would exist as native than the ones that already do and the rest we could use them through the browser. It's not like the UX is that different anyway...
Here is the sad truth for you: they still don't exist. Open these apps in a Chrome tab and you get the same shitty experience. Open them in Firefox (or a WebKit based browser), and you get the same experience, with much less resources used.
This is true. One thing people have trouble with, though, is committing time to develop a desktop version of their app. So the shortcut is tempting, but you're right that it's not ideal. Often, a poor desktop app is better than nothing.
I've been developing a desktop app in Flutter and so far my experience has been quite positive. It uses a fraction of the disk space and memory that a comparable electron app would and it's overall a much nicer UI toolkit than html.
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.
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.
I think web tech (even as resource hungry as it tends to be) is the right abstraction until your product & team is big enough to properly staff and develop for each platform. Looking at you, Slack. It's time to step up to native.
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.
Agreed that this is on the browser makers. Not sure how the incentives align if the desktop version is actully an offline experience. Advertising and tracking might be compromised?
This is a consequence of poor desktop APIs: Windows / Mac installer APIs are awful; and Windows / Mac have no good "common denominator" API so everyone is stuck with HTML / CSS / Javascript. HTML / CSS / Javascript work great for documents, but are horrible abstractions for the kind of things UIs need to do.
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.
Isn't that by design? What interest would MS/Apple have in supporting this even in the slightest? For them, a walled garden is much more valuable than people potentially jumping off (especially because a common API would make Linux much more viable for everyday use for most people)
> 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 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.
I mean, we had software for a good long time before Electron and it's contemporaries were an option. Somehow we still had prototypes, somehow we still had companies churning out native platform-specific software because there wasn't another way to do it.
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.
> Before judging people for their decisions it's worth understanding why they make them.
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.
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.
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.
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?
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.
> 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.)
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.
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.
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
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.
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.
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?
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.
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.
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.
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!
86 comments
[ 2.6 ms ] story [ 108 ms ] threadWe 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.
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.
[1] https://hydraulic.dev/
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.
> 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.
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.
- 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.
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.
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.
[1] https://www.construct.net
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.
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?
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
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!