4 ms·

yes. There can be a lot of boilerplate code present, however in terms of speed, using Qt for instance, can be much faster still than a web application that acco

yes. There can be a lot of boilerplate code present, however in terms of speed, using Qt for instance, can be much faster still than a web application that accomplishes the same task even if you get a huge binary after compilation. Oh and as Nadya said, sometimes this generalization causes issues. Engineering is a game of trade-offs I think :P.

kaoD 10y ago
> in terms of speed That's the point. Most applications don't need speed, and most that need it can offload speed-critical code with no significant drawbacks. The web is fast enough for 99% of use cases.
- CorvusCrypto 10y ago
  I agree. Was there any thought I didn't ;)?
Klathmon 10y ago
What's the speed of the install process for those apps? How's the update system work? How quickly can you release them to all platforms? Can they be easily customized and modified by the user? Can they be easily shared? What's the permissions model like? How much can that application access?
- izacus 10y ago
  Same way as that worked since 1980ties for all millions of home PC users.
  - Klathmon 10y ago
    But compared to the web, native applications are significantly worse in these areas. Especially on that first point. I can go to the vast majority of web apps on just about anything with a browser and get it up and running in less than a second knowing nothing more than a domain name. And there's "cross platform" then there's "cross platform". Something like QT is amazing, but you are still looking at the big-3 desktop OS's, and maybe the big mobile guys if you work for it. A web app includes all of that, plus my TV, my car headunit, and even my damn watch! (I often use a web home-automation app from a browser on my watch, the UI adapts pretty damn well for quick light-flips) Nothing is perfect for everyone, but just because it's been done since the 80's doesn't mean it can't be improved on. And as always it depends on your actual needs. There aren't any "better" and "worse" architectures.
- Nadya 10y ago
  Can it interop with other applications? eg. can output be piped from another program? Will it still be around to use if the company goes bankrupt? Can settings be backed up at all? Can I even restore settings from a backup? Can I easily share these settings? Is there a way to carry it on a thumb drive so that in the event I find myself without internet for a first install/use - I can still use it? How much control do I have over any data used/stored by the application?
  - Klathmon 10y ago
    Well to the settings stuff yes, see something like "cookie clicker" for a (IMO bad UX) example. And you can more easily control how much data it stores over a certain point, as all major browsers make you confirm via a dialog that you are giving permission to use the requested amount. But to keep this from turning ugly, my point was more that you need to take into consideration what you'll need for your app. If it's an application that basically only exists as an interface for data stored in a backend server, then giving them the ability to exist after bankruptcy is pointless. However if it's something that needs root access and will frequently be used and installed on a system without internet access, native is better. And saying things like a native app is "less bloated" when it takes literally multiple magnitudes more time to install and run with significantly more permissions to your whole system is silly.
- CorvusCrypto 10y ago
  One thing I have noticed in this thread in general is that the web devs are extremely defensive. No, a web app is not inherently bad. No one is saying this. But cherry picking questions to prove a point is silly. However, to show it's not a gangup on web apps here we go: Speed of the install process? Probably slower than loading a web page for serious applications How does the update system work? Depends if you're releasing as a single statically compiled program or using shared libs that can be updated. Also if you have a db to sync this will affect things. How quickly can you release them to all platforms? As long as it takes to compile to all compatible targets. Can they be easily customized and modified by the user? in what regard? if you mean configuration then yes. If you mean being able to manually tweak the style of the application like when fiddling around in the element inspector, then no unless you are using a theme parser that lets them adjust the themes. Can they be easily shared? yes What's the permission model like? Depends what granularity you want to have. Permissions can be restricted to the action level, user level, group level, machine level, global level, etc. Whatever logic you want to implement really. How much can that application access? access in terms of what?
  - Klathmon 10y ago
    And one thing i've noticed is that "native devs" are extremely condescending. I hear a LOT about how writing an application for the web is wrong (especially on HN), but not much about why it's a good idea. I see comments about how native is faster, "less bloated", portable, "better designed", offline, and more secure. But never any comments on how long they take to install, how difficult it is to use them across multiple devices, how you need to either use an app-store, bundle your own updater (which follows all the best security practices), or rely on a distro to get around to including it for you. I never read discussions on how they tend to be larger, they have more access to the underlying system by default, how they are more difficult to secure, or how if you use the one application across multiple platforms you need to learn multiple UIs. And while none of that is true across the board, it's stuff you need to spend more time on to get right, whereas you tend to get it "for free" when targeting the web. Obviously things go the other way for some features. Getting high performance out of a web app takes more work, getting "high security" to work in a browser is much more difficult, getting offline takes some consideration (IMO it's not that difficult today, but it does still take work). It might come across as defensive, but I can't bring up anything web-related on this site without being asked why I didn't make it native, or why I'm using javascript at all, or why I decided to use the web when there are "perfectly good UI toolkits for native app development" while hand waving away all the benefits and reasoning behind my decisions as either pointless or just by saying "you can do that with native too" without going into the mountain of work necessary to get it right. And in that comment I indulged that anger which I don't normally do on this site.

kaoD 10y ago

> in terms of speed That's the point. Most applications don't need speed, and most that need it can offload speed-critical code with no significant drawbacks. The web is fast enough for 99% of use cases.

CorvusCrypto 10y ago
I agree. Was there any thought I didn't ;)?

Klathmon 10y ago

What's the speed of the install process for those apps? How's the update system work? How quickly can you release them to all platforms? Can they be easily customized and modified by the user? Can they be easily shared? What's the permissions model like? How much can that application access?

izacus 10y ago
Same way as that worked since 1980ties for all millions of home PC users.
- Klathmon 10y ago
  But compared to the web, native applications are significantly worse in these areas. Especially on that first point. I can go to the vast majority of web apps on just about anything with a browser and get it up and running in less than a second knowing nothing more than a domain name. And there's "cross platform" then there's "cross platform". Something like QT is amazing, but you are still looking at the big-3 desktop OS's, and maybe the big mobile guys if you work for it. A web app includes all of that, plus my TV, my car headunit, and even my damn watch! (I often use a web home-automation app from a browser on my watch, the UI adapts pretty damn well for quick light-flips) Nothing is perfect for everyone, but just because it's been done since the 80's doesn't mean it can't be improved on. And as always it depends on your actual needs. There aren't any "better" and "worse" architectures.
Nadya 10y ago
Can it interop with other applications? eg. can output be piped from another program? Will it still be around to use if the company goes bankrupt? Can settings be backed up at all? Can I even restore settings from a backup? Can I easily share these settings? Is there a way to carry it on a thumb drive so that in the event I find myself without internet for a first install/use - I can still use it? How much control do I have over any data used/stored by the application?
- Klathmon 10y ago
  Well to the settings stuff yes, see something like "cookie clicker" for a (IMO bad UX) example. And you can more easily control how much data it stores over a certain point, as all major browsers make you confirm via a dialog that you are giving permission to use the requested amount. But to keep this from turning ugly, my point was more that you need to take into consideration what you'll need for your app. If it's an application that basically only exists as an interface for data stored in a backend server, then giving them the ability to exist after bankruptcy is pointless. However if it's something that needs root access and will frequently be used and installed on a system without internet access, native is better. And saying things like a native app is "less bloated" when it takes literally multiple magnitudes more time to install and run with significantly more permissions to your whole system is silly.
CorvusCrypto 10y ago
One thing I have noticed in this thread in general is that the web devs are extremely defensive. No, a web app is not inherently bad. No one is saying this. But cherry picking questions to prove a point is silly. However, to show it's not a gangup on web apps here we go: Speed of the install process? Probably slower than loading a web page for serious applications How does the update system work? Depends if you're releasing as a single statically compiled program or using shared libs that can be updated. Also if you have a db to sync this will affect things. How quickly can you release them to all platforms? As long as it takes to compile to all compatible targets. Can they be easily customized and modified by the user? in what regard? if you mean configuration then yes. If you mean being able to manually tweak the style of the application like when fiddling around in the element inspector, then no unless you are using a theme parser that lets them adjust the themes. Can they be easily shared? yes What's the permission model like? Depends what granularity you want to have. Permissions can be restricted to the action level, user level, group level, machine level, global level, etc. Whatever logic you want to implement really. How much can that application access? access in terms of what?
- Klathmon 10y ago
  And one thing i've noticed is that "native devs" are extremely condescending. I hear a LOT about how writing an application for the web is wrong (especially on HN), but not much about why it's a good idea. I see comments about how native is faster, "less bloated", portable, "better designed", offline, and more secure. But never any comments on how long they take to install, how difficult it is to use them across multiple devices, how you need to either use an app-store, bundle your own updater (which follows all the best security practices), or rely on a distro to get around to including it for you. I never read discussions on how they tend to be larger, they have more access to the underlying system by default, how they are more difficult to secure, or how if you use the one application across multiple platforms you need to learn multiple UIs. And while none of that is true across the board, it's stuff you need to spend more time on to get right, whereas you tend to get it "for free" when targeting the web. Obviously things go the other way for some features. Getting high performance out of a web app takes more work, getting "high security" to work in a browser is much more difficult, getting offline takes some consideration (IMO it's not that difficult today, but it does still take work). It might come across as defensive, but I can't bring up anything web-related on this site without being asked why I didn't make it native, or why I'm using javascript at all, or why I decided to use the web when there are "perfectly good UI toolkits for native app development" while hand waving away all the benefits and reasoning behind my decisions as either pointless or just by saying "you can do that with native too" without going into the mountain of work necessary to get it right. And in that comment I indulged that anger which I don't normally do on this site.