[HN Gopher] ToDesktop - Web app to desktop app in minutes
___________________________________________________________________
ToDesktop - Web app to desktop app in minutes
Author : herbertl
Score : 55 points
Date : 2023-08-29 11:58 UTC (11 hours ago)
(HTM) web link (www.todesktop.com)
(TXT) w3m dump (www.todesktop.com)
| philote wrote:
| For those more knowledgeable than me, why use something like this
| over making your web app into a PWA?
| devmor wrote:
| Most people don't know PWAs exist due to poor platform
| support/advertisement.
| philote wrote:
| What do you mean by poor platform support?
| lefixx wrote:
| 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 wrote:
| 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 wrote:
| I thought you could publish them on app stores. What makes
| the installation process poor?
| TruthWillHurt wrote:
| Yo dawg I hear you like apps, so we put an app in the browser in
| your app...
| mulhoon wrote:
| 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 wrote:
| 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 wrote:
| 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/
| devmor wrote:
| 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 wrote:
| 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.
| devmor wrote:
| 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.
| mike_hearn wrote:
| 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).
| kevsim wrote:
| 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.
| resonious wrote:
| 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 wrote:
| 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 :-)
| resonious wrote:
| 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").
| philote wrote:
| 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?
| slara wrote:
| >> Native installers
|
| >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.
| lefixx wrote:
| What happened to SSBs :(
| egonschiele wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| This seems really expensive to just wrap in electron. I do not
| see anything about app store insertion either. Am i missing
| something?
| devmor wrote:
| 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?
| dusted wrote:
| 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.
| franga2000 wrote:
| 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 wrote:
| 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?
| xcdzvyn wrote:
| Zoom is CEF, like Spotify. It's Chromium embedded in a QT
| container.
| LeoNatan25 wrote:
| 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.
| cush wrote:
| > they still don't exist... same shitty experience
|
| There are many additional features a web app is capable of
| when installed, like native notifications, file system
| access, file associations, etc.
| sanitycheck wrote:
| I was going to say, most Electron apps (as opposed to say,
| VS Code) offer the user no benefits over just using the
| website they're wrapping.
|
| 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.
| charamis wrote:
| 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...
| peterkelly wrote:
| All these apps could be written in Qt and would then work on
| all platforms.
| lawgimenez wrote:
| Like Telegram.
| voidpepe wrote:
| 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
| sgc wrote:
| 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.
| mike_hearn wrote:
| 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.
| jcul wrote:
| Slightly off topic, bit is Signal a web app? I haven't
| realized.
| BaseballPhysics wrote:
| It's Electron-based, yes. Anyone using it on Wayland with
| fractional scaling will know that...
| etskinner wrote:
| 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.
| cageface wrote:
| 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.
| charamis wrote:
| I kinda miss the fact that native apps followed os' UI
| standards, now every app has a different UI with its own set of
| quirks.
| ttyyzz wrote:
| I fully agree and very much like vs code at the same time.
| lawgimenez wrote:
| Creating a calendar app with web technologies is a mortal sin.
| cloudengineer94 wrote:
| I'd rather have a pure web app than a janky desktop app made with
| Electron or some other tech that eats my RAM.
| whelton wrote:
| 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
| davej wrote:
| 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 wrote:
| Nice work!
|
| Do you have plans to bring the same low friction deployment to
| mobile?
| davej wrote:
| Not currently, there's still a lot to do with the desktop
| platform!
| ChrisMarshallNY wrote:
| 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 wrote:
| Thanks for the kind words Chris! I completely agree.
| gwbas1c wrote:
| > 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/ for years until I
| switched to the techniques built into Chrome / Edge / Brave.
| davej wrote:
| > 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.
| butz wrote:
| 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.
| supermatt wrote:
| 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 wrote:
| > 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 wrote:
| >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 wrote:
| 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 wrote:
| 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?
| AshleysBrain wrote:
| 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
| rmilejczz wrote:
| 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
| phalangion wrote:
| 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 wrote:
| Safari supports this if you install a web app as a standalone
| app. I'm I missing something here?
| kbd wrote:
| 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 wrote:
| Orion Browser works pretty well for SSBs. But I can't wait for
| native support.
| kbd wrote:
| > 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!
| ToucanLoucan wrote:
| 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.
| asoneth wrote:
| > 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.
| ToucanLoucan wrote:
| 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.
| asoneth wrote:
| > because there wasn't another way to do it
|
| 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.
| loremchecksum wrote:
| I sometimes wonder what the total emission cost of these non-
| native developments amounts to.
| mble wrote:
| 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 wrote:
| 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
| ehutch79 wrote:
| In order to use websites as a desktop app, i would think you
| need to download a binary and run it. Otherwise it's just a
| normal web app?
| JSavageOne wrote:
| With a Progressive Web App you can just download it as a
| desktop or mobile app by clicking on the download app icon
| in the URL bar
| jonny_eh wrote:
| But that isn't what was shared on HN. Why are we talking
| about PWAs?
| gwbas1c wrote:
| 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.
| leononame wrote:
| 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)
| gwbas1c wrote:
| Microsoft / Apple didn't design HTML / Javascript / CSS. It
| happened organically.
| toddmorey wrote:
| 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.
| bentt wrote:
| 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?
___________________________________________________________________
(page generated 2023-08-29 23:02 UTC)