This question has a discussion of progressive enhancement. My question is about the alternative type of web application. If you have a web app in which the UI is constructed almost entirely in Javascript, won't gracefully degrade, has a desktop feel, etc., what is that kind of web application called?
Do you mean this type or the opposite of this type:
"Rich Internet Application" where you could have an application that runs on for example AIR.
to me, what you describe seems to be a JavaScript based fat client ... i see nothing wrong in that ...
the thing is, that everyone forgets is that HTML means hypertext markup language ... it is a format for describing documents and was never designed to capture the functionality that some HTML-based apps offer nowadays ...
the answer "RIA" seems the best to me ... of course that includes flash and silverlight ... but your choice of HTML+JS is completely arbitrary in this case, because you manipulate the HTML DocumentObjectModel with JavaScript as a flash developer would manipulate the flash DisplayObjectModel with ActionScript ...
there are simply web apps, that are document and form based ... they have a CRUD infrastructure for some type of data, that is accessed in a RESTful, or at least RESTish way ... this type of apps can employ progressive enhancement, using HTML to capture its semantics and plain HTTP for all client<->server communication... i'd tend to simply call this kind of web app a web site ... having a bit of funky AJAX won't change that really ... i mean, from a simple guest book, to a forum, to stackoverflow, the basic idea never changes ... and a guest book does not make a web application, does it?
there are web apps, where the state is fully maintained by a much richer client, because these apps do a lot of granular data manipulation, as opposed to the document based CRUD web apps, and to me, this is the type of web application actually deserving the name, but i'd call them RIAs, to emphasize the difference ... in some cases this solution is faster, more lightweight, scalable, usable, easier and faster to develop/maintain/extend, and simply more natural ... this choice is often based on the type of data they deal with, as well as the functionality exposed for manipulating that data ... for example, if you were to implement a game like tetris, progressive enhancement wouldn't be the way to go ... instead, in order to create such apps, willful misuse of HTML is required ... so what? :-D
so, yeah, RIA is the right word, i'd say ... and opposed to others, i think first of all, it is a great, easy and powerful way of deploying functionality ... i mean i get the whole "inaccessible" and "incrawlable" thing ... but the latter is often pointless, and the first one is a problem you can't address properly, unless for example screen readers read whatever is in the DOM, instead of spitting out the original page ... but that's the problem you face with "real", i.e. desktop like, apps ...
greetz
back2dos
Monolithic?
Well, really the opposite of "progressive enhancement" is "graceful degradation", even though they basically achieve the same thing.
Progressive enhancement means you start off with plain old HTML for older browsers, then enhance it in stages, with cross-browser CSS, additional CSS (e.g. CSS3 styles), Javascript and AJAX.
Graceful degradation means you rush headlong into creating a Rich Internet Experience, then tack on alternatives for people without Javascript/CSS.
Anyway to answer your question, I'd probably call it "ungraceful degradation". Alternatives:
Badly designed
Uncrawlable (from search engine perspective)
Inaccessible (credit: Chuck)
Inaccessible.
It just doesn't degrade well.
I'm not sure I'd categorise applications as progessively enhanced, because that inferrs that there is some sort of baseline. How far back should an app degrade before it's considered as 'progressively enhanced'?
At a push, I'd say the app is dependant on certain features of the browser - maybe it is 'edge dependant' or 'modern browser only'?
UI is constructed almost entirely in Javascript, won't gracefully degrade
Arrogant. Presumptive. Illegal (depending on specifics of application and jurisdiction).
Related
In most desktop web applications I've ever worked on you need a server-side web framework. The server-side web framework (Struts, Spring MVC, etc) has some kind of controller for processing requests and then a templating engine (Velocity, JSP, etc) for generating dynamic content.
Now I am starting to work on mobile web applications and all the discussions I see revolve around selecting a UI framework (jQuery Mobile, jQTouch, Sencha Touch, etc) but I don't see any discussion of what is happening on the server-side to actually process HTTP requests or to generate the HTML, CSS, and JavaScript.
Does this mean that most mobile web applications do not use a server-side web framework... meaning the server serves static content, the majority of the interactive behavior is coded in JavaScript, and the only server-side code is REST services that the JavaScript client loads?
If I wanted to use a server-side web framework would that be a bad idea? What problems would I face? Does anyone have a recommendation on web framework that would be a productive platform and not "get in the way" of mobile UI frameworks like jQuery mobile?
NOTE: The developers I work with mostly come from enterprise Java backgrounds, however, I wouldn't limit it to only Java-based web framoworks. There are other frameworks out there that have roots in Java that could be considered (Grails, Lift, etc).
A good question for sure and I will answer it this way. The current trend is to build a lot of interactivity into the front end. There are several reasons for this. Some do it because it's the new thing to do, others do it because they're trying to replicate the desktop experience. In the end, there is only one goal for any given web project and that is to create Best and Most Sustainable User Experience.
That being said, there would be server side technologies to avoid and that would be any of that generate the front end for you but are not using jQuery. Over 45% of all websites today use jQuery and if you select something else, you will be instantly at odds with the prevailing mobile frameworks. (GWT, IceFaces, I'm looking at you).
Probably the safest and most flexible way to go would either be using a Spring based implementation or Prime Faces. Spring Mobile is worth looking at. Prime Faces actually implements jQuery Mobile and is theme-able using Theme Roller.
In general, it really doesn't matter what backend framework (if any) that you use so long as you're pushing good markup. The browser doesn't care and the only thing that user's care about is a good experience. So, pick whatever will make your devs happy for the backend so long as it doesn't get in the way.
As for front end frameworks, yes, their popularity is increasing because they do tend to standardize some of the best practices in mobile. There are many many comparisons of jQuery Mobile vs Sencha vs jQTouch. I'll leave you to figure which is best for your project but would certainly use either jQuery Mobile or Sencha because the community of support around these is massive and you're less likely to look like the many shabby, home-grown mobile sites that tried to do it from scratch when they didn't have the experience to pull it off. It's just sad. My personal recommendation is jQuery Mobile because it's covers such a wide range of devices and (provided you stick to the standard page-by-page model) will degrade gracefully for even the crappiest of feature phones and still be functional but look amazing on smartphones.
To your question of just using a RESTful design with JavaScript loading everything and managing state. There are many that are doing that and it's certainly a snappy experience but you'll be instantly limiting who can use it to people who's mobile browsers support good JavaScript. You'll be looking at only supporting iOS, Android 2.2+, BlackBerry 6+, and Windows Phone 7+. All others will likely have significant difficulty viewing your site. Carefully consider your audience before moving to an implementation like that. If your site wont work without JavaScript and your primary clients are in the corporate world... what happens when the latest Black Hat conference exposes a weakness in the company phones and out of conservative risk mitigation (paranoia), they push a security policy to everyone's phones that disables JavaScript. This kind of thing happens all the time. So, consider your audience.
Take a look to ItsNat, ItsNat invites you to think in client JavaScript but coding in Java and executed in server generating the same JS code to the client.
The difference with GWT is, Java W3C DOM code is executed in server and JS is automatically generated, meanwhile GWT is executed in client, server data must transported to client.
I want to make a site from scratch, and Im considering to use Flex to make a R.I.A instead of the standard approach (xhtml + css + some ajax).
The kind of site I want to make is something like e-bay, but less complicated.
But.. I know that 95%+ of the sites like that are built in the previous mentioned techs... so, what are the cons and pros if I want to make a pure Flex site?
Thx.
If you write an entire website in Flash, the entire website lives at one URL. (Short of mucking around with whatever Flash provides to let you offer deeper links.)
Whereas a website written in HTML, unless you go mad with your AJAX, lets people link to the stuff they’re actually interested in, like unicorns:
http://cgi.ebay.co.uk/DESPICABLE-ME-AGNES-Unicorn-Doll-Plush-Character-Doll-/180602861597?pt=LH_DefaultDomain_0&hash=item2a0cc4f81d#ht_1755wt_907
Or for a non-eBay example, Stack Overflow questions:
Flash for business web applications - why not?
HTML also has a pretty standard and understood user interface: links, and form controls. (Mainly links.)
Flash doesn't work on iPhone/iPad. End of story.
Other reasons: not a web standard, often quite slow, not good for SEO, etc.
It requires users to have a proprietary plugin which some users don't want and other users can't have (since isn't available for all platforms (iOS being a key example)).
It also has performance and stability issues on some platforms (OS X and Linux being prime candidates).
While some search engines have started to index Flash content (so long as it exposes the information), the results aren't as good as for content rich HTML sites.
You can do that simply using traditional xhtml + css + jQuery (or any JS framework if you want to increase UX). Flex won't do much in your scenario.
In my experience, performance is not a real issue unless you play video - one can write bad programs in JavaScript, too...
Your pros are mostly on the development side: You can have a great looking site quickly, and you can almost completely forget about browser incompatibilites.
You rely on the customers having the plugin installed, though, and you rely on Adobe's technology for development and playing of the content.
If this is not important to you, and you can afford to do without all iPhone and iPad users, accessibility and standards compliance... go for it!
Flex is good if you want to install as an application using Air. ebay actually has a RIA version, or at least they did for a while.
There are several concerns with a Flash site, some of which Adobe has addressed in the last couple of years.
One is accessibility. It is more difficult to make a Flash site accessible to the visually impaired, who use screenreaders.
Related, people like to be able to copy and paste content, as well as print. With standard web pages, the developer need do nothing to support this, it just works from the browser. With Flash, you'll have to take care to make your text content selectable, and I'm not sure a user could ever select a section of text + images. I've never done it, but I can only imagine that implementing printing ability in your Flash site would be nightmarish, at best.
Another is linking and addressability. For most sites, you can copy or at least get a link that you can share or save to get back to where you want to be. With Flash, you usually go to a single address and then the rest of of your experience happens inside the Flash "window" and the browser isn't actually navigating any pages. It is far more difficult to implement this ability in a Flash site.
A Flash site is usually very slow to load, especially the first time, and page load times are immeasurably important to a site's success.
Finally, you've perhaps heard the furor over the last couple of years about different vendors supporting or not supporting Flash in their products/devices. An all-flash site would be completely inaccessible on any iPhone or iPad, for example, which do not support Flash at all. Furthermore, some employers do not allow plugins like Flash to be installed on work machines, so you'd eliminate that portion of possible traffic, as well.
Nobody has yet mentioned Silverlight.?
I mostly agree with Jay's answer concerning accessibility, but as a further note would like to add that development in Flex/Flash vs HTML/CSS/JS could be more costly not only in terms of money but also for maintenance. Many Flex/Flash devs typically charge a higher price and their dev tools, which are necessary for compilation, usually aren't free, compared to HTML/CSS/JS devs, who often use freely available text editors.
I'm looking to implement drag & drop in MSIE (must be, a bonus for other browsers, but just "nice to have").
I'm looking at a sort of drawing package - let's say flowcharts for example. The user can drag flowchart elements from a palette and position them in the browser. When complete, I will need to know the type and position of each element, probably some other data too.
Can this be done? If so, what's the most powerful technology to do so? HTML 5? Ajax? JS? Something else?
Short version: I would recommend JQuery UI (A javascript framework), this will make your life easier. As for other components, you are free to stack it up from server-side to client-side components depending on your needs and most of the times depending on your preferences.
[update] The long version: Personally, if I would start a useful website with a back-end, I would use Java as my PL of choice since I'm familiar with it, SQL for my persistence, and make it a Web 2.0 site, like what you want to achieve which is a rich internet application (drag and drop, dynamic content, etc). I would normally make use of Java (JSP, Servlets) but use Grails framework (Groovy, GSP, Groovlets), SQL DB (like MySQL, SqlLite, etc), Ajax, HTML, CSS, Javascript (JQuery as my JS framework). Eclipse would be my IDE to program and integrate all of these components.
Some people would prefer to use Python, others PHP, some .NET, Ruby on Rails, etc. Like what I said, it is very subjective. If you already have a field of expertise, then I suggest you stick with it, but if you are starting from scratch, it's basically a choice of the easiest learning curve for you because different Programming Languages can and will satisfy your needs.
For the front-end you have Flash, Applets / JavaFX, Javascript, etc. The problems with Flash, Applets or other embedded media are 1) heavy on resources 2) compatibility, but the clear advantage is that they are more robust because you can do so much more with these technologies in arguably a smaller amount of time. But if you want to use one of these, you have to seriously think about your target audience e.g. for Flash, iPad and iPhones cannot display them at all (except if you installed the unofficial "frash" which supports a bit of flash content).
I believe what you want to do is highly feasible even if you just use Javascript, and again, I will strongly recommend that you use a framework that can readily satisfy your needs (like drag and drop) so that 1) you'd worry less about cross-browser compatibilities, 2) you won't have to reimplement them and 3) fix many unexpected bugs along the way. But this is the general idea if you are developing a software, if the framework or library already exists, use it (just be extra careful with licensing though but this is another topic) :)
disclaimer: rum + coke = awesome
use javascript, that's all you should need to have drag n drop for elements. for example : http://flowchart.com/demo/
Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.
I have the feeling that Flash-based ( or Silverlight-based) websites are generally frowned upon, except when you are creating games or multimedia-content rich applications. Why this is so?
Flash is infamous for its poor accessibility.
Keyboard navigation does not usually work, and Flash (up until recently) did not have search engine support.
Flash applications does not work in mobile phones and other portable devices.
Flash is not there in the iPhone!!!
Flash is controlled by a single company (Adobe) and so it is not following any well defined standards for the Internet.
The beauty of Internet lies in the fact that you can always view the source code of any website you are in. This way you can use the same programming/design techniques in your website or you can find security flaws in the web application. This is not possible in Flash. In Flash, source code is closed.
The big question is, why should you use Flash "except when you are creating games or multimedia-content rich applications"?
jtyost2 says,
"I would also add that you can't directly link to any content inside of a Flash site, thus breaking one of the major factors that makes the Internet, the Internet, links."
content weight
usability
crawlability of search engine bots
accessibility
ease of use (disputable)
technology encumbrance (added software required to access the site)
security issues (needing to add software comes with issues involved with installing or running that software/player of the content)
[Edit] Why I place usability and ease of use separate is best explained in this link
Usability:
a result – software that is usable;
a process, also called user-centered design, for creating usable software;
a set of techniques, such as contextual observation and usability
testing, used to achieve that result;
or
a philosophy of designing to meet user needs?
Ease of use:
Effective
Efficient
Engaging
Error Tolerant
Easy to Learn
I agree with the comments on that site, but this is all debatable...could be a good stackoverflow question: is usability and ease of use the same? IMO part of usability is ease of use and vice versa, but they are not necessarily the same.
I hope I don't enfuriate the more semantical sensitive with this edit :-)
Interestingly everyone here blasts Flash/Silverlight and you would do well to recognise that this is only one side of the coin.
Flash (and Flex) allow web site designers significantly more flexibility and richer content for their site and this works in a variety of situations - e.g. sites relating to movies, or bands, sites for kids, sites for games etc.
Certainly, there are many reasons to not choose Flash/Flex/Silverlight, but one can do sites just as inaccessible in JavaScript these days. I have previously worked with JavaScript products that have no reasonable usability by blind people, or web crawlers.
Flash penetration (from a biased source to be sure) is 99%+ (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html), which means that those that say "would never visit a Flash site" are in the 1% of the population that do no install Flash, do not watch YouTube or movie trailers online.
So, you need to be mindful of your audience. Certain audiences and situations would definitely be better off with plain HTML pages and a minimum of JavaScript (government websites, programming websites are two areas that spring to mind). Other times it is because the audience are office workers that are not allowed to install Flash in the browsers.
Rich Internet Applications (RIA) is one area where there is a distinct clash/struggle between the Flex/Silverlight and JavaScript/CSS/HTML sides. I've worked with both, and I'm now of the opinion that requiring Flex/Silverlight plug-ins is fairly reasonable, though you can still lose some visitors if the application is public.
In summary - you're best to identify your audience, identify what they're willing/able to use and then based on such limitations decide on your technology.
Flash and Silverlight based sites typically go against basic Internet conventions with their closed models.
For example, most Flash & Silverlight based sites:
Ignore the back/fwd button.
Don't allow you to send anyone a URL to a specific place on the site, or bookmark a specific spot for later via your browser
Place the internet in a fixed size box. No dynamic sizing for wider monitors or higher resolutions.
"I was about to click checkout but I wanted to change something so I hit the back button"
In this next rant s/Flash/Flash or Silverlight/g
The Flash application/plugin is a closed source pot of serious undisclosed security holes that expose private data, allow modification of arbitrary files on your hard disk, etc.
Flash files are enormous for basic content. There are more efficient ways of doing things
Flash is slow. The plugin on my Windows PC can hog 100% of the CPU time to play some shitty websites.
Flash is non-standard. There isn't a supported flash plugin installed everywhere. Linux users can't run it without jumping through package management hoops. Firefox users on Windows don't get it by default (well didn't last I checked).
Flash is annoying; your users don't want to be bombarded by animations and jingles and junk just to get some basic information.
No back/forward functions unless the Flash designer wanted to implement them in
Can't view a single page without waiting for all the content/scripts that make up that "page" to load. That's really quite painful if all your user wants is a slice of text and you force the multimedia down their throat.
Most Flash-only sites are really bad; the designers seem more concerned with using all of the features of the flash engine rather than presenting something that's concise and useful to the user.
I am a Flash developer. The firm I work for has no difficulty finding clients who want us to build Flash-based products for them. There is a certain set of applications which it is much easier to develop in Flash than in other environments I have used.
But Flash has its problems. Some above have complained that Flash apps do not include keyboard support. Others say it is because the developers are too lazy to implement it. The truth is that many of the components that come standard with Flash are buggy. At my firm we have had to write our own replacements. One feature that is problematic is keyboard support. I implemented my own support for keyboard interaction. It works well, but required effort. If I were writing a Windows VB app, the keyboard navigation would be provided and would work well out of the box.
The same is true for deep-linking, back-button support, etc. A clever developer will be able to make a Flash app behave well. Some open source libraries are indispensable here.
As for flowing layouts, I just completed a proof-of-concept for this (in AS3) as well. It is possible, but requires much effort. Why do I make the effort? Because of the other things that Flash does well.
My biggest gripe with Flash is that it takes you "out of the browser" into its own totally separate application. This breaks "browser standards" - i.e. the functions I can do in my browser:
Right click
Middle click (for opening links in other tabs)
Selecting text
Copy & paste
Printing
Keyboard shortcuts (since Flash steals keyboard focus)
Back/Forward buttons and the whole "page" concept
Javascript interaction with other elements on the page (I don't think this is possible).
"Inspect element" in Firebug or Chrome, if I wanted to see the source of a particular part of the Flash file, or find the image being used.
Flash has its uses. It's good for content, not webpages.
Printing is often poorly supported and the backbutton does not work.
I think it's a matter of selecting the lowest cost medium to reach your target audience,
be it Flash or Silverlight or JavaScript or plain text.
You can have text-only, JavaScript-only, etc. versions of your site if you have the
money, and your target audience come with different prioritizes.
So my question to you would be: does your website has people who frown on Flash as its target audience? If yes, you need to stay away from it. If not, use anything to give your
visitors a good experience.
SEO is the prime issue. Still Flash is not crawlable. But Adobe is working on it.http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html for better swf indexing.
Does anybody know a site called YouTube? It wouldn't exist without flash. Flash has great video/multimedia capabilities that simply cannot be ignored.
Flash is amazing when used in the proper way, in appropriate circumstances and when the designer/coder has taken care to embed basic accessibility features.
The thing is, like all good things, there's a lot of abusive use (flashturbation). Especially in the beginning, when people just want to slap Flash wherever they can just to show off.
But I strongly disagree that Flash sites are bad: When made properly, and with good UI design and accessibility, they bring a whole new dimension to the web.
See Steve Jobs' Thoughts on Flash: http://www.apple.com/hotnews/thoughts-on-flash/
Let us not forget that Flash allows web sites to display video, animation, user interaction, etc., and it allows this to be a simple process or a geeky techie one, depending on what you want to do. Many bad Flash sites are down to the author.
If YOU don't like Flash then the answer is simple, don't use it. Don't install the Flash plug-in, or install a browser plug-in such as Flashblock on Firefox. This replaces any Flash movie with a play button, preventing and download until it is clicked.
Better than that though, if you don't like the solution that Adobe or Microsoft are giving you, then come up with a better one, or at least let them know what you don't like, they do take feedback seriously. Support some of the people who campaign for accessibility improvements in Flash, for example visit http://niquimerret.com.
Accessibility is an ongoing issue and not one that will go away, Flash accessibility is improving for people with physical disabilities. In in some cases the use of Flash enhances the experience for people with cognitive and learning disabilities, when an concept or idea is better explained when presented as an animation rather than a page of words and static images.
Flash adds another heavyweight component that's required to properly view a web page. The flash plugins are often buggy and can crash a browser. Flash pages often are used to make cutesy animations and other things that make it harder to quickly navigate a site.
All of the above is true for the wild wild web.
However, for internal business applications, Flash and Silverlight allow the user to have something close to a fully-fledged application in their browser. Accessibility, SEO, and closed source are not very important in an internal application. All that matters is making the user's life easier.
I dislike Flash based websites because what happens if your browser crash or your connection dies for a bit? You have to load it again and go back to the menu, and select the item you wanted to read about, and so on and so forth.
Just don't do it. :S
I don't install Flash on my browsers, mainly to escape the nuisance of animated ads, but also for all the security and privacy reasons mentioned by others.
So sites done completely in Flash are nonexistent as far as I'm concerned. (W.r.t. Youtube, I download videos directly into Miro.)
Probably for the same reason C programmers shied away from Win32 API, Win32 programmers from MFC and MFC programmers from Windows Forms. It's tricky to use and understand - I have tried programming in Flex and am getting along pretty well but it is not inherently designed for typical web application design e.g. there is no native (at least until Flex 3) support for databases or cookies or sessions - you need to put all 3 in PHP or another server-side page and call that from ActionScript.
Try making a simple register/login page with PHP and then again with Flex/Flash and you will see that all the server side crunching is done by someone else - again, this is probably by design since we have HTML/JavaScript for the front-end mixed with ColdFusion or PHP etc. for back-end in "traditional" web applications.
Like started by other people, Flash is bad with the keyboard - try pressing Ctrl-T in Firefox when a Flash object embedded in an HTML page has focus (mouse-over) - so that can be frustrating for the user...
Having said all that, I would still rather make a web application front-end in Flash/Flex than HTML/JavaScript/CSS since the latter needs a sharp learning curve that gets quite bewildering after a while since you have to account for the "good" design aspects of CSS and JavaScript and the bad ones too - and also the peccadilloes that JavaScript/CSS inherently have and those which are introduced by the JavaScript library vendor (Yahoo's YUI, Google's Ajax API, script.aculo.us, etc.
If you are already a web programmer who knows CSS/HTML/JavaScript very well and have a good development environment set up on your PC with all required code inspectors and runtime debuggers etc. etc. then it's easy to keep on working in that (not taking into account end-user preferences) but if you are like me and want to make a web application ready and available for use quickly and want to add features to it quickly while making it pretty all the time, then Flash/Flex is a better option, IMHO.
I am a Flash developer.. and I have found that although Flash requires more effort in coding, the potential is enormous. You can create very simple sites with simple transitions, so subtle it would seem to be a normal HTML page, while still being just as light.
At the same time, you can use OOP with ActionScript to create a website that is as complex and as inclusive, as well as feels and acts like a desktop application. WHILE ALSO REMAINING VERY LIGHT! (only the content required is loaded on demand, as apposed to 4 column HTML sites with far too much information.)
Nowadays, and this is still without migrating to ActionScript 3, but still using ActionScript 2, MY flash files contain simply 2 or 3 lines of ActionScript, only one frame, and an empty stage. Everything else is dynamically created or added at runtime.
Flash's problems are not about Flash, but about lazy development.
In its defence, most of the issues raised here about how people have implemented Flash in their websites, not about Flash itself. Flash does support accessibility it's just that most people don't consider it when building their sites. Flash does work on mobile phones - it's Flash Lite, although the ActionScript is limited in earlier versions.
Why should anyone have an automatic right to view the source code of a website?
A web author has spent time and effort dreaming up their code to share their ideas through the medium of the web. If you want to know how something works, why not put a bit of effort in yourself, and work it out? The beauty of the web is the message, not the medium.
So what if Flash is owned by a single company - Adobe bought it for a reason, and that's because it's a fantastic bit of kit. The problem comes from web authors not using it properly, trying to make it do things it was never intended to, or simply not applying standards to their sites when developing using Flash.
What is so evil about a Flash based website? Absolutely nothing.
It's like asking what is so evil about a gun. Nothing. It's the idiot wielding it that has the problem.
Flash sucks and I refuse to visit Flash-based web sites. Why? Because I can't. Why? Because Adobe is too ignorant to write a plugin for a 64-bit browser.
Look at any major car maker's website, they are ALL in Flash. It depends on what you are doing. If your goal is to provide a rich, sexy website Flash/Silverlight will give you a huge advantage in terms of development time. IF you are providing content/data HTML and JavaScript (jQuery for example) can give you a lot of whizbang without requiring additional software plug-ins (Flash/Silverlight).
Flash Player is the culprit behind more Mac OS X crashes than anything else. It's not exactly well-known for its stability.
All the above answers are focusing on Flash, Silverlight is just as bad or worse. If you are running Firefox with NoScript (you should be) then you have to click on every script that you wish to allow to run.
So build your websites with scripts, Flash and Silverlight. Just make sure that they still work with them disabled. Many of us will simply move on when we open a site and see nothing.
Many of us have had bad experiences with Flash based websites which has propagated the idea that flash is "evil". I don't really think it's fair to apply the label of evil to any technology or framework, they are each designed to cater to specific scenarios and many of them do well in those scenarios, for example, I have no problem with websites that use flash video.
A few other responses have touched on the fact that the use of flash contradicts many of the standard metaphors we use on the internet (e.g. links and navigation buttons), I hate this as much as the next web user but this doesn't really make flash evil either.
While it has been said that there are mechanisms within Flash/Flex to add support for these things, in my experience these are rarely implemented, which is not directly the fault of Flash per se, but is very annoying for the user.
Perhaps the evil is not Flash/Flex but Adobe for not making many of these things easier or more visible to developers.
For the record I have never developed in Flash
Flash isn't evil, it's what people do with it that's evil.
For goofy vector animations and maybe even for example a 360 product view or interactive diagram, yes. Flash can do beautiful Full HD animation on my ancient box # 60 fps using ~15 % cpu.
For web video, if you have no other choice, I suppose.
But for entire websites and these things called 'RIA's, no.
So shockingly a technology works better for the thing that it was designed to do.
Flash is one more stuff to learn in web development. No thanks!
There are just too many already. If I can do my job without it, I don't need it.
Programming is being paid less every day.