Discussion on:
View:
Show:
I think there is an equal justification between web and native applications. Where the web browser is a lightweight client application, it cannot support heavy data transactions dynamically with multiple UI present. To me, that's its Achilles heel. If you freeze one browser pane, the whole app is gone. Lose your network, your browser is toast if it requires connection to a server. Native applications shine in this ability to handle multiple UI. I also feel that while tablet and mobile applications are great, they do not have the ability to really do heavy efficient work without a full keyboard and mouse. Try creating your 40 slide dynamic presentation on a mobile phone. Can you really call that efficient? They will shine when you travel after the heavy lifting is done, but doubt they will replace the PC soon as a development and work tool.
"it cannot support heavy data transactions dynamically with multiple UI present"
With HTML5, that's possible.
"If you freeze one browser pane, the whole app is gone."
Not in modern browsers that use separate processes.
"Lose your network, your browser is toast if it requires connection to a server."
Not with HTML5, which has capabilities for syncing after the connection is re-established.
"I also feel that while tablet and mobile applications are great, they do not have the ability to really do heavy efficient work without a full keyboard and mouse."
I agree, but what we're seeing are docking stations that provide that functionality.
These are the changes that have made the difference. Browsers are better, HTML5 is better, and with the pending docking stations, there is no reason to use a PC except for extremely resource intense tasks (multimedia editing, development, number crunching, etc.) which are very niche tasks.
J.Ja
With HTML5, that's possible.
"If you freeze one browser pane, the whole app is gone."
Not in modern browsers that use separate processes.
"Lose your network, your browser is toast if it requires connection to a server."
Not with HTML5, which has capabilities for syncing after the connection is re-established.
"I also feel that while tablet and mobile applications are great, they do not have the ability to really do heavy efficient work without a full keyboard and mouse."
I agree, but what we're seeing are docking stations that provide that functionality.
These are the changes that have made the difference. Browsers are better, HTML5 is better, and with the pending docking stations, there is no reason to use a PC except for extremely resource intense tasks (multimedia editing, development, number crunching, etc.) which are very niche tasks.
J.Ja
I know that AIR 3 supports some at least some of the HTML5/CSS3 spec. How much I donno. It runs off of webkit
>>Not with HTML5, which has capabilities for syncing after the connection is re-established.
I have tried that with AIR's local database syncing with a DBMS back end and it is a LOT harder than it sounds. It was a total PITA.
>>Not with HTML5, which has capabilities for syncing after the connection is re-established.
I have tried that with AIR's local database syncing with a DBMS back end and it is a LOT harder than it sounds. It was a total PITA.
>> I have tried that with AIR's local database syncing with a DBMS back end and it is a LOT harder than it sounds. It was a total PITA.
As a life-long web guy, I would extend the PITA statement out to most of HTML5, unfortunately for the near future.
Examples:
- Graphical work in Canvas or SVG gets no hardware acceleration on mobile- which means it's horrible.
- Local storage and DB standards are an inconsistent mess.
- WebGL is nice but I had issues displaying basic text.
As someone developing a product, I unfortunately had to give up HTML5 for Flash. Now that the whole world is fleeing Flash (right or wrong), I'm baffled by my next steps. I'm thinking of developing a web version and desktop versions in an embedded Webkit- though I'm worried that may be a headache.
My app is presentation based which means:
- it should run locally *Flawlessly* without fear of internet loss killing a presentation,
- run on Mac, Windows, web, and mobile (in a stripped form)
- Is *highly* graphical- even using 3D
Flash/Flex/AIR can do all these. HTML5 sucks in actual execution here- despite the occasional neat looking demo. And many of the problems are due to browser inconsistencies that the main browser co's don't seem to be moving forward on (I'm looking at you Microsoft, Mozilla, *and* Google).
Frankly, I'm frustrated by a tech world that keeps proclaiming "HTML 5 rocks, Flash and native apps are dead" while not actually fixing HTML5 to build real apps on it.
Meanwhile, I'm the technical laggard for needing to build my platform on something that actually works.
I must go know, I actually have a company to build and users to satisfy...
Alex
p.s. So I go to click "Submit Reply" and, having expanded the size of the textbox, that button is now missing under the comment below. This quirk times 100 is what my personal experience building a real HTML5 app was like. And, yes, I'm angry...
As a life-long web guy, I would extend the PITA statement out to most of HTML5, unfortunately for the near future.
Examples:
- Graphical work in Canvas or SVG gets no hardware acceleration on mobile- which means it's horrible.
- Local storage and DB standards are an inconsistent mess.
- WebGL is nice but I had issues displaying basic text.
As someone developing a product, I unfortunately had to give up HTML5 for Flash. Now that the whole world is fleeing Flash (right or wrong), I'm baffled by my next steps. I'm thinking of developing a web version and desktop versions in an embedded Webkit- though I'm worried that may be a headache.
My app is presentation based which means:
- it should run locally *Flawlessly* without fear of internet loss killing a presentation,
- run on Mac, Windows, web, and mobile (in a stripped form)
- Is *highly* graphical- even using 3D
Flash/Flex/AIR can do all these. HTML5 sucks in actual execution here- despite the occasional neat looking demo. And many of the problems are due to browser inconsistencies that the main browser co's don't seem to be moving forward on (I'm looking at you Microsoft, Mozilla, *and* Google).
Frankly, I'm frustrated by a tech world that keeps proclaiming "HTML 5 rocks, Flash and native apps are dead" while not actually fixing HTML5 to build real apps on it.
Meanwhile, I'm the technical laggard for needing to build my platform on something that actually works.
I must go know, I actually have a company to build and users to satisfy...
Alex
p.s. So I go to click "Submit Reply" and, having expanded the size of the textbox, that button is now missing under the comment below. This quirk times 100 is what my personal experience building a real HTML5 app was like. And, yes, I'm angry...
"Not in modern browsers that use separate processes."
How many browsers do you think do that? Last I checked, Firefox and Safari (for instance) are still using a multithreaded model for tab management. Has that changed in the last few weeks?
How many browsers do you think do that? Last I checked, Firefox and Safari (for instance) are still using a multithreaded model for tab management. Has that changed in the last few weeks?
... since IE9 has managed to surpass it in a number of things, which is just embarrassing. Give the trends, it looks like Firefox won't be a big player much longer either.
J.Ja
J.Ja
It's difficult to argue with that. The power of the Firefox extension system is really what keeps it relevant, from a technical perspective, these days -- and it's why I still use it a lot (apart from testing purposes). I wish Chromium would get its extension system up to snuff so I could drop Firefox like the steaming turd it has become.
So many of the extensions for Firefox that people depend on seem to make up for its shortcomings, based on what others tell me (I don't use it enough to mess with extensions). Neither Chrome nor IE I have ever felt were lacking in a way that an extension could make up for. Chrome's significant issues have to do with UI (particularly the title bar/tabs) and IE's are all at a level that no extension will touch because they are internal. I just look at the stuff that others say they "need" extensions for, and most of it strikes me as the kind of twiddling/tweaking that "power users" enjoy, not because it delivers meaningful/measurable productivity gains, but because they are convinced that a system should work "just so".
By the by, those are the same users that I think the desktop model caters to quite well, but is hurting the other 95%+ of users out there who could not care less about tweaks, and when they do tweak, they also break. I may note, the same seems to happen with browser extensions...
J.Ja
By the by, those are the same users that I think the desktop model caters to quite well, but is hurting the other 95%+ of users out there who could not care less about tweaks, and when they do tweak, they also break. I may note, the same seems to happen with browser extensions...
J.Ja
"So many of the extensions for Firefox that people depend on seem to make up for its shortcomings, based on what others tell me (I don't use it enough to mess with extensions)."
Yes, they do -- but they are (for the most part) shortcomings in all the "modern" browsers. Even in cases where they're shortcomings particular to Firefox, the other big-name browsers have their own particular shortcomings and don't have an extension system up to the task of making up for them.
"Chrome's significant issues have to do with UI (particularly the title bar/tabs)"
Strange. I have not noticed such significant issues. What's wrong with the title bar and tabs?
Problems I've seen with Chromium (and Chrome) have to do with things like lack of granular control over various configuration options, where Firefox absolutely kills Chromium by default and, on top of that, the Firefox extension system is capable of providing far more room to add to that granularity and flexibility of configuration options than the Chromium extension system ever could.
The worst thing about the Chromium extensions system, of course, is the fact that its shortcomings are largely intentional design misfeatures -- like a "security" limitation on the ability of an extension to redirect an outgoing HTTP request to HTTPS, so that a security extension like HTTPS Everywhere cannot work properly on that browser. That's an example of a shortcoming in all browsers that is made up for on Firefox with a security extension that cannot be implemented without a fatal security flaw on Chromium.
"I just look at the stuff that others say they 'need' extensions for, and most of it strikes me as the kind of twiddling/tweaking that 'power users' enjoy"
My choices of extensions are pretty much limited to things that provide redundancy, security, or actual direct productivity enhancement. You're probably reading the wrong lists of important extensions. Actually, I don't think I've ever seen any list of important extensions on the Web that wasn't complete crap.
Yes, they do -- but they are (for the most part) shortcomings in all the "modern" browsers. Even in cases where they're shortcomings particular to Firefox, the other big-name browsers have their own particular shortcomings and don't have an extension system up to the task of making up for them.
"Chrome's significant issues have to do with UI (particularly the title bar/tabs)"
Strange. I have not noticed such significant issues. What's wrong with the title bar and tabs?
Problems I've seen with Chromium (and Chrome) have to do with things like lack of granular control over various configuration options, where Firefox absolutely kills Chromium by default and, on top of that, the Firefox extension system is capable of providing far more room to add to that granularity and flexibility of configuration options than the Chromium extension system ever could.
The worst thing about the Chromium extensions system, of course, is the fact that its shortcomings are largely intentional design misfeatures -- like a "security" limitation on the ability of an extension to redirect an outgoing HTTP request to HTTPS, so that a security extension like HTTPS Everywhere cannot work properly on that browser. That's an example of a shortcoming in all browsers that is made up for on Firefox with a security extension that cannot be implemented without a fatal security flaw on Chromium.
"I just look at the stuff that others say they 'need' extensions for, and most of it strikes me as the kind of twiddling/tweaking that 'power users' enjoy"
My choices of extensions are pretty much limited to things that provide redundancy, security, or actual direct productivity enhancement. You're probably reading the wrong lists of important extensions. Actually, I don't think I've ever seen any list of important extensions on the Web that wasn't complete crap.
Just two extensions off the top of my head. These are hardly geek tweak toys, yet they certainly are not browser shortcomings. As a standard part of a browser install, they would be bloat for most people.
Just tossing an example on the pile.
Just tossing an example on the pile.
Ultimately, what it comes down to is that -- even though a bunch of ignoramuses install bloatware as browser extensions that nobody really needs -- there are very useful extensions that can have a real impact on one's livelihood, a browser's usability, and so on.
* When spawning one tab from another, IE gives the tabs an identical color so you know they are related; with Chrome, they are all the same color.
* In Chrome, the tabs take over the title bar, so on a multi-monitor setup, trying to click the title bar to return focus to the browser is likely to switch tabs or worse, close one. In IE, there's still a full sized title bar. My preferences would be for the tabs to leave about 10 - 15 px. at the to provide some "meat" to select the window.
* In Chrome, no matter how small the tab, the "X" to close the tab is aways available. In IE, once tabs get below a certain size, only the "X" on the active tab is active, so you can't accidentally close a tab while trying to select it.
* In IE, closing a tab activates the previous tab in the "group" (letting you basically work backwards up the tab tree structure), in Chrome, it activates the next tab, which will take you out of the "group" (which Chrome doesn't recognize anyways) if you were on the last tab of the "group".
As you can see, these are all really minor gripes, but for someone like my who typically runs 20 - 50 tabs, because I'm got 5+ research projects occurring at once, it's a big deal overall.
J.Ja
* In Chrome, the tabs take over the title bar, so on a multi-monitor setup, trying to click the title bar to return focus to the browser is likely to switch tabs or worse, close one. In IE, there's still a full sized title bar. My preferences would be for the tabs to leave about 10 - 15 px. at the to provide some "meat" to select the window.
* In Chrome, no matter how small the tab, the "X" to close the tab is aways available. In IE, once tabs get below a certain size, only the "X" on the active tab is active, so you can't accidentally close a tab while trying to select it.
* In IE, closing a tab activates the previous tab in the "group" (letting you basically work backwards up the tab tree structure), in Chrome, it activates the next tab, which will take you out of the "group" (which Chrome doesn't recognize anyways) if you were on the last tab of the "group".
As you can see, these are all really minor gripes, but for someone like my who typically runs 20 - 50 tabs, because I'm got 5+ research projects occurring at once, it's a big deal overall.
J.Ja
* "When spawning one tab from another, IE gives the tabs an identical color so you know they are related; with Chrome, they are all the same color."
I do not think I would have much use for that, but I can see how a very different workflow from mine might make that important. I wonder if there's a way to use the Chromium extension system to add that functionality. If so, I think an extension to do that would be superior to build-in functionality, because those who dislike it don't have to have it that way.
* "In Chrome, the tabs take over the title bar, so on a multi-monitor setup, trying to click the title bar to return focus to the browser is likely to switch tabs or worse, close one. In IE, there's still a full sized title bar. My preferences would be for the tabs to leave about 10 - 15 px. at the to provide some 'meat' to select the window."
I think there are Chromium themes that will fix that problem. Of course, there are other options for where to click than the title bar, such as the address bar, scroll bar, et cetera, so it seems like kind of a non-issue to me -- especially because I tend to consider a big titlebar something of a waste of valuable screen area.
* "In Chrome, no matter how small the tab, the 'X' to close the tab is aways available. In IE, once tabs get below a certain size, only the 'X' on the active tab is active, so you can't accidentally close a tab while trying to select it."
Weird. This is not the case on my install of Chromium. Maybe it's something added by Google to the Chrome-branded variant, or maybe it's a configuration setting, or maybe something something something. I can only speculate, I guess.
* "In IE, closing a tab activates the previous tab in the 'group' (letting you basically work backwards up the tab tree structure), in Chrome, it activates the next tab, which will take you out of the 'group' (which Chrome doesn't recognize anyways) if you were on the last tab of the 'group'."
This is another strange one. With my Chromium install, it works exactly as you describe IE working, except when you do something to break context (such as by visiting a tab unconnected with the group before coming back to the tab in question, which suggests a desire to deal with things separately from the group at least sometimes).
* "As you can see, these are all really minor gripes, but for someone like my who typically runs 20 - 50 tabs, because I'm got 5+ research projects occurring at once, it's a big deal overall."
I really need to cut my number of Chromium tabs to 50 at most today.
I do not think I would have much use for that, but I can see how a very different workflow from mine might make that important. I wonder if there's a way to use the Chromium extension system to add that functionality. If so, I think an extension to do that would be superior to build-in functionality, because those who dislike it don't have to have it that way.
* "In Chrome, the tabs take over the title bar, so on a multi-monitor setup, trying to click the title bar to return focus to the browser is likely to switch tabs or worse, close one. In IE, there's still a full sized title bar. My preferences would be for the tabs to leave about 10 - 15 px. at the to provide some 'meat' to select the window."
I think there are Chromium themes that will fix that problem. Of course, there are other options for where to click than the title bar, such as the address bar, scroll bar, et cetera, so it seems like kind of a non-issue to me -- especially because I tend to consider a big titlebar something of a waste of valuable screen area.
* "In Chrome, no matter how small the tab, the 'X' to close the tab is aways available. In IE, once tabs get below a certain size, only the 'X' on the active tab is active, so you can't accidentally close a tab while trying to select it."
Weird. This is not the case on my install of Chromium. Maybe it's something added by Google to the Chrome-branded variant, or maybe it's a configuration setting, or maybe something something something. I can only speculate, I guess.
* "In IE, closing a tab activates the previous tab in the 'group' (letting you basically work backwards up the tab tree structure), in Chrome, it activates the next tab, which will take you out of the 'group' (which Chrome doesn't recognize anyways) if you were on the last tab of the 'group'."
This is another strange one. With my Chromium install, it works exactly as you describe IE working, except when you do something to break context (such as by visiting a tab unconnected with the group before coming back to the tab in question, which suggests a desire to deal with things separately from the group at least sometimes).
* "As you can see, these are all really minor gripes, but for someone like my who typically runs 20 - 50 tabs, because I'm got 5+ research projects occurring at once, it's a big deal overall."
I really need to cut my number of Chromium tabs to 50 at most today.
I've seen the cloud and also seen what hackers do when they breach it. I do not doubt that this will all be a moot point in a few years. My reasoning may be outdated, but we are coming full circle to the old mainframe and terminal scenario. It's just comes in a different flavor.
Also, you can telegraph your answer to me when your cloud disappears.
Also, you can telegraph your answer to me when your cloud disappears.
Cloud, Web, or Wireless - the fact is that more and more business applications are "cutting the wire." If we don't stay with it, we will be left behind in the dust.
I disagree with the heavy data applications argument: in fact, a good cloud/web server will have higher data rate capability and throughput than most desktop stations. House it in the server farm with direct connection to the backbone for the data access, and only the web/cloud/intranet interface looking out. Data throughput should not be the bottleneck.
"Native applications shine in this ability to handle multiple UI's"? Nonsense! I have created and run major data systems that handle multiple UI's for years, including conveyor and fixed scanners, fixed desktop workstations, handheld batch scanners, wireless scanners - all different UI's, connecting in various ways to a single database, each supplying their own piece of relevant information. Only at a couple of low levels were native code applications necessary, and those were device drivers. Yes, native device drivers are a necessary evil. But they are more single-point, single-purpose, not suited to a generic installation on many platforms.
"Lose your network"? EVERY desktop is just about toast when the company intranet goes down. It doesn't matter whether it's native if it can't access the data.
"Try creating your 40 slide dynamic presentation on a mobile phone." Well how about "Take your desktop workstation with its native app to a customer site." Both examples are ridiculous, obviously using the wrong platform for the job.
"tablet and mobile ... do not have the ability to really do heavy efficient work without a full keyboard and mouse." I agree, but what does that have to do with the native/cloud/web decision? You're arguing for native apps based on hardware capabilities. Again, you do need the right platform for the job, but that has nothing to do with the software development decision in question.
"Native applications shine in this ability to handle multiple UI." Nothing could be more bogus! Native applications are almost always tied to a particular hardware and OS configuration. Web applications are about as universal as it gets. One well-designed web app on the server runs clients on PC/Windows, Mac/OSX, Android, iPad/iOS, Linux and more! Show me any native app that installs on all of those platforms - the few that exist are BROWSERS!
In development applications, native applications are practical and necessary. But for most business production applications, client/server applications for cloud, web, and wireless are easier to interface with the wide variety of platforms in today's business environment.
I disagree with the heavy data applications argument: in fact, a good cloud/web server will have higher data rate capability and throughput than most desktop stations. House it in the server farm with direct connection to the backbone for the data access, and only the web/cloud/intranet interface looking out. Data throughput should not be the bottleneck.
"Native applications shine in this ability to handle multiple UI's"? Nonsense! I have created and run major data systems that handle multiple UI's for years, including conveyor and fixed scanners, fixed desktop workstations, handheld batch scanners, wireless scanners - all different UI's, connecting in various ways to a single database, each supplying their own piece of relevant information. Only at a couple of low levels were native code applications necessary, and those were device drivers. Yes, native device drivers are a necessary evil. But they are more single-point, single-purpose, not suited to a generic installation on many platforms.
"Lose your network"? EVERY desktop is just about toast when the company intranet goes down. It doesn't matter whether it's native if it can't access the data.
"Try creating your 40 slide dynamic presentation on a mobile phone." Well how about "Take your desktop workstation with its native app to a customer site." Both examples are ridiculous, obviously using the wrong platform for the job.
"tablet and mobile ... do not have the ability to really do heavy efficient work without a full keyboard and mouse." I agree, but what does that have to do with the native/cloud/web decision? You're arguing for native apps based on hardware capabilities. Again, you do need the right platform for the job, but that has nothing to do with the software development decision in question.
"Native applications shine in this ability to handle multiple UI." Nothing could be more bogus! Native applications are almost always tied to a particular hardware and OS configuration. Web applications are about as universal as it gets. One well-designed web app on the server runs clients on PC/Windows, Mac/OSX, Android, iPad/iOS, Linux and more! Show me any native app that installs on all of those platforms - the few that exist are BROWSERS!
In development applications, native applications are practical and necessary. But for most business production applications, client/server applications for cloud, web, and wireless are easier to interface with the wide variety of platforms in today's business environment.
I'm curious about the developers experience. Is it now as simple to build a web-app with a rich desktop-style UI as it is to do so for the Windows platform? And is the separation of code and interface now as mature?
There are a lot of good javascript libraries that enable you to create nice looking UI's. There are even libraries that supply touch-friendly widgets. And many are pretty easy in use. (E.g. jQuery UI, jQuery Mobile)
Concerning seperation of code: I believe it requires a little effort from the developer because it's too easy to overlook but it's possible to do it right (more or less). But I do look forward for new languages like Google Dart which enables you to write your code on a higher level.
Concerning seperation of code: I believe it requires a little effort from the developer because it's too easy to overlook but it's possible to do it right (more or less). But I do look forward for new languages like Google Dart which enables you to write your code on a higher level.
I've been doing hybrid programming for the last few years. C# on the server side and jquery on the client UI. My users absolutely love how much the web apps behave like desktop apps. It has a long way to being the same but practically speaking its a non issue. Development wise I didn't even need to take classes. Lots of googling to figure syntax out but its so simple any programmer with a few years of experience should be able to become an expert. This is just with limited html 5 integration. When its more mature I think the advantage will be undeniable. Already to me, native apps seem ridiculous and in the long term that is just not a maintenance friendly scenario.
It's easier to create slick-and-usable interfaces using Web development frameworks than it is to create slick-and-usable traditional GUI interfaces using desktop GUI toolkits. There are just a very few things the Web frameworks typically don't do quite as well, just because they lack the decades of design and development that inform the current form of desktop GUI toolkits, but they're catching up rapidly.
That's not to say they look the same -- but in many cases that's a good thing. In fact, there are desktop GUI toolkits appearing now that use Web technologies directly, without requiring a browser.
That's not to say they look the same -- but in many cases that's a good thing. In fact, there are desktop GUI toolkits appearing now that use Web technologies directly, without requiring a browser.
When you say it's as easy or easier to create a slick interface in a Web environment than a Windows native, are we talking the same sorts of interface?
Personally, I hate the interface of a lot of web-apps and web interfaces that already exist because they are so limiting. Or, perhaps it's the apps that are limiting? I'm talking about things like MDI, customizable toolbars, clipboard integration, all the good stuff we've used for years. I'm happy to see a new interface as long as it doesn't require more clicks/keystrokes to do things and I see at least as much information on the screen at the same time. My experience is that this just isn't the case.
Personally, I hate the interface of a lot of web-apps and web interfaces that already exist because they are so limiting. Or, perhaps it's the apps that are limiting? I'm talking about things like MDI, customizable toolbars, clipboard integration, all the good stuff we've used for years. I'm happy to see a new interface as long as it doesn't require more clicks/keystrokes to do things and I see at least as much information on the screen at the same time. My experience is that this just isn't the case.
"Or, perhaps it's the apps that are limiting?"
Yes -- that's it exactly, in most cases. There's little point in giving us things like customizable toolbars when the end result will be a logarithmic hit to performance for each customization due to the need to communicate stuff across the Internet via AJAX. There's also the problem that you don't want clipboard integration for an app whose security model is based on the modern web browser.
Then, of course . . . there's the fact that a slick-and-usable interface is not always what we need. Sometimes, it's a minimalistic, highly efficient interface designed to reward expertise in the use of the tool.
Yes -- that's it exactly, in most cases. There's little point in giving us things like customizable toolbars when the end result will be a logarithmic hit to performance for each customization due to the need to communicate stuff across the Internet via AJAX. There's also the problem that you don't want clipboard integration for an app whose security model is based on the modern web browser.
Then, of course . . . there's the fact that a slick-and-usable interface is not always what we need. Sometimes, it's a minimalistic, highly efficient interface designed to reward expertise in the use of the tool.
Kind of goes back to what I was getting at. If we are talking what I call Applications, things like Word, Photoshop, 3D Max and Autocad, Live, ..., it seems that web based development still has a long way to go to be able to compete with native interfaces. That's why when we get someone saying ALL apps will be moving online, or ALL apps will be moving to mobile devices, or ALL interfaces will be touch based,... I react! I've spent almost 30 years in the IT industry and expect each new generation to be an improvement on the previous. By improvement I mean everything is at least as good and some things are better. So, you can't take functions away, make them harder or slower to access, give me less options,.... and still call it an improvement.
The reason I'm so focused on "applications" is that I have little or no use at all for the myriad of apps available for portable devices or online use. I'm just not into the "always on" life that many lead of late. I don't book trips and restaurants on a regular basis and I'm not interested in social networking. In my job, I am the only one in my team, so there is no collaboration.
What I like is creating things, enjoying the view when I do travel, spending time actually doing things with friends and family. I don't even like talking to people on the phone. Face to face is the only way to really know who you're talking to.
The reason I'm so focused on "applications" is that I have little or no use at all for the myriad of apps available for portable devices or online use. I'm just not into the "always on" life that many lead of late. I don't book trips and restaurants on a regular basis and I'm not interested in social networking. In my job, I am the only one in my team, so there is no collaboration.
What I like is creating things, enjoying the view when I do travel, spending time actually doing things with friends and family. I don't even like talking to people on the phone. Face to face is the only way to really know who you're talking to.
Web interfaces (that is, interfaces built using web technologies) can be quite useful -- even for local applications, with no network connectivity necessary. I have seen quite a few native GUI applications whose interfaces could be greatly improved by turning them into web interfaces.
There are, as you point out, a great many cases where connectivity should never be a requirement for the application, though. Thus, my differentiation between web interfaces and web applications, where the core application itself depends on a webserver -- in part because building an application on top of a webserver is an exercise in stupidity when you do not have a network-connected intent for the application itself. Using HTTP to connect the interface to the rest of the application is a terrible idea if you are not dealing with situations where the application and its interface are not on the same machine.
Of course, web interfaces are not always appropriate regardless of what's behind the interface. Local native GUI applications can serve as clients for remote network applications as well as self-contained local applications, and sometimes that sort of interface is better than the web interface. There are cases where a console-based interface is by far the best option, and web technologies do not yet offer the kind of capabilities of user shells and other terminal console technologies that make them such a great place to use some applications and utilities. For instance, I wouldn't want to try to do all my software development inside a vi-like editor interface that is, in turn, embedded in Firefox.
I loathe telephones, in general, by the way. I do, however, conduct a lot of business online, and find IMs, email, and IRC (in no particular order) quite useful for such purposes, to say nothing of some of the discussions here at TR and on reddit.
There are, as you point out, a great many cases where connectivity should never be a requirement for the application, though. Thus, my differentiation between web interfaces and web applications, where the core application itself depends on a webserver -- in part because building an application on top of a webserver is an exercise in stupidity when you do not have a network-connected intent for the application itself. Using HTTP to connect the interface to the rest of the application is a terrible idea if you are not dealing with situations where the application and its interface are not on the same machine.
Of course, web interfaces are not always appropriate regardless of what's behind the interface. Local native GUI applications can serve as clients for remote network applications as well as self-contained local applications, and sometimes that sort of interface is better than the web interface. There are cases where a console-based interface is by far the best option, and web technologies do not yet offer the kind of capabilities of user shells and other terminal console technologies that make them such a great place to use some applications and utilities. For instance, I wouldn't want to try to do all my software development inside a vi-like editor interface that is, in turn, embedded in Firefox.
I loathe telephones, in general, by the way. I do, however, conduct a lot of business online, and find IMs, email, and IRC (in no particular order) quite useful for such purposes, to say nothing of some of the discussions here at TR and on reddit.
Since the reasons to write a desktop app were negated in the article, I'm curious as to what sorts of applications some of the developers here write.
What about disk defragmenters, anti-virus/anti-malware, junk cleaners, file recovery, repair utilities, browsers, file managers, download managers, virtualization, image mounting, partition management, good text/hex editors, DEs & compilers, network tools, &c.
Or is no one supposed to have a desktop and some semblance of control over their OS in the near future? Just boot a rendering engine from ROM and go? What about the distant back ends for all those web apps?
Maybe all this is obvious, or someone will make a case for doing these things in HTML5 or that these things are unnecessary and will become unavailable. But I don't see any qualifier to the word "application" as used here.
What about disk defragmenters, anti-virus/anti-malware, junk cleaners, file recovery, repair utilities, browsers, file managers, download managers, virtualization, image mounting, partition management, good text/hex editors, DEs & compilers, network tools, &c.
Or is no one supposed to have a desktop and some semblance of control over their OS in the near future? Just boot a rendering engine from ROM and go? What about the distant back ends for all those web apps?
Maybe all this is obvious, or someone will make a case for doing these things in HTML5 or that these things are unnecessary and will become unavailable. But I don't see any qualifier to the word "application" as used here.
... in the desktop model of computing, for the most part.
A/V doesn't matter when the apps can't touch the system or data outside of themselves. Disk defragging is less of an issue when there is little data store locally, and most items are streamed from the cloud, and tasks are much less I/O dependent. File managers, download managers, etc. are all irrelevant to a filer structure that the user never sees (use an iPad, iPhone, or WP7 device for an example, no need to EVER even think about the file structure!). Ditto for the other tools you mention... in the computing environment of the future, "power users" are an endangered species, and thankfully so. Think about most of those tasks. Do you REALLY want to be doing them? More importantly, do the majority of typical users want to be doing them? Do help desks and desktop support techs want to be doing them? NO! They want and need "it just works" and having to deal with that is the enemy as far as they are concerned.
"Or is no one supposed to have a desktop and some semblance of control over their OS in the near future? Just boot a rendering engine from ROM and go? What about the distant back ends for all those web apps?"
Like I said, other than a few niche applications (multimedia editing, number crunching, software development, etc.), no, no one really needs the desktop environment, and in fact it's been badly holding us back! Few users multitask like you and I do or use stuff like OLE, ODBC, Secure ID, and all of the other super froody techs that come with Windows. The desktop model has worked well for power users, but for everyone else it's a mess and a waste of time and does nothing but cause problems. I welcome the day in which "support" is sending a device back to the maker and giving the user a replacement off the stack, and once they login all of their settings and apps and data sync out of the cloud.
J.Ja
A/V doesn't matter when the apps can't touch the system or data outside of themselves. Disk defragging is less of an issue when there is little data store locally, and most items are streamed from the cloud, and tasks are much less I/O dependent. File managers, download managers, etc. are all irrelevant to a filer structure that the user never sees (use an iPad, iPhone, or WP7 device for an example, no need to EVER even think about the file structure!). Ditto for the other tools you mention... in the computing environment of the future, "power users" are an endangered species, and thankfully so. Think about most of those tasks. Do you REALLY want to be doing them? More importantly, do the majority of typical users want to be doing them? Do help desks and desktop support techs want to be doing them? NO! They want and need "it just works" and having to deal with that is the enemy as far as they are concerned.
"Or is no one supposed to have a desktop and some semblance of control over their OS in the near future? Just boot a rendering engine from ROM and go? What about the distant back ends for all those web apps?"
Like I said, other than a few niche applications (multimedia editing, number crunching, software development, etc.), no, no one really needs the desktop environment, and in fact it's been badly holding us back! Few users multitask like you and I do or use stuff like OLE, ODBC, Secure ID, and all of the other super froody techs that come with Windows. The desktop model has worked well for power users, but for everyone else it's a mess and a waste of time and does nothing but cause problems. I welcome the day in which "support" is sending a device back to the maker and giving the user a replacement off the stack, and once they login all of their settings and apps and data sync out of the cloud.
J.Ja
That was exactly my argument (but mine would be a bit less elaborate :-)). So you're completely right, that is what we are heading towards. But as you also state: where will it leave us, the power users? Will we be required to use a separate OS? In the end, somebody has to develop all these online apps (and stuff like browsers)...
I think power users will always use an OS of some kind. Either directly on the server itself, or in a local (albeit limited) device. As you say, the browsers themselves will need developers, as will the HTML5 apps. Some things do not change...
with the superuser stuff being added on.
...sort of like a microkernel OS, although, arguably it'll be more a smallish-kernel OS.
...sort of like a microkernel OS, although, arguably it'll be more a smallish-kernel OS.
The kernel's likely to be monolithic and huge. All that's likely to be separated from it is userland (including UI).
I think a distributed OS would be more interesting.
I think a distributed OS would be more interesting.
I think, strictly speaking, there will always be an OS. It's pretty hard to build a computer system that doesn't. It might be a tiny OS kernel but it's still an OS. It seems as though people want to change the definition of OS so they can claim their system doesn't have one.
We wouldn't have what we do today without the accidental open architecture of the PC, and once that goes away the ecosystem is going to lose a whacking great chunk of its diversity, which never bodes well for future generations.
From what, exactly?
While I'll certainly agree that a lot of people don't need much more than a browser, what do desktop environments hold u back from, and how?
Sure, everything will "just work" and there will be no support issues with cloud services or connectivity.
no one really needs the desktop environment, and in fact it's been badly holding us back!
From what, exactly?
While I'll certainly agree that a lot of people don't need much more than a browser, what do desktop environments hold u back from, and how?
Sure, everything will "just work" and there will be no support issues with cloud services or connectivity.
Well, it's become very clear that native apps are a nightmare for sys admins. Things break, badly and irreproducably. Each app has its own architecture that must be understood to get anything really done. Each app has its own UI paradigms. Etc. The usability is awful. Writing connected applications is a wreck. People say, "oh, but what about offline?" Guess what? Any client/server app is just as broken offline as a Web app, and you have to jump through just as many hoops for syncing, the only benefit is that you have local storage to save changes if the app closes before a sync occurs.
So while Web apps don't unleash this huge wave of new possibilities, they DO make life so much easier in other ways, ways that *have* been roadblocks to getting things done.
J.Ja
So while Web apps don't unleash this huge wave of new possibilities, they DO make life so much easier in other ways, ways that *have* been roadblocks to getting things done.
J.Ja
I just find the headline and article to be a rather sweeping generalization that doesn't apply to everyone. Even the blog departments doesn't narrow it down at all. My objection is only that this sort of thinking supports the removal of freedom to run any sort of platform we like. I'm already concerned about losing the ability to have hardware platforms which allow us to run whatever OS or applications we like. I rue the day where all data is in the cloud and we are at the mercy of service providers and governments who can cut you off and rifle through your stuff. It's too easy when you can't physically control your hardware, including storage.
The other issue I have with cloud services is this: People love to whine about P2P users using bandwidth. The same complaint should apply to all the commercial offerings which gratuitously ship bits back and forth across the net, whether it is entertainment (e.g., Netflix) or other cloud services. Further, ISPs raising their rates, also always gratuitously, could bring computing to a screeching halt for anyone not in what passes for the middle class these days or above.
I'm not saying that your one opinion is going to change the entire model, or that you are personally responsible for any unintended (by you) consequences. I am saying that this general attitude spread across the industry is a potential threat to a lot of people and their computing freedom. All it takes is hardware manufacturers to find no further profit in building x86/x64 architecture components because they are unneeded to support a bootable HTML5 rendering engine. And if there is no longer any freedom, I could care less about convenience for businesses, mobile users, and providers.
The other issue I have with cloud services is this: People love to whine about P2P users using bandwidth. The same complaint should apply to all the commercial offerings which gratuitously ship bits back and forth across the net, whether it is entertainment (e.g., Netflix) or other cloud services. Further, ISPs raising their rates, also always gratuitously, could bring computing to a screeching halt for anyone not in what passes for the middle class these days or above.
I'm not saying that your one opinion is going to change the entire model, or that you are personally responsible for any unintended (by you) consequences. I am saying that this general attitude spread across the industry is a potential threat to a lot of people and their computing freedom. All it takes is hardware manufacturers to find no further profit in building x86/x64 architecture components because they are unneeded to support a bootable HTML5 rendering engine. And if there is no longer any freedom, I could care less about convenience for businesses, mobile users, and providers.
"And if there is no longer any freedom, I could care less about convenience for businesses, mobile users, and providers."
That line is pretty much the money shot for this entire discussion. You and AnsuGisalas must be sharing a broadcast wavelength.
That line is pretty much the money shot for this entire discussion. You and AnsuGisalas must be sharing a broadcast wavelength.
The thing of it is: This model adopted wholesale to the exclusion of local computing is will be the industry shooting itself in the foot (or both feet, one hand and an eye) as well.
The industry and its fans just pooh-pooh any critics as being lazy and afraid of "progress". The model certainly has valid uses, but the idea that personal computing is not justified puts us all on a very bad track.
Ansu also mentioned that a dearth of computers running or able to run native apps basically removes an educational element from potential programmers who would rather work on a backend. Maybe we'll get lucky and it will be possible to emulate a cloud server network with virtualization, operating systems, and applications in HTML 5 (or 7 - whatever). I was thinking that building HTML 5 apps might be brought to a place where you could build them in a Dreamweaver-variety "IDE" application, but that would have to be able to be written in HTML 5 as well. Just the user UI though, I guess - the rest would be hosted, wouldn't it? Until the providers yet again decide to push the processing client-side. I call shenanigans on web/cloud apps/services that do nothing more than temporarily drop javascript on you to run while providing a handful of bytes of data here and there while they clog the tubes with their traffic. It's all very... disingenuous.
The industry and its fans just pooh-pooh any critics as being lazy and afraid of "progress". The model certainly has valid uses, but the idea that personal computing is not justified puts us all on a very bad track.
Ansu also mentioned that a dearth of computers running or able to run native apps basically removes an educational element from potential programmers who would rather work on a backend. Maybe we'll get lucky and it will be possible to emulate a cloud server network with virtualization, operating systems, and applications in HTML 5 (or 7 - whatever). I was thinking that building HTML 5 apps might be brought to a place where you could build them in a Dreamweaver-variety "IDE" application, but that would have to be able to be written in HTML 5 as well. Just the user UI though, I guess - the rest would be hosted, wouldn't it? Until the providers yet again decide to push the processing client-side. I call shenanigans on web/cloud apps/services that do nothing more than temporarily drop javascript on you to run while providing a handful of bytes of data here and there while they clog the tubes with their traffic. It's all very... disingenuous.
from the point of view of using an application?
I have applications on my PC that I use. They need no connection to a server or the internet to work. Ultimately, I could even set up so I don't need an electrical connection either.
This is the problem. You expect people to go from something they can use without reliance on any connectivity, to a system that requires a connection to work. And, in the process, loose the ability to do the things they could on the old system.
This is also not just about business. These changes affect all computer users, whether at work or home. I and many others use more complex software at home than we do at work.
I have applications on my PC that I use. They need no connection to a server or the internet to work. Ultimately, I could even set up so I don't need an electrical connection either.
This is the problem. You expect people to go from something they can use without reliance on any connectivity, to a system that requires a connection to work. And, in the process, loose the ability to do the things they could on the old system.
This is also not just about business. These changes affect all computer users, whether at work or home. I and many others use more complex software at home than we do at work.
... then a Web-delivered application doesn't either, if the work is done in JavaScript. Just because it uses HTML + HTTP doesn't mean that all of the logic needs to be server side, or any of it at all, for that matter. If the local app doesn't need to work with a remote system, then you could just use the server to dish up the initial resources to bootstrap the application, then run it all client side.
J.Ja
J.Ja
Maybe, but apps aren't there for the benefit of sys admins. They are there for the benefit of users (and consequently the business). Show me a single web app of reasonable complexity whose UI is anywhere close to the smooth and easy user experience offered by a decent 'desktop' app, and I'll eat my hat and reconsider. But until then.....
Has been as good as the desktop version since 2003.
J.Ja
J.Ja
Can you drag an attachment from your file system and into a message in Outlook Web Access (I have not tried). Can you do that in with FireFox and Chrome?
Last time I used OWA, a long time ago, it was IE only for any kind of usable experience. That meant that it used a bunch of non-standard MS only extensions to support that functionality. In such a case, your example is meaningless. If this has improved since I used it, then you are right.
For a good web mail app I'd point to Yahoo mail which works with all browsers I have tried.
Last time I used OWA, a long time ago, it was IE only for any kind of usable experience. That meant that it used a bunch of non-standard MS only extensions to support that functionality. In such a case, your example is meaningless. If this has improved since I used it, then you are right.
For a good web mail app I'd point to Yahoo mail which works with all browsers I have tried.
I might consider using it if it supports Dungeons and Dragons!
More seriously, though . . . I think portability is underrated. Does OWA work with browsers other than IE, on other OSes? If not, we're still stuck with stuff like Evolution -- native desktop applications. One of the benefits of web development is portability, and yet many desktop-replacement web apps fail utterly in the portability realm.
More seriously, though . . . I think portability is underrated. Does OWA work with browsers other than IE, on other OSes? If not, we're still stuck with stuff like Evolution -- native desktop applications. One of the benefits of web development is portability, and yet many desktop-replacement web apps fail utterly in the portability realm.
1) Yes, I just tested it with Drag/Drop from the local file system, worked 100% like Outlook in IE9.
2) Works fine in Firefox and Chrome overall (as in, looks right, doesn't complain like Exchange 2003 used to, etc.). Drag/Drop did NOT work in Firefox or Chrome, neither seem to support that functionality at all.
This is on Exchange 2007, so the Exchange 2010 version may be even further improved.
J.Ja
2) Works fine in Firefox and Chrome overall (as in, looks right, doesn't complain like Exchange 2003 used to, etc.). Drag/Drop did NOT work in Firefox or Chrome, neither seem to support that functionality at all.
This is on Exchange 2007, so the Exchange 2010 version may be even further improved.
J.Ja
Businesses -- or especially government agencies -- that have to limit (or completely cut off) the exposure of sensitive data to external sources can???t ???go to the cloud???. For those businesses, desktop apps & their environment will be around for many years, if not decades, to come, & HTML5 won???t really help with that.
1. The cloud is secure enough, especially if you choose the right SLA.
2. No one cares about privacy anymore, the coming generations of consumers will care even less, the corporations never did (unless it involves their trade secrets, then look out), and government will relax or revoke it's sham regulations to follow suit, eventually.
I didn't say they were good answers. But we are on course for them to be valid answers.
2. No one cares about privacy anymore, the coming generations of consumers will care even less, the corporations never did (unless it involves their trade secrets, then look out), and government will relax or revoke it's sham regulations to follow suit, eventually.
I didn't say they were good answers. But we are on course for them to be valid answers.
I plussed you up, but the knee-jerkers outnumber me with a delta of 2. Could be three to one. I hope it's more of a 102 to 100... but that's not very likely though. 
Of course, maybe all the '-' votes are for the apostrophe
Of course, maybe all the '-' votes are for the apostrophe
"1. The cloud is secure enough, especially if you choose the right SLA.
"
There's one huge assumption there - that the SLA will be honestly honoured. Once it hasn't been, there goes your privacy, too late to do anyting about it too. You can rant about SLA as much as you like, but once your stuff is out there, it's out.
"
There's one huge assumption there - that the SLA will be honestly honoured. Once it hasn't been, there goes your privacy, too late to do anyting about it too. You can rant about SLA as much as you like, but once your stuff is out there, it's out.
Thats not true. I have worked for agencies with classified data. There are secured clouds and private clouds that will satisfy the requirements.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
