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?)
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.
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.
<canvas> and stuff like that...
– Dean Harding
Nov 09 '10 at 22:33
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.
the biggest re-think going from desktop to web is: the web app is inherently stateless
figure that part out, and you're good.
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.
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:
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.)
No
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.