Slashdot Mirror
The Case Against Web Apps
snydeq writes "Fatal Exception's Neil McAllister offers five reasons why companies should re-consider concentrating their development efforts on browser-based apps. As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter. And while UI and tool limitations are well known, the Web as 'hostile territory' for independent developers is a possibility not yet fully understood. Sure, Web development is fast, versatile, and relatively inexpensive, but long term, the browser's weaknesses might just outweigh its strengths as an app delivery platform."
The fact that the different browsers render basic sites differently should be warning enough. Add to that different versions etc; You will never have a standardised audience to utilise these. It will always be lowest common denominator.
Maybe I'll see the end of this 'webtwodotzero applications' crap.
I thought decentralization was supposed to be a good thing, the whole motivation behind having personal computers to begin with but, in the age of web apps everywhere, we seem to be returning to the days of the totalitarian, you'll-do-it-our-way-and-like-it data center (mainframe) model.
in this modern day-and-age, most stuff is just data anyways, and that is all database. Moving to a true client architecture, oh wait, all the data is still stored centrally, and most reports are all done via stored procedures.
Even with true clients, much data processing is still done in the datacenter. maybe some advanced analysis is done on other machines with a data dump, but still... it's all data
I will not give in to the terrorists. I will not become fearful.
Can we please, please go back to the Win32 API? It was such a joy to use, and I've got a Visual Studio 6 license laying around here somewhere.
I agree with this to no end, most people don't need it and people who have a minor need for a browser will screw around with it most of the time.
Well back to work.
FTA:
Browser technologies are too limiting.
I couldn't agree more.
The web used to be hyperlinked documents, but has since turned into a spaghetti of an application hell-bent on delivering ads, peeping into your web browsing habits, and trying to infect your computer with viruses.
Bring back the document-based web! Bring back content! Bring back control to your computer! Say no to webpages that insist on running code on your computer.
Qt took the step by allowing webkit and widgets to commingle... you can have local code running inside your browser, which can render local or remote content.
:P
I like C++ better than Javascript anyway
And won't make the leap to the obvious; the internet is the platform of choice now and is here to stay.
If the telecoms don't screw us enough, the internet will be as fast or faster than your local computer in 20 years. Eventually you will not be able to tell the difference, and where the data is stored won't make a difference; it will all be backed up somewhere.
Someone needs to write up "the case agains't desktop apps" because they are dieing a very quick death. It takes much longer to develop a desktop app and costs a shitload more money.
Sorry people, but eventually every app written will be on the internet.
Evole or die.
While I think the arguments against web-apps are valid, it is the newest trend and people will not listen. It will require a few very expensive catastrophies, before something happens. And then people will still not undterstand what the problem is, just that there were expensive catastrophies.
By now I believe most technological trends are not rational.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Operating systems get updated over time too... everything needs updating as time passes.
_Vishal www.squad9.com
And these issues shrink all the time. I agree with Joel regarding rich clients--I use Mail.app for e-mail, but virtually no one else I know does. Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term, but other apps will, and it's hard to see this guy's ideas mattering. Sure, they might be true, but the web is still more convenient. For me, it's become a central repository for book and other commentary in the form of The Story's Story and write about grant writing at Grant Writing Confidential. Yeah, I write my posts in Textmate, but most people don't--and most people aren't going to buy and install Textmate.
Fools! Use Adobe AIR. If you don't know that by now, you're very slow
To my mind the biggest weakness of web apps is that you have a hard time doing any sort of schedualed reporting/exports to use in another application. It can be done, but you really have to have the stars line up just right, or use some 3rd party scripting of some sort. Doable, but painful. God forbid you want to share data between two web apps, especially when company A and company B both have it in their heads that the other should pay them for development assistance.
But... but... we have to do it the high tech way! It has to be on the web! And use lots of XML for everything! And integrate with Microsoft Sharepoint and Project Server! And we'll have data dictionaries, and Java classes, and object-oriented OLAP cubes, and we will use some of that AJAX stuff too!
Hmph, next thing you know they will be saying we need to go back to stone-age paper and pencil!
Come on everybody: LET'S PUT IT ON THE WEB!!!! (drool, drool, drool)
My biggest complaint about browser/web apps is the inconsistent or non-existent ability to navigate the app with the keyboard.
While fat client apps can have messed up tab stops, they're generally better than their web-based counterparts. A CLI is even better allowing for things to be done in bulk/batch.
I've got over 100 buttons right at my finger tips. I shouldn't need 2 more that roll around (FPS mouselook not withstanding). Let me ALT+whatever and TAB my way around.
YMMV.
Right now web apps are king because they're always only the nearest computer away, and work on almost everything.
We're getting close to devices that provide the same functionality in a mobile form factor. Once everyone has an iphone like device that has a standard development environment we'll likely see a resurgence of local apps. But that's probably a years away at best.
Right now, you can either develop for the web, which will work everywhere, or write one app in Win32/.Net, one in Objective C for Mac, one in Java with Blackberry specific apis, one in Objective C for iPhone, one in [whatever palm is up to], one in .net for winmobile, etc, etc etc.
The only reason client side apps were ever written was because you could be fairly sure windows was your target, or it simply wasn't feasible to centralize and so you forced a standard environment.
There's no single platform anymore, and probably won't be for a while (and when it comes it'll look a lot like a web browser), so the only viable option is web based.
Does it suck? Yes and no. It's definitely better than debugging an app on 40 different platform/cpu/os version combinations.
This story was previously posted to the L4C list. Here's the response I sent there:
An interesting, albeit unoriginal, take on the problem of WebApps. Unfortunately, I do not find his arguments very compelling.
Quite a bit, actually. First and foremost is the convenience of application access. There is no software to install and you can use your applications anywhere you have access to a web browser. In addition, the rise of web applications has spurred the rise of web services. Web services share out tremendous amounts of public information allowing developers to "mashup" (I hate that term) data sources to produce superior applications. Compare that to the desktop where just getting the programs on your system to cooperate is a challenge! (To say nothing of networking.)
FWIW, the author is propagating a misconception about web applications. His belief appears to be that web apps MUST push computing power to the server. Nothing could be further from the truth. Web apps are "rich" clients rather than thin clients. Rich clients are more than capable of accepting a significant processing load. Whether that be Video Games, Image Editors, 3D Engines, Fractal Explorers, or other compute-intensive applications, the client is more than ready to pull its weight.
I personally have written an application for my current employer that requires the client to dynamically sort a 100,000 record data set in nothing but client-side Javascript. Significant computer science had to go into creating an optimized, multi-threaded algorithm that would perform well on the lowest common denominator. (IE6) The next generation of browsers that are appearing (Chrome, Firefox 3.1, Opera 10, Safari 4) will have so much compute power that a problem like my 100,000 row sorter will become easy and commonplace. Furthermore, the standards are even adding true background threads to support long-running compute operations. (The standard is based on the Google Gears implementation, which is already available.)
The communications protocol is stateless. The UI is not. AJAX UIs know their state as well as any desktop application.
Anyone who lived through the development of GUI systems know that this is not a new issue. In fact, it used to be quite common for apps to eschew Windows controls in favor of something custom. Borland, for example, LOVED their custom controls. The rise of GNOME, KDE, Java, and .NET/Avalon/WFC have created just as many problems for the desktop.
That being said, flexibility appears to occasionally improve applications. Using GMail as an example, the design would be gimped rather than helped by a "standard" Windows XP look. The clean lines of the GMail interface manage to communicate a great deal of information without creating the sort of 3D visual noise seen in applications like Outlook.
Javascript is only one component to a very lar
Javascript + Nintendo DSi = DSiCade
Enterprise applications should run on dedicated, fully optimized hardware that can be bolted to employees faces.
As far as a web browser for every employee, there are organizations that "value" productivity and organizations that actually understand how to maximize it.
AJAX is not the be-all of internet applications. There is also Adobe Flex and Microsoft Silverlight.
I find most sorts of apps work fine with standard AJAX controls, but Flex isn't hard to learn if you need more sophisticated UI in your internet app.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter.
For sure, there are some applications that make sense to run locally; or to use special local software in combination with a server, rather than a web-browser-based interface. 'World of Warcraft' won't be implemented in AJAX any time soon.
On the other hand if you want to sell 'software as a service' it's going to be easier if you're supplying ongoing services other than fixing bugs of your own creation. Furthermore, in stagnant markets (*cough*MSOffice*cough*) it could enable new features compelling enough for people to upgrade. What's more, a dependency on your data centre makes piracy practically impossible.
Not everything suits being on the web, or in the web browser. But the benefits to software companies are hard to ignore.
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
There is nothing like painting with a broad brush. In this case the premise of the article seems to be an ALL or NOTHING proposition. Web or Standalone application.
This is huge problem in understanding that there really is a need for BOTH. If you've ever tried to get a bunch of Term Servers running powerpoint presentations simultaneously, you'll quickly realize that some things are NOT suited for time sliced or otherwise processor sharing.
On the other hand, some things are suited for Web side (some database applications), which cut development and deployment costs.
Developers that understand this will be okay. Those that don't will continue to try to fit everything into one model or the other and eventually fail.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
But I thought the web was good?
WRONG! The web is bad! Well, sometimes, for some things... maybe.
There's a grab-bag of random thoughts there on some things that could be inherent problems in the web and some that are merely artifacts, and it seems neither here nor there.
The big guys always call the shots - who cares if it's browsers or operating systems, you're not going to tell MS (or Apple, just to be fair) what to do and there's no guarantee the next SP or random security patch won't bone all your effort with no notice or recourse, whether it's in-browser or on the desktop.
And the web UIs are a mess? That's nothing to do with the web - lots of people design lots of stuff, you get randomness. It's no different than on the desktop, except the long reign of some MS products and the fact that developing Windows apps you get to use some of those same form controls gets you the appearance of this magical consistency that's really just the consequence of monoculture. Open any full-screen app (read: game) and it's a brave new world, like on the web, because the pre-generated MS controls and constraints don't apply. But this is good, right, because you're not doing what the man tells you to do?
And the productivity argument... did he just need to reach 5? You can block the outside world coming in over the wire, it's not that big an effort, and then people will find other ways to screw around - hand-held devices are so powerful now the whole issue of limiting the desktop to work issues only is quickly becoming moot.
And so on and so forth... I guess it's redundant to say "you need to consider each usage case based on its specific merits," but then the decision-makers don't...
Even as you read this, your pants are strangling your loins! Aaa!
With caps on downloads, the future is pretty bleak for me working at home doing anything that requires large file sizes... granted now it is ok, but today's power user is tomorrows average user.
flinging poop since 1969
Cloud computing is irrelevant! My computer and my data will NOT be assimilated!!
Are we supposed to move toward virtualization/centalization in the datacenter to enable more thin-client apps, or just do fat-client apps? So this week thin-client sucks I guess. Fuck you, Neil. Who are you again?
SQL can't do everything. For example, graph the customer attendance at a restaurant. This needs a set S=(month, customers), e.g. (JAN-2009, 123) from SQL.
But the graph should be plotted on the client. Then, many questions can be asked.
* What is the change in customer populations?
dP/dt is the slope of the graph.
* What is the average attendance, people/month?
Do you want to go back to the SQL server every time to get the set S? The client's CPU is powerful enough to do this locally.
Also, the user can ask questions that the WEB application never considered.
Sure, Web development is fast, versatile, and relatively inexpensive, but long term, the browser's weaknesses might just outweigh its strengths as an app delivery platform
So we shouldn't develop web applications not because of the web application it self but because of the browsers people use to access the application?
So don't build a good, usable road because your not sure about the cars they are going to make in the future? Is this a valid reason not to?
The right answer might be Java (yes applets) (for web applications). Too many online apps suffer from GUI design flaws/look and feel etc, because it web site (touch feely girly developers & marketing driods) have far too input. Applets if done right with webservices for backend data comms would work well and be consistent (consistent as the code monkey wants to make it).
what, an open standards-based platform with an incredibly low cost of entry? What weaknesses are these?
I agree the browser shouldn't be the end all platform for business apps. There are many cases where you need better performance and/or more control which you can't get out of some web applications, but web applications can be rapidly developed, easily deployed, and maintained so why not use them when it makes sense. It's client-server all over again? How else do you anticipate we share data? We need centralized storage, table locking etc... Web UI's are a mess? Yes, they are but javascript frameworks, testing in multiple browsers, and good XHTML and CSS make this not so much of hassle. Plus companies can standardize on one browser to reduce QA and development time. Browser tech is too limiting? True, but it works fine in many cases. We'll I'm done debunking this joker who clearly was reaching for a topic to write. What a hack.
Note that many desktop apps hit web services or communicate via HTTP now, mostly because it's 1. easy and 2. SOA became the flavor of the month about a year or so ago.
Also, many enterprise web apps, at least that I've used, have some sort of plugin/JVM requirement. Are they a desktop app? Web app? Some awesomely funky in-between?
Personally, I think these "thick vs. thin" client discussions are a nice waste of time and excuse to get page impressions.
Let's deconstruct, shall we?
Running Outlook and Office will immediately slow that poor laptop to molasses. Add a nice shiny .NET app, or worse, Java, and you've got yourself a tarpit.
You, my friend, have never used internally developed VB6 apps. I say no more.
For some applications, I completely agree. But not everybody needs to see dynamic fluid modeling or stock quotes for 3000 securities in a real-time heatmap.
Good call, time to turn to Java and .NET, which aren't controlled by big vendors.
Because deploying and maintaining desktop apps across thousands of machines is wicked easy.
EOM.
It's all about balance between processing power availability of app and amount of data needed to get the job done. There is always security issue to be considered.
But lets talk about some of the advantages of web apps as well.
Over many years at a big company, the amount of installed applications has dropped, while web applications have proliferated. Sure, web applications are not the best idea for every application. But for most enterprise applications, I think they are the right choice.
The new hype is certainly Rich Internet Applications, but one thing not addressed in this article is whether or not the new non-AJAX technologies used in many RIA apps (Flex/Silverlight/JavaFX) could or should be used to develop a hybrid solution that leverages both the client machine's resources, as well as server resources, when necessary.
Perhaps RIA applications could first assess the capabilities of the host machine, as well as its current load and provide a distributed solution that leverages a reasonable amount of client CPU cycles. It seems to me that any of the above technologies could do this. Typically, this approach is used only for synchronizing, but I don't see why this couldn't occur in real-time.
The article does not even make sense. It is difficult to identify what he is arguing against. On one hand he is mentioning google apps, but he seems to be arguing against enterprise applications using web interfaces.
None of his arguments against deploying web based enterprise applications actually have anything to do with deploying applications in the enterprise. All enterprise organizations standardize on one or two supported browsers, surely this is not any worse than installing another application on every computer? The quote from SUN has nothing at all to do with the rest of the article and somehow makes it into the summary.
They key problem with the article is he does not offer a single alternative to deploying enterprise applications to users scattered across a high latency WAN, he just says "reconsider". Just because he is not aware of the existence of filtering firewalls and transparent proxies, we are supposed to go back to the world of thick client applications with the whole host of problems that brings to an organization?
Ajax does not simulate anything, it is just a new way of doing something that does not requiring installing and maintaining a thick client on the desktop. Surely keeping the business logic in the data center and sending your users only the data they desire is far superior to sending a massive pile of data across the WAN or VPN and then processing it on the desktop, just because it might have enough CPU power.
Crazy Talk from:
"Neil McAllister is a 10-year veteran technology writer and a regular contributor to InfoWorld. He has written extensively about Linux and open source, software development, and emerging technology for a variety of publications. He lives in San Francisco. "
He just doesn't know what he is talking about..
That type is what I argued again here yesterday:
http://slashdot.org/comments.pl?sid=1107509&cid=26650341
But I thought you were just complaining about running on the server, not a browser. You can still write your code in Fortran77 on the server if you want to; it doesn't have to be javascript. No you can't use f77 on the browser, but hey, at least you got immense distributed resources over there.
One of these two arguments doesn't belong.
"Believe me!" -- Donald Trump
screw all this browser nonsense. cobol cics for everybody!
"Fatal Exception's Neil McAllister offers five reasons why companies should re-consider concentrating their transportation efforts on gasoline powered vehicles. As McAllister sees it, automobiles encourage a reckless approach to transportation that leads to far too much dependence on pavement. And while low-fuel and flat-tire limitations are well known, the car as 'hostile territory' for independent travelers is a possibility not yet fully understood. Sure, automobiles are fast, versatile, and relatively efficient, but long term, the vehicle's weaknesses might just outweigh its strengths as a transportation platform."
Here are his bulletpoints with counter-arguments:
1. It's client-server all over again.
So? Most everything nowadays is going to be client-server. Sure, you can author a document completely locally, but much of your real work is going to involve sending data to someone or getting data from someone. The alternative is a client application that pulls data from a server. You can't get rid of the server nowadays. As for wasting the power of the CPU/GPU, most apps nowadays wouldn't tax even a mid-to-low range CPU/GPU. We're at the point that the hardware has far outstripped the software. Doing something in a "low CPU/GPU demand" setting doesn't mean we're wasting power. It means we're being low-impact on the system. Finally, yes, security vulnerabilities exist in networked applications. Here's the thing, though, they exist in local client applications also. And it's a lot easier to patch one web application than it is to roll out 100 or more client updates.
2. Web UIs are a mess.
With modern JavaScript toolkits like jQuery or Prototype, you can add real-time interactivity to web applications fairly easily. No, it isn't the right approach every time, but it can be a very powerful tool for many different applications. As for consistent UI's, that's a problem for the developers. A developer (whether Web or Client) can choose to make their application conform to standard interface approaches or choose to ignore it. I remember, at the last company I worked for, having to endure Lotus Notes. That client application seemed to have been designed by someone who thought: "Let's take every Windows application convention and toss them out."
3. Browser technologies are too limiting.
No language is all things to all people. Still, JavaScript can be a very powerful tool, especially when combined with server-side processing and AJAX. I've developed many interactive applications without having to resort to Flash, Quicktime, or Silverlight.
4. The big vendors call the shots.
You could say the same about the Operating System running behind your Client application. Let's face it, for most companies this will be Windows. This means you're at Microsoft's whim. If Microsoft wants Windows 7 to kill off some functionality that your application relies on, then you're out of luck. And while I'll admit to a lack of knowledge on this next point, I'm guessing that making your application to run on Linux and Windows is more involved than making your website look decent in FireFox and Internet Explorer.
5. Should every employee have a browser?
We are a web-connected world. There's no going back. This doesn't mean that employees should have free reign to the entire Internet, of course. My company has a web filter in place. Everyone is allowed access to our employee Intranet (and some other sites) while some "non-work" sites (porn, gambling, YouTube, etc) are blocked. In fact, if you are dealing with Windows (as per the previous point), then every employee already has Internet Explorer. Even if you block everything outside of the firewall, it shouldn't be hard to allow access to intranet.yourcompany.com.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
The fact that the different browsers render basic sites differently should be warning enough. Add to that different versions etc; You will never have a standardised audience to utilise these. It will always be lowest common denominator.
By the same logic, one shouldn't program at all. After all, different operating systems handle the same source code differently. Add into that different versions, etc; you'll never have a standard audience and therefore all programs everywhere will always be the lowest common denominator.
Srsly, browser rendering is a well specified standard. To claim it's a barrier to good software is silly.
[Ego]out
I [ the user ] only want to access everything through a web browser.
Within a more nuanced statement, let this be stated: I want to access what your app does or shows from random machines throughout the day, that makes installing a specific executable unacceptable.
On the developer and business side of considerations you may figure out web apps are problematic, and decide to abandon browser based coding. Your decision is a tree falling in a forest with no one to hear. Anything your project makes that does not show in a browser will go unused by the most modern class of computer users.
Oh, and take your punk-ass approach to programming to the Windows 98 forum. Ballmer's lurking there, looking for friends with an anti-thin client stance.
It wants its irrational fear of the web back.
Web apps are not new. We have seen numerous expensive catastrophes. And the trend is not reversing.
Hell we keep pushing more and more in the direction of SOA and chubby clients (thicker than thin, but thinner than thick).
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Why is it worth their time? Most game companies build games for Windows - why not also OSX? They even port to consoles more often than they do OSX. Simply put; you put the most work into where there is most gain. You might get around to smaller markets later, but likely only if there is a convenient way to do so.
[Ego]out
For many people is't already possible to get on and be productive only with web apps. What does this mean for example with a ASUS P5E3 Deluxe. Why would you need the whole massive and slow OS any more if the browser is the only thing needed? And what would you do with the hard drive, tons of memory, usb sticks etc if you could do and save everything to web? Could we see simple, very cheap and optimized bulk machines everywhere some day?
Ville / Varuste.net
...Users like to have all of their applications in one space. They can just open up their browser, and they simply need to obtain the correct permissions to access it. No need to install 4-5 different internal apps, and have to update the stupid thing each time there's a new release, when you only actually use the application once every two months.
Get off my lawn, indeed.
I'm a software support rep and not even a developer and I know this is a blowhard troll.
1. It's client-server all over again.
Web applications encourage a thin-client approach: the client handles UI rendering and user input, while the real processing happens on servers. What sense does that make when any modern laptop packs enough CPU and GPU power to put yesterday's Cray supercomputer to shame?
Concentrating computing power in the datacenter is fine if you're a Google or a Microsoft, but that approach puts a lot of pressure on smaller players. Scaling small server farms to meet demand can be a real challenge -- just ask Twitter.
Furthermore, security vulnerabilities abound in networked applications, and the complexity of the browser itself seemingly makes bugs inevitable. Why saddle your apps with that much baggage?
First, it's not client server all over again, not in the way you mean it. Client/server like windows terminal server or citrix makes it easier to manage company wide systems by giving an IT guy a central point to manage, and that saves time, which translates to dollars. Web apps do the same thing, but they are benefit from even easier setup management and deployment. Terminal server is a pain in the ass when it comes to deploying an app, because it has several ways to do so, none of them web based. You could deploy it by giving everyone a desktop to the terminal server, but then the dumbass users can't figure out which is their PC desktop and which is their server desktop. You could publish the app, which requires changing settings on the server and deploying the proper shortcut to the user's desktop, which takes more knowledge, which not everyone has.
Web apps are easier to deploy in that all you have to do is provide a web address. Everyone knows how to use a web browser and click on links. Citrix even recognized this and provides software to allow you to connect to the citrix box with a web interface!
Siting a laptop is stronger than an old cray is a clever misdirection. The real question is, what's more beneficial for your business, 30 laptops that cost $1000 apiece? Or 1 very large server that costs $10,000 plus 30 laptops costing $500 apiece? I just saved you $5000 on hardware! Plus when a laptop dies, there's less downtime, because I could just hand you another machine and you just go to the web address again. No application reinstalls. Most mega servers these days cost less than a distributed environment and can handle processing quite nicely.
As far as network vulnerabilities, that's just utterly nonsensical. How does that statement say that a webapp is less vulnerable than a distributed app? Data still has to travel over a network in a distributed app! Duh! Besides, most of the vulnerabilities these days dealt with IE specifically and those dealt with how it was integrated with Windows. Pick another web browser, viola, reduced vulnerabilities. Take it a step further and deploy the web app as an intranet app so it can't be accessed outside your local subnet. Network security is for the network professionals, let them take care of it. Provide encryption as needed in the app and access levels for the data but other than that, that's not a developer's domain.
2. Web UIs are a mess.
The Web's stateless, mainly forms-based UI approach is reliable, but it's not necessarily the right model for every application. Why sacrifice the full range of real-time interactivity offered by traditional, OS-based apps? Technologies such as AJAX only simulate in the browser what systems programming could do already.
And while systems programmers are accustomed to building apps with consistent UI toolkits such as the Windows APIs, Apple's Cocoa, or Nokia's Qt, building a Web UI is too often an exercise in reinventing the wheel. Buttons, controls, and widgets vary from app to app. Sometimes the menus are along the top, other times they're off to the side. Sometimes they pop down when you roll over them, and s
"All great wisdom is contained in .signature files"
A CLI is better than a web program?
:-) whatever you type in is run by the Javascript interpreter. Plus there is a tiny API of a few AJAX functions.
How about a web program that is a CLI?
Something I whipped up for fun
"Sure, Web development is fast, versatile, and relatively inexpensive,"
Did Internet Explorer suddenly disappear? I must've missed that today...
I believe web-versus-desktop is mostly a false dichotomy. The problem is that our standards need a rethink. Web browsers started as a kind of e-brochure viewers, and this e-brochure approach was shoehorned into C.R.U.D. uses (biz forms, data-sheets, and reports).
What is really needed is a "GUI browser" standard and/or OSS tool that has most of the desktop-like GUI functionality and behavior we've all grown to like. BUT, this "GUI browser" could ALSO be used for desktop development. Thus, one does not have to learn a different UI platform when toggling between desktop and web projects.
Most GUI kits have made this difficult by making GUI's language-specific. Fitting these to other languages is often almost as forced as HTML-browser-to-CRUD shoehorn jobs. What needs to be done is the design of a GUI protocol that is mostly declarative. Being mostly declarative makes it easier to use by different languages and paradigms. In my opinion, the "everything must be OOP" thinking is largely what has got us stuck with language-specific kits. OOP is not well-suited to declarative APIs/protocols in my opinion. Encapsulation generally leads to behavior-centric API/protocol designs. (Some disagree, it makes for an interesting and heated debate.)
The behavior-centric approaches of existing GUI kits hinders this goal. Most common GUI actions can be defined declaratively if you think about it a bit. The remaining that require Turing-Complete coding can be done by server-side and/or client-side app languages using the more lower-level features of the GUI-browser.
Think of it as kind of as a smarter and HTTP-friendly rework of X-Windows where one usually deals at the widget-level instead of at key-stroke level (but key-stroke level is still possible as an option).
Table-ized A.I.
Isn't that the idea?
The work doesn't magically go away because it's distributed. It just gets harder to keep track of. Something isn't more net work because it becomes easier to measure.
Now if you're stupid enough to concentrate all that formerly distributed work in one place and expect that you don't have to alter your staffing distribution, you deserve what you get.
In any case, TFA was clearly phoned in to generate click through revenue. It's so wrong headed it isn't even wrong. It's not that you can't dream up reasons why browser based application development is a bad idea, but the existence of valid questions is not tantamount to an answer to those questions. Put some effort into answering those questions, then write a real article.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
GMail with calendar integration, chat and now Google Gears is the best damn email solution I have ever used - by far. If a hard problem like email can be tackled in the browser with such success, a lot of things can.
I second this.
What about all those fine thick client apps that refuse to run unless they have elevated privileges on the workstation?
Wearing pants should always be optional.
Regardless of web or not, security will drive movement back to centralized data processing. It is more cost effective to secure data in one location than it is to secure thousands of employee desktops and laptops.
Cost will drive data back to the data center. The author's assertion that modern computers are like Cray's only means that companies are wasting money buying unused CPU cycles that can be better used on a centralized farm where cycles can be distributed where needed on the fly.
The flexibility of web deployment means fewer VPNs, faster deployment of new physical work sites, and the potential to run on all sorts of devices.
I think I'll start deploying stand-alone apps which are just my own lite wrappers around the IE active-x control. That way it's a 'fat' application but updates and deployments are a cinch. It's the best of both worlds.. I control their 'browser' environment and I only have to update the server.
Check out my lame java blog at www.javachopshop.com
That's why there are numerous ajax libs that give you a standard of cross browser support without having to worry about oddities. YUI is my favorite although there are others. All of their main controls work the same across all top browsers - very nice stuff.
I think you're going to see an explosion of standalone applications tethered to a web-based datasource or back-end. iPhone and Android basically do this already - taking their cue from email programs since the dawn of the internet. Programs like Steam allow you to install local, fat clients through a thin client interface. Each of those pieces has a reason for being fat or thin, and you want to take advantage of that.
I think, in the end, the point is that you want to be confident your interface is usable where-ever, and that your backend can be swapped up without version issues, and that either way the program can do everything it needs to. The web is very good at the first two, it's just that the domain of problems it can manage has not yet expanded to the third. Is that anything but a matter of time?
[Ego]out
Once everyone has an iphone like device that has a standard development environment
This is where people miss the point. There won't be a standard interface for local coding, because that would require a monopoly on the operating system... and as Linux has proven, a lot of people don't like that.
Java tried it. The idea behind Java is nice, but those who want the power of local coding will usually go with C anyway because it's simply faster, and they can access all of the platform-specific speedups that Java blocks (by default) in the interest of platform agnosticism.
There's a reason that web apps are as popular as they are, and that's that a thin client allows the developer on the other end of the connection to do all sorts of crazy stuff on the high-powered server and just report to you the results in a language that for the most part every browser understands.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Cross-platform GUI libraries are inadequate given the wide variety of devices, platforms, user expectations, usability standards and the extreme disparity in basic user interface elements, layout engines and even programming languages.
HTML is currently the most ideal because it offers a cross-platform and largely-standardized way of expressing both content and layout. Using a browser GUI solves a lot of difficult issues, including look-and-feel and specialized layout for peculiar form factors (like cell phones).
Essentially what I'm suggesting is that we are looking at the situation backwards. We should be using HTML to lay out GUIs locally, rather than have clients connect to these applications remotely.
So which is it, Neil? Fat apps on the desktop, or thin/lean apps on the web?
This discussion comes up every once in a while and I think that anyone who has had to build and maintain both types of applications can appreciate the points in the article.
For database-centric apps that are in-house tools, I really think something like Network Transparent Widgets could be the best solution.
Keeping your business and presentation layers separate is the key to ensuring that your options are open in future. I'd like to think that I could take my php web app and put it into a php-gtk application without much extra work.
I could see a time when that happens somewhere down the line when the same app is basically offered in web or desktop format. There's definitely a time and a place for desktop apps. The web is a pretty square peg for the round holes of business, though you can get away with a lot.
This article ignores the real reason web apps suck: You have to be connected to the web to use them.
Developers keep forgetting that not everyone has broadband access, an iPhone in their pocket, or ready access to WiFi networks. Bandwidth isn't cheap, it isn't always reliable and it isn't always there. I mean, come on - I like Google Maps as much as the next guy, but if I find myself stuck in an out-of-service zone I know I can rely on the road atlas in my car.
I think web apps are great for what they do but I don't think anyone should rely on them alone. If cost is the major issue with desktop apps, open source is the answer.
(rant on) I just love it when a web guy tries to tell me that his app renders "great" on any smartphone.
As I scroll down to get to the login/pass field, only to find that the fields don't accept grafitti characters when I use my Centro, I look at him and he says "oh, well, I only used my iPhone to test it out". Then I ask "did you at least try Android? Maybe a BlackBerry, or a WinMob phone?" Only to hear "That's a problem with the browser for your phone, we have no control over that."
Really now. The main reason people want to do web apps is really simple...they want to do it cheap up front. They don't want to hire someone to write clients that are naturalized to each platform that are easy and efficient for their users to use...they want to make something on a server and pray it works. And suddenly, if by some odd chance that their poorly rendered browser based app takes off, their datacenters are overworked and they need to hire more server guys, buy more servers, and lose more of their margin to maintenance. Or they just work their web guy to death trying to solve a nearly impossible problem. Mobile clients are special...they're simple enough that one person can knock out the code reasonably fast, provided they get a good upfront design. After that, the only time you have to push new revs is when there is some massive new direction in the market. Most phones support wireless updates these days, so it's not that hard to coordinate.
Users actually DON'T WANT to upgrade a mobile app every month because it's annoying. Phone apps are all about being simple to use and reliable. Starting up a browser is more clicks than I want to do if all I want to do is log my work hours, check some data, check a map, whatever.
And for you Java people, no. It's not as cross platform as you think it is. And it's not the phone's fault that it's not completely compatible with your favorite language. Yeah, it's hard. Making money IS hard work. Doing it easy doesn't mean you're going to get customers. Java doesn't give you enough control over most devices to do anything more than just the basics. That's the downfall with "cross-platform". Sometimes you have to put in a little work and make your app NOT SUCK for people to use. (/rant)
Well, that was the lamest collection of reasons I've ever seen.
It's client-server all over again? Umm. Yeah? So? Most enterprise applications are client-server. Include document and process management and your entire network is a gigantic client-server system. Come on. Is that supposed to scare anyone? Really? Wow. Should every employee have a browser? Hell yeah. If they have a computer they should have a browser. If you have a problem with your employees doing other stuff than work then you have a problem that won't go away because you take away the browser. That should be obvious to anyone who has ever been an employer.
And saying that the web is a place that is dominated by big players is just ludicrous when advocating working on the desktop instead. (I don't think I need to spell this one out for you)
No, this is all crap. There are valid reasons why certain applications shouldn't be web based. But the article lists none of these. Too much load on the datacenter. I mean seriously. Come on!
I've had a wonderful time, but this wasn't it -- Groucho Marx
I think right now, there are not that may applications that can work as web apps. The only one I know that works well are email, instant messaging and maybe teleconferencing, where if you suddenly lose your Internet connection you won't suddenly lose a lot of productivity.
In my opinion, business apps should STAY on the local computer, what with the price of hard disk storage being dirt-cheap nowadays and you can work "offline" writing documents, creating spreadsheets, creating presentations, etc. Given the cost of OpenOffice (e.g., free), do you really want to do office applications with a web-based app?
I am the sole IT person for a nonprofit, volunteer animal rescue. They don't have any money to pay for professional staff (preferring to spend it on the animals instead).
All of our IT tools (a wiki, a bird tracking database, OTRS, our website, a chat server, etc) are webapps.
The type of people, for the most part, who are willing to volunteer to do animal rescue are not geeks, techies or even "power users". For a long time our animal tracking database was a client application. 75% of the volunteers had so much trouble figuring out how to INSTALL IT and connect it to our database (even with written instructions) that they didn't even use it, and had to ask others to do all their data entry for them.
It got to the point that each adoption coordinator had to be set up with a technically astute "data entry buddy".
Now that our bird database is a webapp, all the coordinators can use it, because they CAN navigate to a website and use the tool.
So, yeah, there's a place for thick client apps too, but without webapps we'd be screwed.
While browsers were readily sitting on all these computers.
Switching to server-client brought some sanity back into my life.
Certainly the network should be policed to make it secure. No helmet, no body armor, no steel door makes a security. It's just a part of it.
Server overload? 4 cores, 12 GM RAM, 2 TB hard disk are overloaded? Check your code and especially queries. Say, if in PHP you are to get an integer do only casting $a=(int)$_POST['a']; no further sanitizing is needed. Casting is non-function operation and requires little computing. Limit queries. Writing good queries and sticking to efficiency and security philosophy on a server may make an application work.
One more thing, vote for politicians who use Internet and pledge to protect it.
Web apps are fast? FAST??
I'm yet to see one that i would call fast..
Can anyone recommend a good therapist for me.. er.. my schizophrenic network card?
Webapps are here to stay, for several reasons having to do with the economics of their delivery and maintainability.
As developer organization, you upgrade in one place, flip a switch, deploy it, and you are done. All, or a controlled subset of your customers, is now running the new version.
And most importantly, you control what versions and how many versions your software customers are running, thus slashing maintenance costs.
Also, everyone encounters the same bugs. Believe me, that is a feature not a bug, as it leads to quicker discovery and of necessity quicker resolution of the bugs, which is good for the customers, all of them, despite their own laziness in upgrading their s/w.
Regarding the thin client problem. Thick client web apps are just in their infancy, and will almost certainly dominate in the long run, after some serious platform wars.
Where are we going and why are we in a handbasket?
And for the love of god, stop broadcasting our IP address!!!
Web apps are OK for the "enterprise" the problem is though is that enterprise "solutions" become standards for everyone and thus Uncle Joe and Aunt Jane in the past were stuck with M.S. Word if they wanted to be able to open attachments and print at Kinkos or whatever.
Will home users now be stuck with sub optimal web apps when open office or Abi Word, whatever would serve their needs better?
Tired of all the isms, don't exploit people as an employer, or a government, mmmmK?
I think the parent is right. But I'll modify his prediction to say "on mobile devices". Case in point:
Can your java applet talk with the GPS unit on an iPhone? If no, then you write a native app.
I can easily forsee a lot of "real" applications written for the iPhone or Android. Of course, Andriod might be a java stack, I'm not sure :-)
PS: Hopefully someday soon there will be a standard way for a javascript application go talk with a mobile phone's GPS. There is a *huge* potential for GPS + Mobile + Always on internet.
It doesn't do you any good if the userbase never bothers to upgrade.
Dear IE6 users: UPGRADE!!!!!
I second this.
What about all those fine thick client apps that refuse to run unless they have elevated privileges on the workstation?
What about all those fine thin client web-based apps that need to use that one feature of IE/ActiveX/Flash/Java, which you can't update unless you have elevated Windows access to run the update?
But in general, I do agree with you, at least to a point.
The last job I worked I had to run some apps in IE, some in Firefox, etc. I finally got so tired of the lazy, incompetant "IT" guy not updating basic system stuff like Java, etc. I just threw it all on a USB drive.
Which saved my ass more than once when my computer was kindly 'updated' overnight, which meant the dumbass just hooked up an external harddrive & imaged the machine.
I think all in all, if you have a decent IT department, both methods work fairly well depending on the specific needs you have.
If you end up with a hodge-podge of computer hardware and OS's, you'll run into a lot of trouble either way, but be slightly better off with the web apps because at least you can shift the workload from your engineers/developers and onto the IT drone.
"Accesskey" is the magic attribute!
That said, the example I found did not work in Firefox. When I hit "ALT + e", the caret did not move to the box in the example. Instead it opened the edit menu. This was the case no matter what part of firefox had focus. ..Oh wait, I had to hit "ALT + SHIFT + E" because the access key appears to be case sensitive. Then I hit "ALT + SHIFT + P" to move to the "Phone" field and Windows Media Player popped up. I guess in Firefox guess the GUI takes priority over the page for access keys.
I tried the same page in Chrome and the access key was *not* case sensitive and "ALT + E" worked just fine. IE7? Works as good as Chrome.
Conclusion? A good idea in theory, but the browser support, at least in Firefox, is very half assed.
On reason being overlooked for web apps is that the app keeps running, doing things for other people, even when your system isn't.
# Erik
A very large percentage of enterprise applications are multi-page forms based. The works reasonably well for that with a relatively low training issue. Every new hire knows how to use a web browser. Older very shortcut, abbreviation driven systems let experienced users fly through the system but many jobs have either high turnover or high numbers of irregular users. Web apps are great for that.
Web applications are easy to roll out to the enterprise without any client reboots remote install scripts or any of the other nastiness. All of the client machines in the enterprise are supported. Remote deployment doesn't require remote desktop or other higher complexity solutions. Most enterprises only support one browser internally so there isn't any cross browser issue.
Fat apps have their own issues. Applications that are large enough to be very hard on the web are often complicated and hard to build as a fat application. Data integrity issues across views and panels can be a pain. Two tier client server applications often still need two levels of validation, both on the server and client.
Mail and calendaring are two good examples of applications that work well enough on the web for some very (very) high percentage of users.
This guy must have a few Thick Client mates that could not make the transition to Thin client programming who are out of work.
Never heard of the biggest load of crap in my life..
Nearly everything he says is wrong. 1 example Try and deliver a new thick client app in a business enviroment. 6-8 weeks and 15k for the packaging boys in india lol.
When all you have is a hammer, everything looks like a nail. The correct answer to which kind of apps developers should focus on writing is "All of the Above". I want web apps, I want native apps written for specific operating systems, I want cross-platform apps written in languages like Java, I want hybrid apps that use web services. The more choices we have the easier it is to find just the right tool for the job,
...don't blame the tech for any nefarious purposes, right?
'Push Technology' just meant that instead of people refreshing websites all damn day long, the website would shoot the client a new copy if there was anything new on it. Push died, people still didn't want their sites refreshed by clients all the time, so they set up RSS feeds instead. Now everybody hammers the RSS feeds all damn day long. It's less bandwidth than the whole page, but it's still the same problem.
Heck, we actually use 'Push Technology' all the time. Instant Messenging, for example, is push. Sending an e-mail is push. Proper push e-mail (where the service goes to connect to your phone, rather than your phone checking every 3 minutes)... is push.
Yes, there are even RSS subscription services that use push.
Back to the 'nefarious' bit, however.. some people were scared that media moguls/governments would try to squash pull and have clients receive push only - thus limiting the information you can get to whatever is being pushed by those groups. I think it would have taken a *lot* for that to happen back then - it'll be neigh-impossible now.
This guy is full of it. There are so many new options coming down the pike, all essentially web apps despite their various flavors of enabling technologies. This guy has had his head in the sand. Besides--what is the alternative? Fairy Dust Apps that just live in the air and drop down out of clouds of pixie dust?
Write Once, Debug Everywhere
I will assume that was meant in friendly jest.
Note that it may still be possible to put OOP wrappers around the GUI API for specific languages. Thus, one is not necessarily abandoning an OOP viewpoint from the app developer's side.
The tricky part is that the "state" is inside the GUI engine and not in app language objects. (This is necessary to make it multi-language and multi-paradigm-friendly.) Making it appear as if its in app language objects, or mirroring the state as app lang objects could be a bit challenging for some languages.
Table-ized A.I.
ignoring the parent's incoherent and completely off-topic rant, the arguments raised by the author are somewhat flawed.
take for instance:
um, all over again? when did we ever stop using the client-server model? client-server architectures are so prolific because it's simple and it works. some of the greatest technological successes in recent decades have been based on the client-server application model--for instance, database servers and network services and their derivative technologies such as the world wide web, ATMs & EFT, cellular networks, instant messaging, IRC, all types of online gaming, and the list goes on.
commodity computing moved away from dumb terminals and thin clients perhaps, but things don't have to be one extreme or the other. you can have the best of both worlds. a modern MMORPG is a client-server application, but they're certainly too graphics-intensive to run on a thin client. but if you're developing an intranet application that already uses networking and databasing, two of the most prominent classes of client-server applications, then what is wrong with using a web front-end that is cheaper and faster to deploy?
with today's high speed networking and mature browser technologies, most enterprise applications gain no benefit from being developed as a standalone desktop app. an accounting application doesn't require a complex desktop interface or lots of processing power, same with CRM and other business applications. applications like 3D gaming, multimedia production, CAD software, scientific modeling, etc. still require a standalone desktop application. but business apps that consist solely of filling out text fields & electronic forms and outputting textual data with very basic graphics are perfect for web front-ends--especially if they're network applications.
I peeked at his bio.
Some guy who writes about tech. A lot for a long time sure. So what? How many movie critics have sat in the directors chair? I sure as hell wouldn't ask one how the next blockbuster flick should be shot, filmed, editing, cast, etc.
Most of the things he puts on that complaints list are hardly confined to web application. "System" application as he puts it, is just as rife with the same bull shit.
counter points.
1) Ever write a 3 tier app in MSV*? Same crap.
2) Bull. "System" applications have the same issue. People building their own UI's and messing with the user.
3) Because maybe we want it on the web in the first place. That's why it was built as a web application? Duh.
4) And Windows 7 now? They haven't fixed Vista. Same bull. The big boys call the shots. OS or browser. At least Firefox runs on Mac, Linux and Windows. Cross platform clients are where it's at.
5) Seriously? that's the lamest point ever. Who can't fit a browser on their 4GB USB drive that cost $9.95? He who wants porn gets porn.
And an extra point. This comment is a web app in it's own right. So is this site. It's hardly a static 5 page site with no user interaction is it?
That's not entirely true. Sure there are "webby" workarounds, but for the most part the following things are difficult to do right and reliably in a web browser:
* Edit Grid - A standard editable "grid" control to provide a spreadsheet-like data grid (AKA "Table Browser"). Extra points for allowing different widget-types in the grid, such as combo-boxes, check-boxes, etc.
* Combo Boxes (hybrid text and drop-down list)
* Menus (menus in JavaScript+CSS/DOM with frames are a nightmare)
* Tabbed sub-portals or sub-forms
* Collapsible tree/outline browser
* Formatted Masking and/or Validation - Example: Date entry
* Pop-up Dialog Boxes - (Tabbed browsing and IE's security prompts have made the traditional "target=_blank" solution less desirable.)
* MDI-style Interfaces
* Right-Click Features or Menus
Many of these can be emulated via JavaScript+CSS/DOM, but the results tend to be unpleasant and browser-version-sensitive.
Table-ized A.I.
Not only that, but SNA is much better suited to business apps than TCP. Like TCP, WebApps are the reality. They are proliferating like crazy while those old client server apps are slowly (too slowly) dying out.
Maybe you have so few repeat users *because* you deployed a web app?
No one wants to repeat *that* experience?
SCNR :)
[The captcha was "cactus": how fitting!]
* Edit Grid - A standard editable "grid" control to provide a spreadsheet-like data grid (AKA "Table Browser"). Extra points for allowing different widget-types in the grid, such as combo-boxes, check-boxes, etc.
I don't get how this is hard. You might even use actual HTML tables (gasp!) to lay it out. What is it that's not working about these?
As this seems to be a theme, let me summarize:
* Combo Boxes (hybrid text and drop-down list)
* Tabbed sub-portals or sub-forms
* Collapsible tree/outline browser
* Formatted Masking and/or Validation - Example: Date entry
These are not only done in Javascript/CSS/DOM, but they have been done so many times that you can pretty much pick up a jQuery plugin, throw in a one-liner on the client and maybe five or ten lines on the server, and you're done.
This is also not valid:
Many of these can be emulated via JavaScript+CSS/DOM, but the results tend to be unpleasant and browser-version-sensitive.
You'll have to be more specific about "unpleasant" -- I find them quite pleasant. And the browser-sensitivity is hidden away in a library somewhere, where I don't have to care about it.
* Menus (menus in JavaScript+CSS/DOM with frames are a nightmare)
So don't use frames. (Seriously, who uses frames?)
I'll amend that: Use iframes if you must. Otherwise, stick to emulating them with CSS, maybe even AJAX -- that way, your users get bookmark-ability.
* Pop-up Dialog Boxes - (Tabbed browsing and IE's security prompts have made the traditional "target=_blank" solution less desirable.)
That's most often a UI mistake, IMHO. It's much cleaner and friendlier to put the options in that "dialog box" in some expandable/collapseable block next to the element it affects. A notable exception might be editing a spreadsheet formula, which has a dedicated area elsewhere on the screen.
Popping something up, if it's done right, means you've now covered up what the user was doing -- which might include information that goes in that dialog box -- and you've restricted their navigation, and you're adding modality to the application which doesn't need to be there.
However, I got overruled at work because of how trivial the jQuery Boxy plugin makes it to throw up a dialog box -- within the same page, of course, not a popup, but it can be made draggable, so not as obnoxious.
* MDI-style Interfaces
The browser is your MDI-style interface. A properly designed app, and you should be able to middle-click on any link and have it open in a new tab. Depending on your browser, you should be able to pop tabs out of the window, move them between windows, or split a tab into panes.
Bonus: Having done it this way, the whole issue of which features to include inside that MDI window is completely removed. It supports whatever the browser supports. If the user wants something you didn't think of, they can just use a different browser, or install a browser addon. How were you going to make your desktop app that extensible?
* Right-Click Features or Menus
Apple has a point -- while right-clicking is great, you shouldn't rely on it.
That said, Google Docs seems to do a decent job of that. I can't imagine how it would be hard -- what is it, an "OnRightClick" event?
I would say, if you're still in doubt, go look at some of the things that have been done with, for example, EXTJS. I hate to mention that library -- the developer did a pretty shitty thing with his license, and we dropped it like a rock for jQuery -- but it has some pretty impressive demos.
The only problem I see with the "webby workarounds" is that you can get them wrong (which is true of anything), and that they are technically slower than a native widget library -- but that will only improve, and performance is already more than "good enough".
Don't thank God, thank a doctor!
We've seen all of this before and we will see it again... (I've heard that line somewhere before)
So where do rich clients apps fit in the pendulum swing? I think rich client apps give developers absolute control over where a process runs. They take more planning and deliberate server communications, but I believe the payoff is huge. We developed a Java rich client framework for our applications development. We develop under Linux and test and deploy to Windows users. We never tested it on Mac, yet we just had a Mac savvy user install it and run without issue!
Don't buy the argument that rich clients apps are too hard to distribute. We built our own tool that will reconcile the installed Java class files at user login. TALK ABOUT A MASSIVE TIME SAVINGS in both support and debug! It ensures all users are running the same version, all files are checksum validated, and since we deploy files at the .class level (not by the jar), it is like an rsync, often requiring less than 10KB transfers to perform an upgrade. All of this was developed before things like Sun's Webstart, except we have extended features like user authentication, and server, application and service selection all before they even start the application. These features have made managing rich client apps a breeze!
As for performance, we run rings around browsers! Our framework implements both in-memory and persistent object caching. It is a true n-tier architecture where a hierarchy of caching servers receive and broadcast updates which optimizes slower connections. For high volume customers we install a caching server behind their firewall to consolidate traffic over the net to the server.
The payoff? Users can view large sets of data, change sort orders and instantly change their view on the data, all of which occur solely on the client side. It happens quickly, without breaking the users train of thought. Our framework regularly can easily deliver 50,000 objects to a client application for them to view and manipulate, and should any one of those objects change, they will see that change immediately. Not going to happen with a browser any time soon.
We have customers running our software as a service using only a cellular connection for an office of four users. The framework is completely optimized for slow connections; once I gave a 30 minute demonstration of our inventory software using a laptop and cell connection. Afterwards, I showed them the connection stats; the total download was 4MB and the upload was 750KB. For contrast, I then spent less than five minutes browsing their current website which quickly racked up over 15MB of bandwidth.
The web has it's place. We would not expect any anonymous visitor to download and install an application. It is the right solution for the broader market, but I refused to roll back the user interface and usability 20 years and abandon the power of the desktop computer to use a web browser for enterprise solution. The web is convenient for everyone, optimal for no one.
... again, and very likely ... again.
"Old bag" has more than one meaning.
Problems With Mobile Security
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
I'm using Pascal-style quoting, if you don't mind. Better WYSIWYG.
(* You might even use actual HTML tables (gasp!) to lay it out [make data grid]. What is it that's not working about these? *)
Column names scroll up out of range, and you cannot widen or narrow columns as needed by dragging the borders.
(* These are not only done in Javascript/CSS/DOM, but they have been done so many times that you can pretty much pick up a jQuery plugin, throw in a one-liner on the client and maybe five or ten lines on the server, and you're done. *)
Like I said, they tend to behave a bit clunky at times, and are very sensitive to browser versions. Thus, many may not work when IE 8 comes out, for example. This can be a big headache.
(* And the browser-sensitivity is hidden away in a library somewhere, where I don't have to care about it. *)
How can it be? The author didn't have IE8 around when they developed it because it didn't exist yet. You cannot test what doesn't yet exist. They often rely on poorly documented or undocumented features of DOM/CSS that could easily go away or not work in future browser versions.
(* If the user wants something you didn't think of, they can just use a different browser, or install a browser addon. How were you going to make your desktop app that extensible? *)
Browser add-ons defeat part of the purpose of using web-apps instead of desktop installs. Desktop installs are nearly as easy as add-ons if done right.
As far as your MDI argument, I found it weak. For one, the developer doesn't have a lot of choice about the size of a pop-up window, such as an advanced list-lookup wizard. New "windows" taking up the whole screen limits GUI design.
(* The only problem I see with the "webby workarounds" is that you can get them wrong (which is true of anything), and that they are technically slower than a native widget library -- but that will only improve, and performance is already more than "good enough". *)
The biggest problem/risk is Microsoft sabotaging JavaScript/DOM/CSS. They can and will if web-apps take up too much desktop sales. A small example is the stupid warning prompt you get if you use window.close() in IE7 but it was not in IE6. Thus has mucked up many of my web apps. MS does things like this to complicate web development. They claim its for "security purposes", but the prompt could at least ask to bypass warning prompts for a the current (selected) domain.
Table-ized A.I.
lets see if the stars (sic) decide to do something about it.
Java has *everything* - applets, jws, security libraries (not in popular PHP yet)
Yet, people dont use Java.
And Java runs on gazillion platforms with minimal code change.
It's sick that the leaders of web 2.0 skip java applets and java web start. If they put a tenth of the effort bettering OpenJDK, we'd have much safer, robust apps, given Moore's law and Microsoft's "competitive hardware upgrade strategies".
Well, SUN doesn't seem to understand this.
I've stopped programming in DOS just because of that Win32 API!
Once all that windows cr*p came out, I've stopped programming ASM & TP (BP) .. No kidding ..
I've moved writing bbs-door applications for Proboard & Remote Access and swiftly moved to Perl for web applications.
I guess I've always loved the text more than the icons ;)
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
It seems to me that more and more apps are coming and going to the Web. These apps are becoming more and more powerfull. The network is getting faster. I believe that in the future we'll be playing, PS3/ Xbox 360 - alike games, do our Photoshop stuff etc. over the Web in a browser on your LCD TV in the living room. There is just no reason, no added value, to have it on a local machine. Less (local) hardware upgrades, no more evil lock-in, more choice etc.
For all those who wish to poo-poo web applications.. be mindful that our beloved Slashdot is backed by a web application... ooohhhh and AJAX too!
OS dll hell, where developers had a party on operating system files. One developer would enhance an OS file replacing it with his/her cool extensions needed by their application. The next set of developers would extend the same OS file breaking the other applications needed extensions. With modern programming languages / OS developers inherit functionality and extend it making a new file, so the issue has been reduced.
I installed Google toolbar on Vista the other day to get my favorite site search tool and it broke internet explorer. Fortunately add/remove programs let me remove Google toolbar and my browser started to work again. My guess is Google compromised a file needed by windows for the browser to work.
Now if Google can't make an installer smart enough to detect my OS/browser to not install the browser plug-in or it wasn't tested properly, then when all the small software shops start making web plug-ins the consumer has no guarantee anything will work.
So how is this any worse than a windows application. If a non driver related windows program causes a dll problem and breaks another program the worst case scenario is a few programs are down. If a web application breaks my browser then every web application I run is down.
"Never say Never."
I hate crappy AJAX GUIs as much as everyone else, but I also know that writing a decent "offline" application in a suitable language takes at least one order of magnitude more effort - and that is before you attempt to implement some of the features every web app has naturally (automatic updating etc.).
It's convenient to rant about the stuff we use every day, but when was the last time *you* wrote and supported a non-web based, cross-platform application with GUI and had first hand experience with all the problems involved? Nowdays we're all spoilt web developers, aren't we ...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
That way you need to support only three (IE, Firefox, Safari).
IANAL but write like a drunk one.
It is really simple and it can be done.
You don't let an application in your shop unless:
a) They are commited to open standards.
b) They show you a road map of upgrades for the next 5 years.
In any case, if you are really screwed, launch a virtual machine that has a different browser and get on with things.
IANAL but write like a drunk one.
Otherwise one would have to code such features into a desktop application.
I'm no fan of webapps. I hate any browser scripting, except as optional additional client-side form validation. More importantly, I think this whole trend towards webapps is crazy. In these days of cross-platform GUIs that have been developed for years to support a well-recognised, fully featured widget set, OpenGL rendering, etc., it's crazy to think we have a bunch of new developers doing all the same stuff over again, making the same mistakes. It took decades to develop and standardise those GUI layers the first time around. We made tons of small iterative improvements, like adding accessibility keys, customisable toolbars, click-to-sort in headers, double-click to edit, file dialogs, etc. It'll be at least another five years before the web has similar widget sets, let alone standardisation and full compatibility with other tools like screenreaders and debugging and all.
That said, I think it's worth recognising here that the web already IS the lowest common denominator -- originally, it's just a way to distribute a page across platforms, without even so much as page layout info. Essentially, it was one step beyond dialing into a BBS and asking for pages on your ANSI terminal.
1. It's client-server all over again. Web applications encourage a thin-client approach: the client handles UI rendering and user input, while the real processing happens on servers. What sense does that make when any modern laptop packs enough CPU and GPU power to put yesterday's Cray supercomputer to shame?
Simple solution DO NOT BUY SUPERPOWERFULL PC's. Guess what, try and figure out HOW much you can save NOT just by using google docs by not buying MS Office but by not buying a powerful PC either. In fact my P3 booting from network works just fine with webapps, Office not so much (that it boots linux of course does not help). Oh yeah, another cost saving. You don't have to buy Windows either. Sorry, this argument fails, we bought powerful PC's because our clientside programs and OS demanded it, if they don't, we don't have to buy powerful PC's anymore.
Concentrating computing power in the datacenter is fine if you're a Google or a Microsoft, but that approach puts a lot of pressure on smaller players. Scaling small server farms to meet demand can be a real challenge -- just ask Twitter.
Eh, twitter? Good luck making that into an offline app. What next, offline websites? Yes, scaling a serverfarm is hard but is this applicable to most small companies choosing between a web-app or a desktop application (that usually still needs a server backend anyway). Sorry, but datacenters are nothing new and the likes of IBM can happily sell you all the power you need, you can pay them with the money you saved on your client PC's. Oh, and if all your data is local, how are you going to back all of that up? If all your data is server side, then your client programs still need a server farm to serve them. Failed argument again.
Furthermore, security vulnerabilities abound in networked applications, and the complexity of the browser itself seemingly makes bugs inevitable. Why saddle your apps with that much baggage?
In a net-app I only need to patch ONE piece of software, if it is purely clientside I need to patch all clients out there. Browsers patches are being taken care off globally. If you have a client-app you still need a patching strategy so nothing changes, you just patch the browser instead of your own apps. The complexity of the browser makes bugs inevitable he claims. True enough but for most web-apps these bugs are totally irrelevant. Futhermore such bugs are under constant scrutiny where as your own client apps are not. This argument by him is just scare mongering. There are secure web-apps and insecure client side programs.
2. Web UIs are a mess.
The Web's stateless, mainly forms-based UI approach is reliable, but it's not necessarily the right model for every application. Why sacrifice the full range of real-time interactivity offered by traditional, OS-based apps? Technologies such as AJAX only simulate in the browser what systems programming could do already.
So he says in the title that UI's are a mess and next that they are reliable. He seems confused, Ajax is for communicating with the server, what is the difference between using Ajax and whatever your clientside program happens to use? Did he ever program client programs that interact with servers? If so he would know they are easily as messy.
And while systems programmers are accustomed to building apps with consistent UI toolkits such as the Windows APIs, Apple's Cocoa, or Nokia's Qt, building a Web UI is too often an exercise in reinventing the wheel. Buttons, controls, and widgets vary from app to app. Sometimes the menus are along the top, other times they're off to the side. Sometimes they pop down when you roll over them, and sometimes you have to click. That inconsistency hurts your development budget, but it hurts usability more.
Now he is just getting silly. He mentions THREE UI systems ALL COMPLETELY DIFFERENT and then complains web-app developers don't follow a standard. WHAT STANDARD? If there was a standard M
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I used to work in the NASA software technology lab at JSC. Around 1994 (memory fails me), so guys from Sun came and showed us a little Java application and how it ran on Sun and Windows and looked the same.
It was slow then. Really, slow.
That same trivial application - 15 years later - is still slow. The good news is that is also uses a shitload of ram and an average java application programmer is nearly clueless about the OS and hardware they're using. There are exceptions, but most "pure java" programmers boast how they don't need to know. It doesn't matter.
I use a few non-trivial java applications daily. Most things about them are fine, even good, but the startup lag, click lag, and processing lags for trivial things really bother me.
Yes, java still sucks 15 years later. Delphi is better. VB is better. QT is better. C/C++ is definitely better. And finally, full web applications ( we use Zimbra for enterprise messaging) with drag and drop capabilities are better than java applications.
As a full time web application developer I hate them mostly because of browser incompatabilites with standards - HELLO Microsoft! DO YOU HEAR ME!!! Your IE browser (any version) sucks big green donkey dicks! EVERY VERSION! We are sick and tired of having to do a million HACKS to get your crappy browser(s) to render / handle pages correctly! Why is it Firefox, Opera, Safari kick your browsers ass? Because they are more standards compliant than you fucking browser(s)!!! I can write code that works perfect in Firefox, Opera and Safari but of course doesn't work in IE - I have to do hacks from hell to get IE to work! I'm pushing to use an "anti-IE" script in our apps - basically refusing to support IE because of the crappiness of IE. I'm looking at modifying the IE6 Blocker to work with -all- IE's
The Truth is a Virus!!!
Once upon a time, we had a thing called a mainframe and a bunch of terminals. That mainframe probably came from IBM and the terminals, too. The terminals from IBM are often smart enough to handle (limited) input verification and drawing forms and such. The intelligent terminals were a brilliant necessity given that the mainframes liked to process jobs, and it made the most sense to have users just queue up their requests rather than having an interactive session.
Today, we have a thing called a web server, and a bunch of browsers. That mainframe could come from anyone and communicates with the browser (admittedly, it's really vice-versa) via a more-or-less standardized protocol. Because of the random-latency nature of the internet, this form submission model is ideally suited to provide most types of application content to the user.
It's true that there are times when a web application doesn't fit. This is mostly cases where the web browser doesn't already provide the functionality that you want to use. When you have to build new interface metaphors into a web browser, you tend to hit a performance wall. But then a new browser comes out, and it speeds up.
I guess my real question is whether there is actually anything superior. It is so bloody easy to put together a web application that anyone anywhere can use, there is nothing else even close. There's easier development systems, but there's nothing more broadly supported, not flash, not java.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Basically the reason that people write web apps is because port 80 is the only port they know they can get access to through all the network barriers, AND the fact that the browser based standards endorsed by the W3C not only are sufficiently adopted but are are free of charge, unlike Microsoft's widely adopted operating system that is neither free nor open.
Seastead this.
"what value does a browser add to your application"
3) (should be #1 though) Interoperability.
Yes, browsers treat fancy stuff differently, but if you're doing forms and tables (the heart of 80% of the webapps I've built/seen), you will spend exactly *zero time repackaging your stuff for various platforms.
Java promised to take this off our hands, but 15 years later not much progress.
My turnips listen for the soft cry of your love
"Right now web apps are king because they're always only the nearest computer away, and work on almost everything."
I run a bunch of computer labs at a large university, I can't tell you how many times instructors complain that the web app their class needs won't work, even though "all it needs is a web browser." Of course when they actually try to use it on our computers, it tries to install a proprietary plug in and pukes because we won't let users do that. If a user needs a proprietary plug in to use your app, you might as well just make a client for it and bypass the browser.
Never let a lack of data get in the way of a good rant.
here: http://boblog.matsuoka.com/post/74368904/the-case-for-web-apps
-- this sig beneath your current threshold
I don't mind it -- going to continue using quote tags, if you don't mind. Raw habit.
Column names scroll up out of range
Easy enough to keep them in place, or even rip the whole row out and put it outside of the container, with a little CSS.
you cannot widen or narrow columns as needed by dragging the borders.
And a little Javascript fixes that.
many may not work when IE 8 comes out, for example.
If this is a huge problem, force your users to install Firefox. I don't see why that would be harder than forcing them to install your random little app.
The author didn't have IE8 around when they developed it because it didn't exist yet.
And as IE8 betas start to show up, the authors add support in that library.
In that way, it becomes exactly as boring and transparent as what parts of OpenGL are implemented in software or in hardware, and what parts of the driver are in kernel space or the GL libraries. I just tell the library to draw a triangle, and it draws the triangle.
They often rely on poorly documented or undocumented features of DOM/CSS that could easily go away or not work in future browser versions.
Not the ones I use, certainly not what you just described about an HTML table. Mouse events, resizing elements, and floating elements on top of a scrolling window -- or, alternatively, a div set to add a scrollbar on overflow -- are all well understood, well specified, and well supported.
Browser add-ons defeat part of the purpose of using web-apps instead of desktop installs.
You're missing the point of addons, then.
I'm not saying an app should require addons. It should work well enough on a standard browser.
I'm saying addons are a way for a user to script that app -- without which, you'd have to embed a language like Python or Lua and develop your own scripting framework.
For example: Slashdot works well enough without addons. However, there is a Greasemonkey script which provides a quick confirmation system for moderations. And Slashdot didn't really have to do anything, other than be a website, to enable that scriptability.
The biggest problem/risk is Microsoft sabotaging JavaScript/DOM/CSS. They can and will if web-apps take up too much desktop sales.
The way I see it, they tried and failed. There's too much chance now that, if Microsoft actually does break the Web sufficiently, large sites that people rely on like Google, Myspace, etc, will start forcing people to switch. If you can't get onto Facebook from IE, that's easily over a hundred million IE users Microsoft just lost.
So, they have been dragging their feet, because they don't want to make the problem worse, and because they do want it to still be sufficiently painful that people want to use Silverlight.
But they've also been making real progress so that people won't abandon them entirely.
Oh, and again, Javascript frameworks mean we don't really have to wait for Microsoft. I use CSS2 properties every day, probably even some CSS3, via jQuery -- if run on a browser that supports these natively, it Just Works. If run on IE, a workaround is applied.
Don't thank God, thank a doctor!
I am posting as anonymous because I could get fired for this. The company I work for has a very large application running with a very thick client. This legacy application supports 2500 concurrent users. Our Oracle-Java-SOA people can support two hundred concurrent users with twice the hardware. No body will admit they made a five million dollar mistake, so they keep adding servers and software the SOA cluster hump.