As a longtime desktop developer looking at doing our first large-scale web application, what are the pros and cons of doing web development?

Is developing a web application much worse than developing a desktop app? E.g., is it more tedious or annoying? Is the time to market much worse? Is the web platform excessively limiting? If the answer to any of these is yes, then why?

(And how does developing a Flash or Silverlight app compare?)

  • 5
    I haven't voted to close but I think it might be more constructive if it could be re-purposed into a web development vs. desktop development standpoint. – Josh K Nov 9 '10 at 18:42
  • K: Okay, I tried to rephrase the question without invalidating existing answers. Thanks. – Josh Kelley Nov 10 '10 at 13:14


It's painful if you don't know what you're doing or don't plan correctly, but that's true with any development. It is easier to bottle the application in a desktop application, but then you lose the accessibility that is provided by coding for a web application.

I would make the choice between desktop and web based on the desired use. I see many applications written web based that shouldn't be because they don't know how to code desktop applications. I don't see many desktop applications that should be web based though, and I think that's something to consider. If you need the centralized storage, remote accessibility, and UI traits then sure.

I can't comment of Flash or Silverlight because I use neither.

  • 5
    I hate to be that guy but... :s/loose/lose/ :) – dr Hannibal Lecter Nov 9 '10 at 19:51
  • @dr Hannibal: Fixed it. Sometimes I double tap the keys. ;) – Josh K Nov 9 '10 at 20:00
  • 4
    @dr Hannibal: There's such a cognitive dissonance that comes from the words "I hate to be that guy" coming from "Hannibal Lecter" :) – Skilldrick Dec 16 '10 at 18:53

As mentioned by others, it's a matter of trade-offs and of having the right knowledge.

The only pitfall you might want to consider is this: you mention in your question that you see the web as having "cross-platform" as an advantage. But does it really? Think of it this way: if you develop something for the desktop, you need to define the list of platforms and their requirements to support.

Make no mistake, it's the same for the web. And even though it's already tremendously simpler than it used to be, if you design a wide public app, you're going to have to deal with every possible version of every web browser out there. And if it's more of an enterprise app, then brace yourself and prepare to draft your supported browser platforms requirements very precisely.

Don't think you'll avoid to have platform-specific hacks here and there if you build something significant.

And then the fun parts. What is best? Browsers that update themselves almost transparently very regularly like Chrome? Or the ones that roll-out security updates only monthly and major features every stone age (like IE)? The answer is not as obvious as you might think, because some of these frequent "transparent" updates might break your code, and you will need to follow this and react promptly. Or keep an eye on beta and dev pre-releases while developing and testing. For all of the browsers you foolishly said you wanted to support (good luck).

Oh and let's not forget UI considerations. You also face the joy of deciding whether you want a consistent UI ACROSS all your target platforms, or a consistent UI WITH each host's target platform. See all those little buttons you can view on web-pages? Do you want them to be exactly the same everywhere, or to integrate with the environment used by your user? Of course this problem isn't new and existed for other development models, but it seems to be more important here, and depends on the type of users you target and what they expect. Public end-user would tend to want you to integrate with their platform - but will still want you to "wow!" them with fancy stuff - while the enterprise user will want something that looks like a desktop app. And mobile platforms had a new dimension to all this.

For the last 2 paragraphs, a common idea is sometimes to package a pre-configured web-browser with your installer, which then connects to your web-app (locally hosted or on the web). It's great because you control the update frequency and you can "freeze" the state and you know exactly what to support and test on. Plus you can add cool stuff like dedicated user extensions. For instance, packaging a "frozen" Chromium with small Chrome Extensions you've developed to make the use of your web-app easier for different types of users can be extremely nice. On the other hand... you're now responsible if a security breach occurs because you froze the release cycle, and your app won't benefit of speed improvements (if any).

Like many things, it's a double edged ax.

Note: I have a strong bias against the web for being basically a big pile of half-baked technologies (and I am polite here), down to the OSI layers, on which we keep adding layers of crap hiding the problems underneath without really solving or fixing them.

That being said, I am in favor of the web for its ubiquitous nature as a platform. I think your company's move is (probably) the right one. It depends on your target market and the platforms you aim for, obviously. If you want to expose something as a service, then you're probably good to go (though it's not necessary either). If you don't, then maybe there's not so many reasons for it.

Hmm, and expect some fun developments in the future now that more light-weight variants of existing operating systems keep spawning for mobile environments (netbooks, smartphones, PDAs, tablets, eBooks...), with more emphasis on using lightweight embedded browsers... but with all their new share of UI rendering glitches.

Regarding plugin-based technologies... I'd say steer away from them. They will enhance your app's power, but will limit its market penetration. In some cases you will see it as a plus in terms of cross-platform support, until a new platform suddenly refuses to support them. Web Standards are here for a reason (be careful not to get too excited about everything in HTMl5 either, or it might blow up in your face).

EDIT: other things to consider...


It's extremely hard to find knowledgeable web developers. You'd think there's a herd of them, but they're lost in a huge pool of, well, fairly incompetent people who think having managed to write 700 lines of JavaScript/ECMAScript to implement some validation in their forms is the end-all and be-all of what can be achieved in terms of high-level skills.

I'm not kidding, lately my first question for all web-development interviews is how to declare a variable, and then whether there's a different between using var or not (depending on how they answer). It's depressing. I find it a lot more difficult to find an average or advanced web developer than to find an average or advanced desktop developer.


No one will ever consider you seriously when you say "I'm a web developer". It's for a sub-class of programmers, developers, isn't it? The ones you ignore and mock from afar, and don't join when they go get coffee. :)

This is obviously untrue, but it comes down to the fact that you develop for an environment that is mostly managed for you. Browsers correct your screwed up markup, your screwed up styles, and will even correct your screwed scripting for some of them, and optimize it for you if you please. And if you're a web developer, people won't assume you have a clue about lower-level programming, so you must be a complete idiot, right?

And then they realize how crazily complex ECMAScript can be, but will refuse to review their opinion. Because it's web. We don't like it intrinsically, we just like what it enables us to do.

  • -2, +10... I see I fostered some controversy ;) – haylem Nov 9 '10 at 18:48
  • Differences between browsers have become less and less of an issue. Certainly, there's minor inconsistencies in the way they handle CSS and whatnot but for the most part, I've never had a major issue with a modern browser. Unless you're right on the bleeding edge with HTML5, <canvas> and stuff like that... – Dean Harding Nov 9 '10 at 22:33
  • 6
    "Note: I have a strong bias against the web for being basically a big pile of half-baked technologies (and I am polite here), down to the OSI layers, on which we keep adding layers of crap hiding the problems underneath without really solving or fixing them." - ARE YOU ME????? – Bobby Tables Nov 10 '10 at 0:36
  • 2
    I worked with a couple of guys who are real web development gurus, do amazing things, and use it as a serious software development platform. They have my deep respect. But that's only two in the last 15 years. The rest... well, I once got a gig as a Perl "expert" just because my sample code was structured rather than the spaghetti the interviewer was used to; at that time, my genuine Perl expertise could fit in a thimble. – Bob Murphy Nov 10 '10 at 3:17
  • 2
    +1 for ECMAScript being good, bad and called ECMAScript. – Alan Pearce Nov 10 '10 at 9:46

As someone who's dealt with both (more desktop than web though): by far my biggest gripe is the sense of "general clunkiness" in web development. Even with the very best tools and frameworks, the abstractions are still very leaky and you're constantly dealing with the fact that you're running over a stateless protocol.

Another related annoyance is the mix of technologies that's used to implement web apps. There is no nice, monolithic, modular environment and language that everything can be done in. Even relatively simple web apps require you to code things in a handful of separate programming, scripting, and markup languages.

So as a general answer: YES, it really is that bad. At least if you're coming from a traditional desktop background where you're used to coding things in a clean, seamless environment, using a technology and platform where everything is quite linear and well defined. The best way is to just not try to think of it as the same field. If you keep subconsciously expecting web development to be "like desktop development", it'll always look very obnoxious and annoying.

  • 4
    The reason it felt "generally clunky" is perhaps because you were using frameworks that attempted to "abstract" away... what, the web? The web is stateless. No matter how much "webforms" in ASP.NET wants to make you think otherwise, never forget that it's stateless. The quicker a developer accepts that as an unchangeable truth, the quicker they get on to writing quality web applications. – Jason Whitehorn Nov 10 '10 at 1:47
  • 1
    +1, well said. Even with frameworks like Rails which are supposed to be the solution to writing everything in a single tech stack, they manage to screw it up by changing recommended practices from RJS to "Unobtrusive JS". – Jas Nov 10 '10 at 13:20

the biggest re-think going from desktop to web is: the web app is inherently stateless

figure that part out, and you're good.

  • does browser matter? – JeffO Nov 9 '10 at 21:18
  • @Jeff cross-browser inconsistencies are annoying, but not really significant – Steven A. Lowe Nov 9 '10 at 22:05
  • 4
    You have to write for real browsers (some inconsistencies), Internet Explorer (more inconsistencies), and perhaps the devil's child (IE6). – TRiG Nov 10 '10 at 0:29
  • 2
    @Malfist: If you're not careful, with this approach (stateless+sessions=stateful) you could design an emu with an aircraft jet engine bolted on, when you originally wished for an eagle ;) – Piskvor left the building Nov 10 '10 at 21:52
  • 1
    @Jim G: of course it is. But the differences between browsers et al are miniscule compared to going from stateful to stateless applications design. – Steven A. Lowe May 28 '11 at 14:51

Much of the tediousness comes from the work necessary to make everything work in all browsers. Since you do most likely not need be on the bleeding edge you can leverage the work done by others, by choosing a suitable web framework instead of handrolling your own.

Which one to use, strongly depends on what language environment you are currently used to. You may want to edit the question to provide that information.

  • 2
    Browser compatibility issues are a giant pain, it's true, but to balance this out, don't forget that he's comparing to desktop development, where you have to deal with different versions of operating systems, libraries, etc. – Carson63000 Nov 10 '10 at 4:53
  • @Carson, if they do Java desktop development this pain is actually quite minimal. Maybe it is much worse for .NET or Win32 API. – user1249 Nov 10 '10 at 8:44

No, web applications have different trade-offs than desktop applications. Each has their strengths to my mind. While there are strengths like a single deployment, there is the trade-off of knowing which browsers do you support and what screen resolution are you expecting the customer to have? While you do have control over the server hardware there is the question of how much traffic do you expect and how well will it scale? For those that have done web development for years these can be sore spots much like I'd imagine you have some development tasks that you find to be a major pain, no?

A Flash app may or may not be a web application to my mind. Something like AIR can make some Flash stuff run on the desktop now and some applications are built on that,e.g. Twhirl, so it isn't immediately that cut and dry.


Web development isn't necessarily worse, it's just very different.

One of the things that separates web development from desktop development is the plethora of radically different technologies you have to master in order to develop a decently complex application. I mean, you basically need to have a strong knowledge of:

  • HTML
  • Javascript
  • CSS
  • Some server-side language (Java/PHP/whatever...)
  • An RDBMS (or some persistent store technology)
  • ...and possibly many other things like Flash, Silverlight, etc.

Whereas, with desktop development you're usually working with a much more monolithic set of technologies. For example, developing a Java app basically requires you to know Java, and that's it. (Of course, that's somewhat of a simplification, but the point is web development exposes you to a much wider range of radically different technologies that need to work together to form a functioning application.)



As long as you pick the right tools, web development is as clean and easy as desktop development.

The web API's (html, CSS, Javascript and DOM) are the equivalent of the win32 api. Eventually everything talks down to that API level, but you're crazy if you program directly on top of it without a library to abstract the messiness, verbosity and inconsistency away from you.

So, be careful about your choice of frameworks. Some problems are self-inflicted by picking bad tools (e.g. browser compatibility issues).

It is possible to have a clean and consistent web dev platform, with a single language. E.g. if you want it to be "all java all the time", you can use GWT and write both your client-side code and server-side code in Java. Or, if you'd rather have it be all javascript, you can pick something like Ext JS for the client-side and node.js for the server-side.


I've heard it described as "...the bane of my existence" and I would agree. I've been offered $$$ an hour to do HTML web development and I've turned it down. It's that much of a pain. I've spent a majority of time in HTML and recently started working with the "Flash platform". It's one of the most sophisticated frameworks I've ever seen and no one even knows about it. When people bring up Flash they think of Flash as of 10 years ago. It's grown... a lot. I love writing software again.

It still has it's disadvantages. Bugs sometimes linger forever but it's gotten better (thanks Steve J.).

BTW There's a major shortage for Flex developers. I've been approached by so many companies it's sick. If you know your CS, then spend the next 6+ months learning Flex hardcore then call me. I'll pass on all the job offers I have to turn down.

Update: Cross browser support is the main pain point. What works in one browser won't work in another or it will but not in a previous version.

The process goes something like this: - get design of site - attempt to recreate it in one target browser (this can be difficult) - show client - client changes design - scrape all the layout work you originally did - get it functional - client approves - get it to work in other browsers. This is the most difficult part. There are obscure bugs all along the way. Then you'll encounter features that earlier browsers don't support such as rounded corners. You'll try to reuse your code and css but that quickly becomes fragmented. Simply it can become high maintenance very quickly. Add in animations and older browsers choke.

The client will make changes. You'll end up spending all your time doing "what should be simple things" and hate your life. You'll become a guru and know things you don't want to know. I know it sounds dramatic but I'm not embellishing the issues you'll face. Frameworks will make it easier. If you are persistent in working in HTML then to prepare yourself recreate one of your favorite sites in HTML making sure to match the design and functionality in all browsers it supports. Get the issues you encounter out of the way before going into a job. Issues such as best design tools, best javascript frameworks, best debugging tools, best IDEs, etc.

  • Could you edit your answer to explain why you consider it the bane of your existence? – Josh Kelley Nov 10 '10 at 13:17
  • Updated my answer above – 1.21 gigawatts Nov 10 '10 at 21:33
  • 1
    Three bucks an hour? No wonder you turned it down, is that even minimum wage these days? ;) – Piskvor left the building Nov 10 '10 at 22:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.