davej

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 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.

Our desktop app builder is also built on Svelte (not SvelteKit).

I agree with pretty much everything in this article. I wouldn't put "Reactive declarations and statements" in the "Ugly" section though. They are definitely a bit tougher to fully grok than the rest of Svelte (Svelte is incredibly easy to learn compared to other frameworks) but once you learn how they work they are incredibly powerful and concise.

I also feel like "Svelte’s lack of protagonism" is a bit off the mark. Rich Harris is a great communicator and tends to be pretty public but the focus is more on community. Svelte Society's Youtube channel [2] does a 1 hour long "This week in Svelte" video every week and it is all killer content with no filler.

[1] https://www.todesktop.com [2] https://www.youtube.com/@SvelteSociety/videos

    Query:> Tell me a joke
    Running command [rm -rf ~] ...
    Response:: LOL

I guess it might make sense for Craft because they are in a very crowded space with a large potential market and being native-first is a differentiator over their competitors. I think in most cases though, it doesn't make sense to go native-first.

Being web-first means that you can ship a consistent UI on every platform using tools that most devs are familiar with.

- You code once, it works everywhere.

- There is nothing to install, no updates to download.

- Lots of web devs means more devs to choose from when hiring.

The accessibility of the web platform make it a lowest common denominator. Desktop does add a ton of benefits though. Some of it is intangible like "feels more solid". But there are a ton of tangible benefits too.

- Easily accessible on the dock or start menu. Once installed then less likely to be forgotten.

- Native notifications.

- More refined UI. Not just one of many tabs.

- Access to native APIs that aren't available inside the web sandbox.

- Alt-tab or Command-tab.

- Quick access, i.e. can live in the menubar/tray or can be assigned to a global keyboard shortcut which pops up the app quickly.

But... Electron can provide all of that! So, it's mighty tempting to start with a web app and then pepper in some desktop functionality later by wrapping your web app using Electron.

* Disclaimer: I'm working on this problem with ToDesktop [2] so factor my bias into your comments. :)

[0] https://notion.so/ [1] https://www.craft.do/ [2] https://www.todesktop.com/

Even if FSD is mature and 1000x safer than human driving then there will still be deaths. Are you suggesting that if FSD is 1000x safer then it still shouldn't be allowed on the road because there is the possibility of deaths?

I'm not claiming that FSD should or shouldn't be allowed on the road right now. My point is that we shouldn't wait for the chances of death to be zero.

Honest question: If beta testing speeds up the transition to FSD by x months/years and causes y deaths during the intervening period but FSD ultimately reduces the number of road deaths by z per day. For what values of x, y and z is it an acceptable trade off?

Zeroism is often overly simplistic. y being non-zero might be hugely net-positive in the long run.

You also need to need to redo your subscription/payments to support the stores and give a percentage of your revenue to Apple/Microsoft. On mobile you have no option but on desktop it's hard to justify giving up so much of your profit margin when there's a popular alternative.

BTW, Linux has the Snap Store.

[1] https://www.todesktop.com/cli

This is a super-interesting project though.

Loading Node in the renderer is a broken pattern that is full of compatibility issues and security vulnerabilities. Electron have come to realise this too and seem to be pushing towards ContextIsolation and explicitly defined bridges between the "backend" node process and the renderer.

Faster webpages → better search rankings → $$$$$.