Developers around me have recently begun to look more closely at the fuzzy area where one should choose HTML/CSS/JS over Flash for rich browser content. Unfortunately, conversations on the topic have a tendency to get derailed almost immediately because features like Canvas, and even the whole JavaScript language, get dismissed entirely by a vocal few. When that happens, everyone heads off on a tangent to argue a couple points, and then the conversation pretty much ends. Without a clear winner, the dismissal becomes the defacto conclusion and further exploration within the group is halted, at least temporarily.
We’re all aware that certain options may be technically or aesthetically inferior. Yet, we can’t improve the situation without getting our hands dirty. Rather than preach to the choir, we should be providing clear, visible evidence of where web standards (or implementations of the standards) need improvement. We should be creating publicly visible works that push the limits of the browser as it exists today, even if doing so requires the nastiest of workarounds. In fact, finding those workarounds should be a priority because I want us to be able to point to them and say, “Hey browser vendors: I made this, and users love it, but check out this code that’s going to make you want to puke (or this overworked CPU, or excessive memory, or whatever). You need to fix that.” By showing truly compelling projects that can hit barriers and raise awareness of web development pain points that anyone can see, I think we’ll find that browser vendors can be far more agile than some people assume.
The open web community has been calling out Flash for many years, whether their arguments were accurate or not. Now that they’ve “won” for certain use-cases, I think that it’s time for the tables to turn, but in a more productive way. Targeted and actionable feedback, measurable data, along with impressive content will do much more to improve the web than complaining that we miss the good old days. Our jobs may not be as fun at first, but wouldn’t you rather make it better sooner than later?
Great news guys: I just added strong typing to JavaScript, and all the browser developers are implementing it next week. And — AND — I convinced them to force everyone in the world to update to the latest version of their browser. We should be good to go by Friday.
Ka-ching!
We were recently involved in the development of a campaign site, which started out as a flash site. However, once the site was completed, the customer decided they wanted it to work on mobile too. Here, of course, flash is a problem, so we ended up re-programming the site in HTML/CSS/Javascript. To make things somewhat reasonable and predictable, we decided to target webkit browsers only, which actually worked out quite well. You can see the flash version here:
http://krafter.unionen.se/
and the mobile/html version here:
http://krafter.unionen.se/mobile/
Ironically, thd mobile version ended up being about 10x in size (kB) compared to the flash version. This is mainly due to the need to use PNGs, and the large number of separate files (web fonts, javascript libraries and such). But in the end, it all worked out rather well, I’d say, at least when viewed on modern versions of iPhone/iPad/Android.
Some tools that would allow a HTML version to be “exported” from a flash version would of course be ideal here, but probably not easy to do. So in this case, each version is hand-coded separately.
-JM
Thank you, Karl, for showing us a perfect example of the sort of dismissive behavior that I described above.
I think the tide will turn back to hybrid websites. Simply because of the job loss aspect for html programmers. I would rather hire an ex html turned flash guru that now needs to kick ass in html 5 and when js grows up ends up like as3 or java, then hire an html guy that will not cope with what’s coming. Oops did we make a mistake pushing for them web standards ? 😉
You know what we should do? Since JavaScript is so week structured to create complex software comparing to ActionScript, we should call ActionScript JavaScript II and make a standard out of it and allow browsers to implement it.
No need to wait for browsers to implement your language of choice, Mitnick. The early successes of CoffeeScript show that you don’t need to write JavaScript if you don’t want to.
Josh, that was a joke – browser vendors won’t do this in a hundred of years unless w3c tells them to. Actionscript will stay for games and where better speed is required. CoffeeScript isn’t a real language. I Really do not like those languages what does some kind of magic for you and requires abstraction of what is actually going on under the hood. Flash is moving in the right direction allowing users to compile C++ code and upload code directly to GPU for execution.
I’m aware of the ECMAScript origins of AS3; I got the joke. I felt it still deserved a legitimate response.
What’s the difference between CoffeeScript or AS3 compiling down to JS and AS3 compiling to bytecode? Arguably, its the same sort of abstraction.
While coding in AS you use strong datatyping, vectors, work closely with garbage collector and use other things that makes you think more what is the end result for processor and what is going on in memory segments. All Actionscript is compiled down into bytecode and bytecode is then represented on virtual machine that is running on the users computer no matter what architecture he has, but Actionscript is not limited to just generated byte code from Actionscript OOP classes. In latest projects for bits that needed extra boost and will be executed many times I coded in C++ and compiled out SWC files, and tied them together with my resulting SWF, what gave me excellent performance on places I really needed it. Adobe is working now on Alchemy2 – IDE that will facilitate this approach more. For faster rendering on graphical data you now have Stage3D which allows you actually define the code in AGAL format, that is very low and can be uploaded directly to GPU for processing and showing the results directly to screen on windows using DirectX, and on MAC and Linux OpenGL. Next year beginning also available on mobile devices in AIR applications.
Okay, so now we’re on another tangent about why Flash is better, argued among people who already know all these facts. If we can’t use Flash for a project because a client doesn’t want it, or because we need to target platforms that don’t support it, then any superior capabilities that Flash provides won’t matter at all. This leads me again to ask, how do we encourage browser vendors to improve their products?
I think the sad truth of the matter is, browser vendors have proven historically that they value their point in political games be them standards, media formats, open / non-open source solutions, different rendering engines, different JS engines and different CSS formats regardless of longstanding standards way more than they value our time as developers for their users.
The most optimal solution regarding time to market and guarantee of success, though it disappoints me to say it, would be start developing a open plugin that supports the types of benefits Mitnick describes using formats and proven technologies that are already unproprietized and open, ie: AS3 (or any other appropriate language), SVG, etc. to fill in where their creators will not, or as you suggest, fight the battle to convince the browsers to do it for us.
It sickens me that it is coming to this all over again because of political BS regarding Flash / Flex, HTML 5, CSS 3, JS from corporate slap fights, uneducated buzz-word driven blind fanatics, and worst, developers unwilling to look at every language / technology if for nothing else to identify and understand the merits and build a better environment for us all. We need to start by reminding ourselves that we are where we are today mostly for that fact…we allow this constant feeling of “almost there” unifying technologies with no end because we can’t accept where they came from or why they started succeeding in the first place and so pit them against each other in arguments that only we and our users only lose from. We allow biases in ourselves that directly compete with the very passion for elegance, problem solving, and analytical thinking that our field of science demands of us (and yes, I count web development as part of Computer Science).
With this in mind, how can anyone claim JS was designed for any of the demands we ask of it today, not just in compilation, but as a language? ActionScript as a further implementation of the ECMAScript standard that at least stands in for JS in relative similarity while offering amazing flexibility as a language. If it didn’t have Adobe’s name on it, which it isn’t proprietized at all btw, or come from flash, do you think anyone would really have a problem liking it?
And is the diffused, fragmented environment that web browser vendors create and continue to encourage the same group of hands we want holding that future? I can’t bring myself to ask that of them when they can’t handle a single W3C standard to this day in completeness at even roughly a similar timeline, and this is completely ignoring the disaster they have made of CSS and JS. Even the ECMAScript standard itself became a political battlefield of corporate ownership and disagreements about what is best for the vendors as opposed to the best solution.
I felt this way long before the recent announcements from Adobe. We are so far behind where we should be because we didn’t make this realization long before Macromedia did all this work for us, actively leaving all of their formats and languages un-proprietized for us to build upon and take over at will. MS and Apple were never willing to step up to the plate with that. Now, I’m not sure our own community is willing to take a hard look and realize that shoving this all into JS / HTML / CSS is the poor move, as opposed to bringing AS3 and many other great technologies, regardless of their source into the standards fold.
Thanks for inspiring a thought-out conversation and I hope this comment is clear that my intention is to participate in that, albeit I am pointing out that I feel your post dismisses many options, only some of which I described.
Cheers.
The idea of an open plugin is a noble one, but it would face a steep hill to adoption. Unless operating system vendors would install it by default, like they did with Flash Player for many years, it would end up being about as effective as Chrome Frame (another noble idea that hasn’t gotten very far). I don’t want to dismiss it, but I also think many web developers would be opposed to a plugin approach, even if it wasn’t proprietary.
If you’re still following the comments here, Mike, I’m curious to know what else you think I’m dismissing that you didn’t cover. I think it’s more that I’m advocating one specific option, and I didn’t spend time comparing it with alternatives.
today, web development sucks, see this: http://harry.me/2011/01/27/today-web-development-sucks/
the web needs a common bytecode and PNaCl + LLVM is the best option. i recommend reading the comments (like the one from ant57) here: http://news.ycombinator.com/item?id=2057415
i’ve tried the html/js/css combo with various frameworks. no question, it’s a kludge of crap. beyond writing a simple webpage, i couldn’t see myself as an html5 dev and enjoying my job.
but as a former flash/flex dev, i was at a crossroads. for my future, i’ve chose to write native iOS apps as an alternative to html5 web apps. go native or go home.