Flash vs. Ajax (merits of platforms building 'Buzzword' wordprocessor)(blog.virtub.com)
blog.virtub.com
Flash vs. Ajax (merits of platforms building 'Buzzword' wordprocessor)
http://blog.virtub.com/?p=8
7 comments
My definitions:
Web App: Application developed entirely using open standards, which (aims to) run in any browser, requiring no additional vendor plugins.
Desktop App: Application designed to launch from the user's desktop, without reference to a web browser.
Thick Client: Any desktop app that makes heavy use of the Internet, or any "Web App"-like thing that makes use of non-standard extensions to the browser.
Reasonable people may disagree on this, and the differences are pretty fuzzy, but my distinctions are based upon the development problems I feel each type of approach must address.
Web App: Works on (most any) platform, no installation, but you have to deal with cross-browser issues, and you're limited by the technology of the web (no local FS access, for instance.)
Desktop App: Tied to one architecture (or worry about JVM incompatibilities), installation hassles, but you get an incredibly rich set of capabilities.
Thick Client: If it's a desktop app that talks to the network, you've got all the desktop tradeoffs, plus richer data, plus worries about what happens when the user works offline. If it's a "Web App" using non-standard extensions (Flash, Silverlight) you've got to worry about whether the user has the right version installed, and licensing hassles and/or fees on the server side and/or in the toolchain. You're also constrained by the capabilities of the extensions, but, in practice, development seems easier than for a pure Web App.
I realize that these definitions mean that lots of things (YouTube) people think of as Web Apps aren't (to me, anyway), but I'm okay with that. It seems a crucial distinction that, once you're targeting the Flash client, you're not really solving the same set of (technical) problems as someone targeting a browser.
Web App: Application developed entirely using open standards, which (aims to) run in any browser, requiring no additional vendor plugins.
Desktop App: Application designed to launch from the user's desktop, without reference to a web browser.
Thick Client: Any desktop app that makes heavy use of the Internet, or any "Web App"-like thing that makes use of non-standard extensions to the browser.
Reasonable people may disagree on this, and the differences are pretty fuzzy, but my distinctions are based upon the development problems I feel each type of approach must address.
Web App: Works on (most any) platform, no installation, but you have to deal with cross-browser issues, and you're limited by the technology of the web (no local FS access, for instance.)
Desktop App: Tied to one architecture (or worry about JVM incompatibilities), installation hassles, but you get an incredibly rich set of capabilities.
Thick Client: If it's a desktop app that talks to the network, you've got all the desktop tradeoffs, plus richer data, plus worries about what happens when the user works offline. If it's a "Web App" using non-standard extensions (Flash, Silverlight) you've got to worry about whether the user has the right version installed, and licensing hassles and/or fees on the server side and/or in the toolchain. You're also constrained by the capabilities of the extensions, but, in practice, development seems easier than for a pure Web App.
I realize that these definitions mean that lots of things (YouTube) people think of as Web Apps aren't (to me, anyway), but I'm okay with that. It seems a crucial distinction that, once you're targeting the Flash client, you're not really solving the same set of (technical) problems as someone targeting a browser.
Are any of you working on Flex/Apollo UI startups? I have to admit, the demo I saw of Flex/Apollo at the Salesforce developers conference was really impressive. However, my partner isn't convinced that going with a particular company's solution is the way to go, so we are sticking with javascript for our UI for now.
Your choice #1 must always be javascript. Why lock yourself to Adobe? I can state a very good example.
One of the most widely used components in flash is the webservice component. An app i built in flash depends entirely on this component. But when the latest version of Flash, Flash cs3 came out, there is no webservice component in it! To rewrite my app in Actionscript 3, i must rebuild my app in Flash cs3. Now that this component in not included, its impossible to update my app.[This component is available in Flex, and Adobe can port that component to flash CS3 in no time. They are not doing it for obvious business reason]
Bottomline is,building your business on top of any closed system is a bad idea.
[Side note: Flex is not a big thing as Adobe markets it. Its Flash itself, but built to attract Java developers (developers who come from a background where Flash's timeline concept is unheard of). Flex need to be used ONLY if you cant find a decent actionscript developer. This is because, the only thing Flex does is to provide the developer with a lot of pre cooked UI elements.But by doing so, you will end up using a lot of unwanted code resulting in bloated file size.Do you really want to build a business on top of a very generalized component set? Reducing file size 300k to 10 k is good for you.Hire a decent local actionscript programmer if you have to go with Flash.]
One of the most widely used components in flash is the webservice component. An app i built in flash depends entirely on this component. But when the latest version of Flash, Flash cs3 came out, there is no webservice component in it! To rewrite my app in Actionscript 3, i must rebuild my app in Flash cs3. Now that this component in not included, its impossible to update my app.[This component is available in Flex, and Adobe can port that component to flash CS3 in no time. They are not doing it for obvious business reason]
Bottomline is,building your business on top of any closed system is a bad idea.
[Side note: Flex is not a big thing as Adobe markets it. Its Flash itself, but built to attract Java developers (developers who come from a background where Flash's timeline concept is unheard of). Flex need to be used ONLY if you cant find a decent actionscript developer. This is because, the only thing Flex does is to provide the developer with a lot of pre cooked UI elements.But by doing so, you will end up using a lot of unwanted code resulting in bloated file size.Do you really want to build a business on top of a very generalized component set? Reducing file size 300k to 10 k is good for you.Hire a decent local actionscript programmer if you have to go with Flash.]
Yes, we are using Flex in our application. It is pretty easy and quick to develop in Flex and their builder is worth all the money. Action script is very similar to java script so it is easy to pick up. I huge pro is that you don't need to worry about browse compatibility. Also a few extra good things are that the sdk is going to be open source and that mainstream websites already make use of it (for example yahoo maps and messenger are in flex). I recommend to at least try it before you turn your back on it.
I don't get the flash decision.
Lots of "wow cool" flashy transitions etc, but who cares about them when you want to write a quick document quickly on the web.
For that matter who cares about whether it will match exactly when you print it?
All I want is a fast, quick, editor that interoperates with other things easily (eg with a javascript/ajax ui, you can resize the font from the browser etc... not so with flash).
I am looking into using Flex for my next webapp
Seems to me the difference between "web app" and "desktop app" is getting more and more fuzzy. Is it a web app because it's written in Flash? Is it a web app because it (presumably) doesn't store anything on your machine?
Given that desktop apps these days often interact heavily with data from the web (Google Earth, for instance), what exactly is the definition of "web app" now?