Web Application VS Windows Application
-
@guyinpv said in Web Application VS Windows Application:
They are not as easy to control via OS security policies.
I'd argue that that is almost always a good thing. OS policies are the wrong place for the majority of app management. It's similar to relying on the LAN for security, it was necessary long ago but mostly crufty today. You can move security into the central app for better control.
-
@guyinpv said in Web Application VS Windows Application:
I rarely touch Office online because it's just slow, herky jerky, buggy, crashy. I absolutely hate interfaces that aren't very responsive.
I actually have the opposite experience, even with MS Office. Neither experience is great, but it's often better online. But a lot of that is because it's a web app even when running locally. Like many modern apps are. It's become common to make things that look like native apps but are actually web apps.
-
@guyinpv said in Web Application VS Windows Application:
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.
-
@guyinpv said in Web Application VS Windows Application:
If you want native OS features or require to greatest efficiency, security, or OS-level features, then obviously native.
Partially this is true. But web apps have nearly unlimited access to native features today, including OS level features, are often super efficient (often better than native because of better coding) and I'd argue that security is backwards, native apps have the biggest security challenges.
-
@guyinpv said in Web Application VS Windows Application:
If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.
Just web apps running locally
It's not really a crossover. You can do all of the same stuff without those frameworks using web apps. The web server can be local. -
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.
sure, this is an issue of the central component fails, but that seems to be a less likely place for things to break. if you compare how often Outlook breaks compared to Exchange, Outlook breaks significantly more often. Also, when Outlook breaks, it generally only takes down one user, not the entire office.
-
@Dashrender said in Web Application VS Windows Application:
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.
sure, this is an issue of the central component fails, but that seems to be a less likely place for things to break. if you compare how often Outlook breaks compared to Exchange, Outlook breaks significantly more often. Also, when Outlook breaks, it generally only takes down one user, not the entire office.
Right, but it is still extra risk. The choices are, in that example, require only Exchange or both Exchange and Outlook. Outlook doesn't reduce the risk, it increases it.
-
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.
Just web apps running locally
It's not really a crossover. You can do all of the same stuff without those frameworks using web apps. The web server can be local.What do you mean by "web apps" then? Cause I'm just referring to websites, essentially.
And I've never seen a web page able to put itself into system startup, maintain account auth auto-login, have a system tray icon and use native notifications and access deeply into the file system. I don't think Greenshot can work as a web app. I don't know how well web apps can create system-wide keyboard shortcuts as well.
One thing I hate is how bloated these "websites in a frame" apps are. Programs that should normal take 30 or 40MB have to take 180MB just for all the fluff.
I don't really buy it that you have the opposite experience with web interfaces, that they are MORE solid than native desktop. How can that be? It's dependent not only on the speed of the app server, but also the browser, and your ISP bandwidth, etc, things a native app may not have to deal with.
Heck just using my online Outlook mail (actually Hotmail) is buggy. Often it won't delete as fast as I can go through messages. The interface dies and says I should reload the page. I run Sweep and it takes 15 seconds to find and delete 8 messages, etc.
My Yahoo mail is even worse, often parts of the entire UI just go blank. Or something refreshes the page and I'm in a different part of the screen or another folder, etc.
Even though the web app has certain control over the keyboard, there have been times when I'm typing and hit <backspace> only to have the entire page go back in browser history!But again, I'm not saying websites or web apps or whatever you want to call them, are wrong or bad or insecure or any of that. It's just that native code has many advantages. Look at Steve Gibson, the dude still programs in freaking assembly. Creates Windows apps that are single EXEs less than a megabyte that take almost no RAM at all. Removing all that fluff can have its advantages. Especially for little utility apps with simple purposes.
-
LOL I love the Steve Gibson example. The size of his apps has as much to do with no fluff assembly as they do to the lack of complex functionality. Don't get me wrong, I like much of what he says, but definitely not all - I don't worship at the alter of Steve Gibson like Leo seems to at times.
I agree that web apps never seem as fast as native apps. But Outlook is now a Web app, it just happens to be running on a web server inside your computer, not on the other side of your internet connection. It can have as much local control as you want to allow it to have. I'm willing to bet that someone could get a version of Greenshot to work in that type of environment, but it still would be tied to Windows machines, so probably isn't worth the effort.
-
Well I use Thunderbird
-
@guyinpv said in Web Application VS Windows Application:
Well I use Thunderbird
I really don't like POP3 or IMAP - I use activesync where ever possible.
-
@Dashrender said in Web Application VS Windows Application:
I agree that web apps never seem as fast as native apps. But Outlook is now a Web app, it just happens to be running on a web server inside your computer, not on the other side of your internet connection. It can have as much local control as you want to allow it to have. I'm willing to bet that someone could get a version of Greenshot to work in that type of environment, but it still would be tied to Windows machines, so probably isn't worth the effort.
I've seen tons of software move to this model. Why put in the effort making and maintaining two apps when you get do it all with one?
-
@guyinpv said in Web Application VS Windows Application:
What do you mean by "web apps" then? Cause I'm just referring to websites, essentially.
Well, even so. Things written in Electron or that use a local web server are still websites, just ones that run on your own desktop.
-
@guyinpv said in Web Application VS Windows Application:
I don't really buy it that you have the opposite experience with web interfaces, that they are MORE solid than native desktop. How can that be?
Easy, code quality. Most people writing native, non-cross platform apps are not the top programmers, it's normally the cheapest people that can be found. Code qualities tends to suffer.
This same conversation was had years ago with C++ and Java. How can Java be faster, people asked, because it has so many layers. Yet normally it was (is). Why? Because tons and tons of research has gone into optimization and it makes it easier for normal people to write better software. Just because native "can" do well, doesn't mean that people are going to use it that way.
-
@guyinpv said in Web Application VS Windows Application:
Look at Steve Gibson, the dude still programs in freaking assembly.
Um... yeah.
-
@guyinpv said in Web Application VS Windows Application:
Removing all that fluff can have its advantages. Especially for little utility apps with simple purposes.
Outside of specifically maintaining an OS, which is a unique thing as it's neither business software (it's IT) nor does it have the possibility of being cross platform, what kind of apps do you see taking advantage of this?
-
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
Removing all that fluff can have its advantages. Especially for little utility apps with simple purposes.
Outside of specifically maintaining an OS, which is a unique thing as it's neither business software (it's IT) nor does it have the possibility of being cross platform, what kind of apps do you see taking advantage of this?
I think it's just the principle of the thing.
Less fluff means smaller, faster, easier to distribute, fewer dependencies to test/update or that can potentially introduce security leaks or be hacked or become outdated.
To me this is one of those questions like, why not just get the vehicle with the big frame and all the horsepower and lights and hydrolics? If gas is cheap and they can afford it, why not?
On the other hand, if all you need is to get from A to Z, the expensive gas gets annoying, possibly a liability.I'm old school. I still have "768 megs of RAM yeah!" mindset, where everything should be highly optimized and using as few resources as possible.
People nowadays don't care for that, it's just "I got lotsa RAM, bring on the fluff! Who cares!"To each his own. There always seems to be sacrifice between convenience and optimization.
-
@guyinpv said in Web Application VS Windows Application:
I think it's just the principle of the thing.
Less fluff means smaller, faster, easier to distribute, fewer dependencies to test/update or that can potentially introduce security leaks or be hacked or become outdated.
I'm thinking that it is more like virtualization.... standard abstraction layers add "more stuff" but in standard ways that make development, stability and security easier.
-
@guyinpv said in Web Application VS Windows Application:
I'm old school. I still have "768 megs of RAM yeah!" mindset, where everything should be highly optimized and using as few resources as possible.
People nowadays don't care for that, it's just "I got lotsa RAM, bring on the fluff! Who cares!"To each his own. There always seems to be sacrifice between convenience and optimization.
The thing is, for 99% of business apps, that stuff bring huge limitations and risk. Things that businesses "just expect" these days. Like being able to expose to the outside without needing to send company laptops home, not needing a VPN for app access, linking to common tools, not needing Windows in order to run a business tool, not needing CALs to something unrelated to run a business app, not needing to pay for Windows Server to deploy their own software, not needing to pay for desktop management, etc.
Desktop / native apps create a lot of cost and risk. They might seem small and tight, but that's not the factor that matters 99% of the time. It's just not important. The risks, the limitations that those apps bring can be crippling.
-
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
I think it's just the principle of the thing.
Less fluff means smaller, faster, easier to distribute, fewer dependencies to test/update or that can potentially introduce security leaks or be hacked or become outdated.
I'm thinking that it is more like virtualization.... standard abstraction layers add "more stuff" but in standard ways that make development, stability and security easier.
In theory.
I don't think tools like Electron are this "standard" yet. Could be wrong. I've had plenty of "websites in a box" apps crash on me and do stupid things, screwy UIs and other bugs.
I'm sure they will improve. I'm looking forward to trying Electron myself. I just don't have a project yet!
