I would probably be much more of a user interface (UI) guy if the tools didn't cause me to tear out handfuls of my now-precious thinning hair. Every single time I try to find a new and better way to do UI I run into everything from edge cases that the language designers didn't think were important, to downright bad design.
For quite awhile I've felt that programming Flash with Flex was going to be the good solution, because they started from scratch to specifically solve the UI problem, and "adapted" to the browser via a virtual machine (VM). Through one of my conferences, I knew about Flex before Adobe bought the company that created the technology, and it always seemed promising. For a time I was even writing and speaking about Flex.
Now that I examine my feelings a bit more deeply, I realize that my intuition was telling me, "Yes, but." As in, "But it's not going to work out in the long term." (My intuition is very mysterious and there's no logic to how it knows things. If there was logic, I guess I wouldn't need intuition).
This is not the fault of Flex, but rather an accumulation of occurrences (things like those I try to puzzle through in Reinventing Business). Of course a big change happened when Flash didn't keep up with handheld devices and it became clear that Flash was a drain on batteries (if we'd gotten better battery technology then things might have gone a different way, but even then manufacturers would probably just have made smaller devices. On handhelds, code efficiency is going to be an issue for a long time). Worse, Steve Jobs declared "no Flash on iOS." It's hard to ignore the direction of Apple these days. I know that Adobe is working on a solution for this, translating Flex into some kind of HTML5; perhaps this will pull the fat out of the fire but that remains to be seen.
Friends have been reporting stability issues with Flash. I've had it lock up the Chrome browser a couple of times. Basic quality control issues on such a (relatively) old (and essential) piece of software is a troubling development.
One of the big nails in the coffin for me happened when Adobe decided to drop support for Flex on Linux. It's not just the fact that they've backed away from a promise, it's the deeper implication: it means that bean counters rather than technologists are setting the goals for a technology company, and that has never turned out well.
I still do like Flex and see it as a solution when you can control where it's being used, but if I was trying to build a general-purpose application that had the remotest chance of being used on handhelds (and these days, when is that not a possibility?) I'd have to use HTML5.
I do notice Adobe seems to be branching out; there's now a FlashBuilder 4.5 for PHP, although I have no idea what it even means to build Flash for PHP, unless it creates the front end as Flash and automatically connects it to a PHP back end and writes the necessary communication code for you. And FlashBuilder 4.5 is supposed to create apps that run on Flash-hostile handhelds like iOS, so all might not be lost in the Flash world.
I'd sure love to see Adobe use its formidable talents to create the ultimate HTML5 development environment. With their ability and reputation for tools, they could charge well for it and make a lot of money (after this article was written, Adobe announced an HTML5 tool for animation). I'm not holding my breath, but I'd strongly suggest they consider it. (The only recommendation I've gotten so far for an HTML5 IDE is Aptana so I don't yet know this space very well).
I recently came across the lecture
Closures appear to be the most misunderstood language feature I've ever seen. I cannot count the number of times I've seen writers equate closures to anonymous functions. This confused me for the longest time when I was trying to figure them out, and the propagation of this idea has confused many others as well (I suspect that a huge number of people in the Java community have been actually asking for anonymous functions when they've been saying closures).
Closure means that a block of code "closes over" variables defined outside that block. More importantly, those variables persist even after they would ordinarily have gone out of scope and disappeared. The closure captures and retains surrounding variables.
One thing that's very frustrating is how long we've been doing this, and how many opportunities that the various committees have had to try to fix things. I'm going to guess that there's been too much at stake and pressures from corporations have prevented anything useful from happening.
I don't know who to blame for the way that this has all happened. W3C, I suppose. It doesn't really matter. I can't imagine how we've managed to collect and save all these worst-possible decisions, but it looks like we're totally stuck with this mass of mess.
Really, after all this time there's no way to include standard headers and footers on a web page? And CSS -- who thought that was a good idea? (They couldn't even make a uniformly-adopted standard). It doesn't seem like complaining is going to do any good, either. These standards, as far as I can tell, are created in some kind of weird vacuum.
The other layer of abstraction we need is a pluggable DOM. Again, this would allow much better DOMs to replace the crippled one that we must cope with now. Both the VM and pluggable DOM would be tricky to design and implement because of both backward compatibility and the need for cooperation within a single page. But it's important, because the browser is arguably the single most important piece of software in the world -- it's becoming the OS for the user -- and this problem needs to be solved.
I'm wondering why you've cut Java applets out of the running. If it's because Swing is inferior to Flex (I have very little experience with either, myself), then have you looked at JavaFX 2.0 yet? It's being touted as -- among other things -- an easier-to-develop-with revamp of Swing.
All things being equal, there are lots of advantages to using Java on the client side, such as seamless use of the same classes on client and server and the advantages of the language itself over JS and AS, so I figure the problem has to be either the current GUI frameworks, the seamlessness of Java Web Start, accidental problems with integration of the JVM into various browsers or essential problems with the model of the integration.
I'm not lobbying, mind you, but it seems like a matter that should be investigated.
- You say "The syntax of the language varied across browsers!" but this has never been the case to a serious degree. There are small syntactical variations (many of which are now gone since the release of IE 9) but these are not typically apparent to a novice. You're probably referring to differences in browsers' document object model (DOM), which is not the same thing.
In conclusion, I agree with you that there are certainly problems with the Web as a platform but your post does nothing to improve the situation.
I would like to see something like the Mono CLR as a replacement for the JS engines. Then we would have the freedom to choose and even reuse code or libs no matter which language they are programmed in.
BTW, Firefox already supports array comprehensions and generators, much like Python's (and not by coincidence!)
Do take a look at CoffeeScript, because it is quite pleasant.
I meant to say that Ajax libraries improve the experience of programming and in that way are like programming in another language. I look forward to experiencing the improvements once I can begin to understand which libraries are necessary and/or best.
It does seem like there has been lack of leadership in the committees, and some things like CSS seem to have been created in a vacuum. I do think the whole thing is a huge mess. The thought experiment is this: If we were to start from scratch, knowing what we know now, how different would the system and languages look? Of course this is impossible but it's a valuable metric to see how far we've diverged. I'd say that some things would look very similar but some things would be completely different.
This post was really meant as an an eyes-wide-open evaluation. The promise of HTML5 is a great improvement over what we've had, but there is remarkable suckage left in our tools. A significant portion of programmer time is going to be lost in navigating the suckage rather than being productive.
And yet, we seem to have no alternative. Flash looks to be veering off track, and maybe it will recover (but these things have a bad history -- by the time we the public can see the results, the underlying machinations have been broken for awhile and are typically encrusted in the organizational structure). Java Applets have long ago been relegated to the scrap heap, mostly because Sun never fixed the user experience. Admittedly, I only keep up on Java developments these days by listening to the Java Posse news during my infrequent long drives, but I was surprised to see that Oracle seems to have re-committed to Java FX (see http://javafx.com/roadmap/) so who knows what possibilities that might eventually produce. However, that still requires a VM and so cannot run on iOS devices.
So to me, right now, it looks like HTML5 is the horse to bet on to reach the largest number of devices. It will require a fair investment of time to learn how to avoid the hassles, and significant extra effort when programming. It also requires you to insist that the users upgrade their browsers to HTML5 which might not always be feasible (I've heard of some amazing libraries that fall back when older browsers are used). But I don't see any alternative right now.
Bruce - by "Ajax libraries" do you mean jQuery, Dojo, ExtJS?
Dojo and ExtJS are application frameworks with their own libraries for DOM manipulation and Ajax operations.
Programming with jQuery is indeed somewhat akin to programming in another language.
Well, in my experience, the language chosen is most often the result of FOTM considerations of The Suits. If "best tool" were the criteria, far more SQL would be used. As it is, client code (in various source) is used far more than is warranted.
Flat View: This topic has 29 replies
on 2 pages