The following post is a reprint from my personal blog. It is editorial in nature and even delves into random politics. I apologise. You can deal with it though :)
Steve Jobs didn’t hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out “stupid keys” (print screen, F keys, and the like) and swore a lot.
We love to paint with broad black and white brushes these days don’t we? Whenever I hear people talking about Google being “evil” or not…. I sit back and think about how interesting it is that companies become “people”, especially in this country.
Corporations are recognized by the law to have rights and responsibilities like actual people.
That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn’t a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.
I have been thinking about this ever since the recently surprise court decision the other day that “allows corporations and unions to pour unprecedented amounts of money into elections.”
Lawrence Lessig had some interesting commentary:
The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.
Fun aside
My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on “the mind”.
The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.
Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn’t just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren’t solely based on profit. They want to create a different kind of legacy and company.
That being said, I think it is quite easy to fall into a trap such as:
If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!
Google will sometimes do things that could be considered “evil” by some. That is life.
The good news with Google is that their search and ads business deals in a trust economy. It doesn’t take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.
Not all corporations are profit driven
I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make …. you think of the mission.
It was interesting to work there knowing that I actually wouldn’t want Firefox to be a 90% browser. You can fall into the similar trap as above and think:
We are mission based! If we had that domination we would use it for good!
But, not having that power in one hand is even better. Imagine working somewhere thinking “in my wildest dreams, the market would be shared somewhat evenly with the competition.” The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can’t move as fast as a dictatorship, but there is a reason we don’t want dictatorships in our government (even if the trains run on time!)
And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn’t dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.
I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don’t want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can’t Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.
I don’t want to “kill” these other platforms as they offer competition and spur on the industry. I just don’t want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?
Erm, no.
And thus I find myself torn. I really want to go out and by that iPad……. but when is it “too late”. Surely I have a few years right? I can enjoy the shiny new toy? :)
Do you feel that view source added to the popularity of the Web? or that it was just a nice to have that is neither here nor there? Other technologies have tried to bolt it on (e.g. in Flex you can opt-in to view source) but opt-in to a developer flips a bit of “hmm no I will keep this to myself” for various reasons.
I personally feel like the ability to view source fit in perfectly with the culture of the Web, and was especially important early on. I am willing to bet that we have all learned from the notion of view source.
However, it is also true that in some ways our front ends are getting a lot more complex and by the time you run a compressor through, or a tool like GWT/Cappuccino/insert others there isn’t much to learn. Of course, on the back end all the code is hidden and we have found ways to learn there (big thanks to open source and communities that have sprung up).
The notion of view source is under attack. How hard to we try to fight it? How do we fight it?
Keep reading Alex’s post which has some good stuff such as:
To understand the importance of view-source, consider how people learn. Some evidence exists that even trained software engineers chose to work with copy-and-pasted example code. Participants in the linked study even expressed guilt over it the copy-paste-tweak method of learning, but guilt didn’t change the dynamic: a blank slate and abstract documentation doesn’t facilitate learning nearly as well as poking at an example and feeling out the edges and possibilities by doing. View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, loading it in a browser and switching between editor and browser between even the most minor changes. This is a stark contrast with other types of development, notably those that impose a compilation step on development, in which the process of seeing what what done requires an intermediate action. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop. The only required equipment is a text editor and a web browser, tools that are completely free.
“View Source is your friend”, we’ve learned countless times as web developers. It’s something special about web development that we can seamlessly lift the covers on anything we see and find out how the sausage is made. And it gets even better with greattools to interrogate the system in real-time. This capability has helped us evolve practices and patterns, and contributed to the production of many a fine browser extension and Greasemonkey script.
Our friend might sadly be going the way of the blink tag. View Source has always worked because the standard development model is to put up some static Javascript files on a server somewhere and serve them out. That model is changing though; performance is a veryhot topic right now, and View Source is playing victim to that trend.
Google’s Let’s Make the Web Faster initiative is a case in point. Here is a multi-pronged attack on the performance issue, involving new protocols (SPDY), tools (PageSpeed), browser improvements (Chrome), on-demand loading (Closure), and – most pertinent – compression techniques (Closure again). And we ain’t seen nothing yet; there’s every reason to believe Google will soon be putting its money where its mouth is, by rewarding faster sites with higher rankings. (I guess I was alone in assuming they always did that.) While performance should always be a consideration for site owners, a dangling SEO carrot would no doubt convert the best of intentions into the most concrete of actions.
Site owners can’t (much) control factors such as browser choice and browser efficiency, but they can get their own performance-fu in order, and code compression is low-hanging fruit. Looking at the top 20-ranked sites, filtering only English-language sites, I found the very top guys (Google, Facebook, Yahoo, YouTube, Windows Live) predominately using Javascript compression, with the others not using it much, if at all. I expect most of them to be using it in the next 12-24 months.
In addition to compression, there is also obfuscation. With Javascript being used for more complex tasks and replacing desktop functionality, more companies will be wondering about all that intellectual property sitting in plain view. (And let’s not mention the security-by-obscurity fans, who will also go this route, however flawed their thinking.)
Is it all bad? No. There’s a much healthier respect for plain old semantic HTML these days, which means HTML documents should be View Sourcier now than ever before. (CSS, not so much, with compression also likely to grow.) If I had to choose between one or the other, I’d take clear HTML over clear Javascript. Also, we will probably find the majority of sites in the long tail won’t feel the need to do anything about their code (but the ones who do make efforts are probably the ones with the most interesting things to look at). Also, the aforementioned tools, which do things like XHR sniffing, will help us to understand from a “black box” perspective even if we can’t peer into the code. Hopefully, there will also be more attention paid towards Javascript beautifiers as well, to make sense of compressed code.
I can’t speculate on the waning of View Source without mentioning the tremendous counter-balancing act played out by Open Source. From the get-go, open source has played a vital role in Ajax, with individuals and companies releasing code for all sorts of reasons. Most of this is library and framework code, rather than production-ready applications, so we might lose something there, but we still have much to gain from the ever-growing corpus of code that’s out there, free to be studied and incorporated into our own applications.
Posted by Michael Mahemoff at 10:40 am 29 Comments
Phil Rabin of CBC Radio 3 has kindly written a guest post on his experience creating a fantastic Web interface for the station that uses Flash for audio, but a full HTML experience that maintains state from page to page.
CBC Radio 3 is a community, radio station and user-generated independent music library which is a small department of the Canadian Broadcasting Corporation. When the CBC Radio 3 web team was called upon to rebuild the site we were confronted with the technical problem of having an uninterrupted music experience for our users. The old design of the site (see image) achieved this by embedding a flash player in the body with the content being served through a statically positioned iframe in the center of the page. Radio 3's content offerings were outgrowing the design so we went with a full page 1000px-wide layout with the player resting in the page. This created an obvious hurdle being that with a fresh page load comes a bad listening experience like myspace where a single wrong click breaks the audio. Also, not having popup player was a design decision that was made to give the website a more integrated feel.
We decided to completely removed flash from the UI equation and went full html/ajax because we found that it offered more flexibility and play with the page. The hardest part was figuring out a way to maintain state on each page load while keeping the audio continuous.
We went with an old-school frameset to create a type of inter-frame communication with the top level frameset acting as the orchestrator/bootstrapper. The visible "UI Controller" frame is completely blown out with the stateful player frame hidden from view.
The stateful player frame contains hidden swfs to handle playing audio and connecting to RTMP for our live streaming. All the communication in and out of flash is handled by a couple gateway javascript classes to abstract out the flash from the rest of the application.
Here's an example of a communication gateway for wrapping the events coming to and from flash. The event objects are native flash event objects that get sent by Flash's ExternalInterface and come in as JSON that can:
An instance of the gateway has to be maintained by the player application because events coming from flash have no context. This way the application classes can subscribe to events coming from flash like this:
At the core, audio is always played by Flash. The swfs broadcast events, such as audio head position and download progress of mp3s, and connection, streaming, meta data events from RTMP. Those events get passed on the instance of the hidden stateful player.
Since the server frame is only loaded once when the site first loads, an instance of the stateful server player is instantiated for the entire session on the site. On each client frame page load, the server player instance is "injected" into the visible client UI controller by the "bootstrapper" top frame. State is maintained in that instance which allows for the controller to query the state of that object and reestablish everything like which track is playing, progress, time, thumbs up or down status, shuffle, play mode (stream or individual mp3 and playlists), etc. Everything had to be covered like if an mp3 was in mid-load when someone browsed to a new page, the loading progress had to pickup on the next page. Here's a example of the bootstrapper code contained in the frameset:
We used Prototype/Scriptaculous as the base for the entire site. All the AJAX communication is handled with asp.net web services with scripting enabled. ASP.NET takes care of all the serialization of DTO's (Data Transfer Object) into JSON which are specific to the player application.
All of the classes in the application are written using Prototype's Class/inheritance model. Most of the classes subclass from a base EventDispatcher much like AS3, which is adapted from Matthew Foster's example for Prototype and our own custom Event model. This allows for a nice separation of concerns and decoupled classes throughout the application and allows the UI Controller to add event listeners to custom events coming from the server player instance.
for(var i = 0; i <this.listenerChain[type].length; i++)
if(this.listenerChain[type][i] == listener)
this.listenerChain.splice(i, 1);
},
clearEventListeners:function()
{
this.listenerChain = {};
},
dispatchEvent:function(type, data, target)
{
var event = new CBCR3.Commons.Event(type, data, target || this);
this.buildListenerChain();
if(!this.hasEventListener(type))
returnfalse;
this.listenerChain[type].any(function(funct){
return(funct(event) == false ? true : false);
});
}
});
This also allows the UI Controller to unsubscribe from all events when the page unloads. This was key in memory management and so that we don't get orphaned references to instances of the UI Controller.
The most difficult part of the whole player project was re-establishing state of the controller on every page load. We hoped that we could implement some sort of state-pattern with no luck. In the end, the UI controller contains a couple monster resume methods that we haven't been able to abstract out of that class. We'd like to bring in some sort of MVC architecture that wires up the UI player view to a state object. Any suggestions would be welcome! Go check out the site and give us some feedback!
Dion: I then asked Phil about the CBCR3 library and he replied
CBCR3 is the base namespace for all th javascript controls and apps written for the site. Everything for the player is in CBCR3.Player, the concert calendar is CBCR3.Gigs, etc. We have a shared base lib which is in CBCR3.Commons.
An issue with Prototype that we had was some bug with including 1.6.1 in a frameset in Opera. So, right now the frameset is holding an older version of prototype while the frames have the latest. One thing that Prototype was seriously lacking was Date extensions. (like addDay, addMonth, addWeek) etc.
We ended up going with YUI's DateMath widget for that which really smoothed out working with dates.
Most of the issues we had cross-browser stuff was with IE6 (no surprise), which were almost all related to CSS rendering bugs, and IE DOM manipulation problems. A big one was upon the dynamic removal of items from lists. IE has a real hard time refreshing the positions of items. We had to write methods like
this would in effect "nudge" the browser and force it to update the position of the remaining DOM elements. In the end, we chose to drop IE6 support and to tell you the truth, we haven't heard a single complaint about it!
As editors-in-chief so to speak, I always feel that it is important to fully disclose to the community any affiliation change. We have always tried to by balanced, and show that by featuring all kinds of news (for example, we haven't been shy at posting about great WebKit tech while at Mozilla, or amazing IE news ( ;) when at Google.)
Ben and I are nowatPalm leading up the developer relations team.
We started devphone awhile back as a place to talk about mobile dev, but I personally didn't have the gas to write a lot about that as I was mainly interested in the Web side of mobile development. Thus, my excitement when Palm released webOS and I had a nice path to take my Ajax skills to the rapidly growing mobile Web market.
You can expect to see some more mobile Web news, just because I will be looking at that world a lot more. However, you shouldn't expect to see any lack of other news, and we also love to accept contributions both as quick links to great Ajax news, but also guest posts. We really do see this as your community!
Also, expect to continue to see Bespin and Mozilla news, because we are very much going to continue to be involved in that community. I am in a Bespin meeting right now! Yay open source, and open companies like Mozilla!
Thanks for being loyal readers for the life of Ajaxian.com so far, and we look forward to serving you even more in the future!
He talks about an application that he has traditionally sold as a desktop app, and how it is faring on the Web. Bingo Card Creator is the application in question, and he has strong opinions :)
Over roughly the same period my day job has changed and transitioned me from writing thick clients in Swing to big freaking enterprise web apps. I’ve learned SQL, Rails, etc and used them to fairly decent effect in selling Bingo Card Creator, which is a Swing app (if all you have is a hammer…). This summer, I decided to try stepping my web programming skills up a notch, and released a web version of Bingo Card Creator. It has exceeded all my expectations: in ease of writing, in features, in sales, in support burden, in marketability, etc. In game theory terms, it strictly dominates the desktop version, when seen from the eyes of the developer at any rate.
If I were starting out today, I would, without a shadow of a doubt, write a web app instead of a desktop app, for these reasons:
The Shareware Funnel Is Lethal
Web Applications Convert Better
Your AdWords Strategy Is Very Sensitive To Conversion Rates
Web Applications Are Easier To Support
The Age Of The Pirates Is Coming An End, Jack
Phone Home vs. Google Analytics
Web Apps Can Be Customized Per User
Interesting to read. Note, Patrick does admit that he much prefers desktop apps in general (e.g. Excel > Google Docs).
We are all so into the Web, that we are often very critical. Web apps are too hard to build. They are too hard to monetize. However, the grass isn't always greener on the other side, and this shows you how brown it can be.
Chrome OS created a whole slew of buzz around the Web finally being an OS. There are many other examples of this of course. On the desktop we have had the likes of moblin and Jolicloud for quite some time. On the phone we have webOS.
The Web as a virtual machine
In many ways, it seems obvious that this will happen. When I look at my desktop, I often find it looking like this:
which looks surprisingly similar to this:
Wait a minute. Can't you look at the browser as being a virtual machine for the Web? A hugely successful one that has been ported to almost every platform known to man. It is a viral virtual machine that has become so successful due to its simple yet powerful constructs that allowed the platforms to do the porting (oh and it was friggin made to be free! Take that gopher!). As a virtual machine it grew so fast that it is quickly usurping the hosts themselves. The traditional operating systems. Applications are being written for the VM rather than the OS. This is very different to the diagram that has Windows running inside a VM on the Mac. In that case you are running applications written for Windows on the Mac. The virtualization crew have done wonders to make that emulation possible. With the Web you didn't quite need those tricks, and instead thanks to Web standards, you just had to write a browser.
Going inside out
Normally, we have seen systems built natively and then we virtualize them. In the case of the Web, the "Web platform" is the host environment and the VM. As this environment has become stronger and stronger, there is bound to be the time to ask "do we need our host anymore?" We are on the fringe of that time right now where a huge bulk of the applications that people use are Web based.
I just ran an experiment in this area myself. The hard drive in my Macbook Pro died and while the kind folks at the local Apple store replaced it I had to pick up a random machine for use. What would life be like if I had to work on a random machine? I purposely didn't restore from my own backup, and ended up with a week seeing how much of this cloud thing I use.
It turned out that all of the apps that weren't somehow cloud based were now a pain in the arse. Obviously I could get my email with Gmail and the other Web apps were there. However it went further than that. I could download Tweetie and be instantly up and running where I left off (thanks to the fact that Twitter is just a Web service). I got to see which IM servers did a good job keeping my server based contacts, and what a pain it is when you make changes on the local client to tell you that flubber65 is Frank and suddenly you have no idea who anyone is without that (NOTE: if you build a service, for gods sake save everything up there!).
It even made me happy for Bespin, as I was able to get to a bunch of my code. That has incentivized me to help make Bespin great :)
So, I learned that Web based services won. I was productive on a random machine in minutes, and cursed the situations where this wasn't the case (mainly around development).
If the entire OS was Web based, with a rich cloud infrastructure, then I could literally login to any machine and be ready to roll. X Windows productivity will be back! :) This will greatly change the role of devices too. Seamless upgrades. Multiple devices sharing data. Fun times.
So, Web OS it is. Hopefully the Web platform will be complete enough, and where it isn't this kind of force behind it will push it even faster (this is why I am excited to see the space heat up, and also wanting to keep a watchful eye to see how things get standardized with crazy timelines behind them).
What do we lose?
But, wait a minute. We have seen that virtual machines are actually pretty awesome. Having an entire system in a single file that I can suspend, backup, and run multiple off? Cool. I am running multiple "Web OS's" every day (Firefox, Safari, Chrome). I can update them whenever I want, and they can compete.
We also see fantastic features where we can watch over all of the connections from the virtual machine to the host. Tweak how ethernet works, set limits on various usage, etc. Just as we are getting amazing things out of virtual machines.... maybe we don't need the Web platform to move from there just yet.
User-Agent
Chris Beard (Chief Innovation Officer at Mozilla) is often talking about what it means for the browser to be the "users agent". There is so much that the s/browser/virtual-web-machine/g can be doing for us, and we have only just begun.
We need to be wary of losing out on any of these thoughts if the Web becomes the OS on the computer (whatever that means, of course!).
As we think about Jetpack and granting enhanced functionality from Web apps to browser-chrome I am often thinking about a morphing browser. When I am on Gmail, I don't need the URL bar and all of that jazz. Instead, add new Gmail specific UI for me to use, and let me tie into the local system for contacts etc.
In that vein, it has been nice to see a step in that direction when listening to Alexander Limi speak about UX in Firefox last week. He and the UX team showed some concept mockups for future versions of Firefox such as this:
By the "home" tab you can imagine other tabs that are for applications. Thin tabs that just have an icon (e.g. an email notification icon showing new message counts). These "app tabs" can be slightly magical. The user has to bless them, and at that time can grant special powers to access local services such as a File API, or a Webcam, or Geo location, or [insert cool thing that native apps can do]. This feels like a small step for the browser, but one that can open up a lot.
In conclusion, I am bullish about the Web being called the 'OS' on certain computing devices. I am most excited about seeing this driving innovation into the Web platform as a whole, and also exploring the great side of having a platform run as a virtual machine on your hardware. Gotta love the Web :)
Ben gave a fantastic talk on creating compelling user experiences that discussed craftmanship in software.
He details the somewhat opposing views of Alan Cooper (pictured above) and Joel Spolsky talking about how IT people are screwed when it comes to quality. A depressing thought, and one that we need to combat in the trenches by just creating great software at work and proving that it is a winning strategy.
One piece of the talk I wanted to highlight was when Ben discussed UI latency. He has a simple feedback test page that lets you see how various delays make you feel. Give it a go and think about what feels sluggish and annoying. It differs between people, but 100ms feels like the "noticeable" level and 200+ feels sluggish. We should have a page that doesn't show numbers and is randomly setup, and then do a test. What do you think?
Also, to finish off, you owe it to yourself to spend a couple of minutes watching this awesome rant of Louis C.K. as he discusses how screwed up we are wrt expectations:
This is actually incredibly relevant to us as developers, as we run up against expectations in software too. Do you want to meet expectations? Or set new boundaries?
We are big fans of PhoneGap, the "open source development tool for building fast, easy mobile apps with JavaScript" including apps that run on the iPhone platform.
The PhoneGap team has been winning awards and developers like it.
Upon review of your application, cannot be posted to the
App Store due to the usage of private API. Usage of such non-public
API, as outlined in the iPhone SDK Agreement section 3.3.2 is
prohibited:
" An Application may not itself install or launch other executable
code by any means, including without limitation through use of a plug-
in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple's Published APIs
and built-in interpreter(s).
The PhoneGap API implemented in your application is an external
framework.
This is just wrong. They haven't targeted RegexKitLite or Google Toolbox for Mac, or Joe Hewitt's cool new framework. PhoneGap only uses official APIs, so it isn't doing anything wrong there.
You could assume that this is on purpose, to keep people in the Obj-C sandbox. Or, you could consider the fact that the review process is probably manned by a LOT of people who sit there with check lists. I am hoping that someone at Apple gets to see the outcry from developers and steps in to do the right thing, just like they did when Trent Reznor and many others complained about the hypocrisy of his iPhone app not getting in the store.
Mark Pilgrim has a certain style, and it was in full force on his latest post on font issues that we have on the Web.
Some people are offended by tone and such, but if you ignore that, Mark is actually normally spot on!
In this case, the font world feels like the DRM world of music. They can battle up hill all they want, but if they don't start working with their users (who are willing to pay for fonts, just like we are willing to pay for music!) they will find themselves in big trouble.
I was chatting with a GFX engineer on Firefox and after a fun time talking about how freaking fun it is to get fonts right cross platform (holy subtle-ties batman!) he pointed to a nice M+ font (multiple weights etc):
There are tons of great open source fonts out there. One day, instead of looking up to the foundries in their ivory towers in the sky, we will look down on the floor and see the gold is right there! And, then what? What will the foundries have after they push everyone to go the open source route?
Let's enjoy font squirrel and find some nice friendly fonts and use them to make the Web more fontific, and hope that the other chaps work out how to play nicely.
Then Opera does something actually quite cute with their Opera Face Gestures gag:
Looking ahead, we recognize the future importance of touch interfaces, but we believe that there is another input device that is already present in most new computers and it’s ready to enable a whole new way of user-interaction: the webcam.
Today we introduce Face Gestures, a revolutionary technology designed to make interacting with your browser easier and simpler on computers with cameras. Face Gestures lets you perform frequent browsing operations with natural and easy to make face gestures. By using an internal technology dubbed Face Observation Opera Language, we are able to recognize pre-determined facial expressions and match them to commands on the Opera browser.
He talks about how some frameworks have code paths for specific browsers to shorten the if (foo) type overhead. Having a compile step like GWT does makes this easy. TIBCO GI "builds an optimized code tree for each major browser release (the opposite of the approach jQuery 1.3 and others have taken, as code only makes it into a build for that browser if that browser is known to support that functionality)."
excludeStart(”webkitMobile”)
Dylan then discusses what is happening in the Dojo community:
In recent discussions on the Dojo mailing list, discussions turned to how to make Dojo faster for mobile users. In most cases, this involves removing code and features that are not needed on that platform given the precious resources available on mobile devices and over mobile networks.
Alex Russell checked in some work he started last year that looks like this:
While we would love to switch to pure feature detection over browser version detection like John has done with jQuery 1.3, version detection is generally more concise and precise, and does not necessarily make Dojo any less forwards compatible.
Version detection also makes it easy to exclude code created solely for browsers that require major workarounds, such as IE 6. To get the most out of this though would require doing something similar for each major browser, which would make Dojo more challenging to understand and maintain, would probably require a build step even during development (not just in production to improve performance).
At this point, there are no clear answers, just a lot of questions on how to create a toolkit that offers edge of the web features for desktop users, and still preserves performance for mobile web users. What approach do you think is best?
2009 was a solid year. Progress was made in the depth and breadth of the platform as we saw:
Browsers
The IE6 frustration is far from gone, but the tide is moving and we now see fantastic browsers with decent share. We may get Firefox 4, Safari 5, Chrome 73 (they like to bump versions quickly don't they) and even IE 9 if we are lucky. All with rich standards support, fantastic performance that goes beyond the JS runtime to areas such as the DOM, network layer, and GPU acceleration throughout.
Folks got excited to hear Microsoft talking about Canvas, but it was limited. IE with Canvas support will be fantastic and we hope it happens. Silverlight team.... turn around and let the IE team do their thing.
Developer Tools
Firebug has done well for us, but we need more. This year we got a lot of great new tools. From fantastic add-ons to Firebug itself, to WebKit Inspector improvements, to Chrome developer tools. We finally get the ability to look at memory (in Chrome and Firefox) and the black box is broken. To top it off we get Speed Tracer which I expect to see supported in more than Chrome in 2010 (already in WebKit, and I wouldn't be surprised if it was working in IE).
Ubiquitous JavaScript
JavaScript is going everywhere. With efforts such as CommonJS we saw the server side JS community come together to make sure that we don't have 15 File APIs! Narwhal and Jack are doing well, but we then saw the explosion of the awesome node.js for event I/O. A community has grown around Node, and I expect 2010 to push hard in this area.
Mobile
How could I not mention mobile? There are more mobile SDKs than I have had hot dinners, yet many of the smart phones have something in common.... a Web stack. 2010 will push hard here too, and will be a turning point for the Web. It is our contention (which is why Ben and I are at Palm) that the Web can be a unifying platform for devices and platforms. As a consumer it is fun to think about all of the devices in the near future. I want my watch, my glasses, my mobile device, [insert every other device] to be connected... but how, as developers, are we going to program all of these? The Web has a way to go .... but a huge community with large companies are pushing hard, and I think that we will soon look down and say "oh wait, this is actually an awesome platform!"
"HTML5" may not fully be here in 2010, but it will be a lot closer and we will have many more APIs that we can start using as they are implemented by browsers. WebSockets. Canvas 3D. Keep it coming!
What are you excited for in 2010? The date feels futuristic, so we have to make that a reality. Above all of course, I hope you all had a great 2009, and look forward to a passionate, enjoyable, rewarding 2010. Cheers.
I realise that we are an international community here at Ajaxian, but for the American Thanksgiving holiday, I thought it would be OK to take stock and say some thanks too.
Firstly, to the bright hackers who brought us not only XHR (thanks Microsoft), but porting it to other browsers, and then the hard work of giving us the Ajax libraries. The Ajax framework authors have done the hard work so we don't have too. They boldly go where no Web developer wants to.
Thanks to the browser vendors, especially recently got getting back in the game and charging ahead. We have another game on our hands as we see browsers add features and come a huge way with respect for performance.
Finally, thanks for you all. You provide the colour that we get to cover. You build the great applications that we get to showcase. The engine that is Ajax matters little if there isn't a great body on top. Thanks for pushing the Web forward, and for supporting the platform that tries hard to be Open for all. We have a unique opportunity to have developers "own" the platform that we all build on rather than a particular vendors. We need to push even more to make this happen in spades.
If you notice that we haven't covered something that you have found cool... perhaps you made it, please don't assume that we glossed over it. Chances are that we simply didn't see it. So please email us and contribute some news! One of the Ajaxians will make sure to check it out. To the other Ajaxian editors, I appreciate ever post that you do to contribute to this community.
As it is Adobe MAX this week, there is a lot of talk about the Flash platform. How does this relate to the Open Web? Well, it turns out that Dion and I have been discussing how Flash can join and become a part of the Open Web.
Adobe (via Macromedia) has traditionally been a Web designer company, but developers haven’t jumped in to the same degree (note: not to say they haven’t been wildly successful!). I think that the perception is something like this:
Dion discusses how Adobe has an opportunity to position themselves relative to Silverlight much more strongly in the Open Web camp:
With Silverlight making a huge charge I worry about a world where you have “Best viewed in Silverlight and IE” (which in fact is “only viewed in…”) and people often ask: “But isn’t Flash just as bad?”
Adobe has an opportunity here. They can move to the right and Flash could become strongly in the Open Web camp. Then we would all be stronger as we come up against Silverlight :)
The next logical question related to this is open sourcing Flash:
The conversation tends to end up with opensourcing Flash, which I think will happen at some point through necessity, and the sooner the better (for everyones sake). Flex has a loyal base and has some open source help, but hasn’t gotten the love that it could get because it sits on top of something that isn’t open source itself. It is hard to get excited about an open source tech that sits on top of the same vendors proprietary platform!
I agree with Dion that open sourcing Flash and having it join the Open Web camp is a very compelling idea. Open source would just be the first step, though, so following up on Dion's post I put together an editorial titled "How Flash Can Integrate With The Open Web":
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen...The important point is to integrate Flash and Flex more deeply into how the Open Web works:
Cross-Platform Standards
No Vendor Lock-in
Anyone Can Innovate
Powerful, Universal Clients
Open Source Implementations
Mashable, Searchable, and Integrated
I give a list of suggested ways to do this; the important thing is to have Flash integrate more deeply -- these are just some suggestions to kick things off. Here are some of them; click on them to read more in-depth how this might work:
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
