Ajax Girl

For years, many of us have been salivating over the idea of JIT’ed JavaScript in the browser. Adobe’s JIT’ing Flash VM showed a preview of tremendous speed gains to be had, but we’ve had to wait until SquirrelFish from WebKit to see anything dramatic happen in the browser.

Until now.

Mozilla just let the cat out of the bag on their new TraceMonkey project. Brendan Eich, Mozilla’s CTO, describes it thusly:

I’m extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox’s SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more. [Emphasis ours.]

There are charts and graphs all over the Web; here’s one from Brendan’s blog:

As Brendan points out, the benchmarks can be generally quite misleading; the best results are the demos. And, here’s a link to Mike “schrep” Schroepfer’s blog entry where he put one together in a screencast:

Brendan goes into significant detail on how all of this came about, and notes some key points:

* We have, right now, x86, x86-64, and ARM support in TraceMonkey. This means we are ready for mobile and desktop target platforms out of the box.
* As the performance keeps going up, people will write and transport code that was “too slow” to run in the browser as JS. This means the web can accomodate workloads that right now require a proprietary plugin.
* As we trace more of the DOM and our other native code, we increase the memory-safe codebase that must be trusted not to have an exploitable bug.
* Tracing follows only the hot paths, and builds a trace-tree cache. Cold code never gets traced or JITted, avoiding the memory bloat that whole-method JITs incur. Tracing is mobile-friendly.

For even more details, check out Andreas Gal’s detailed blog entry on trace trees.

The first phase of Ajax has been all about leveraging the existing platforms as much as we can. This announcement is a major signpost towards the second phase: improving the existing platforms. We couldn’t be more excited.

Brendan puts it in his own understated way:

JS-driven <canvas> rendering, with toolkits, scene graphs, game logic, etc. all in JS, are one wave of the future that is about to crest.

John Resig voices similar sentiments in his excellent blog post on the subject:

[This] means that JavaScript is no longer confined by previously-challenging resource of processing power… I fully expect to see more massive projects being written in JavaScript…

The primary thing holding back most extensive Canvas development hasn’t been rendering - but the processor limitations of the language (performing the challenging mathematical operations related to vectors, matrices, or collision detection). I expect this area to absolutely explode after the release of Firefox 3.1 as we start to see this work take hold.

Speaking of Canvas and JS, we’ve got our own little project we’ve been hacking this year that we can’t wait to try this on… way to go, Mozilla!

Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/372268236/javascript-jit-the-dream-gets-closer-in-firefox

Ning, the build-your-own social network platform, has removed all widgets created by popular premium developer WidgetLaboratory. The news has come without warning and is being met with outrage by a number of users who have spent hundreds of dollars on the widgets to build up their social networks. WidgetLaboratory sells its widgets for around $30 a month, and has managed to become the most popular widget creator on Ning’s platform.

WidgetLaboratory has posted a notice to its site explaining that it has received no explanation from Ning, and speculates that the shutdown is a result of anti-competitive behavior rather than a breach of the ToS - it’s possible that Ning saw that the company was making a sizable amount of revnue, and was worried that it might make a grab at its users. The site has also posted a form asking users how much they’ve spent on their widgets so they can be properly compensated (apparently through a lawsuit).

Update: We’ve been digging into the story and it appears there’s another side to this. We’re hearing that WidgetLaboratory may have been displaying a pattern of questionable behavior and that they were given “ample warning” and a chance to correct their actions. Ning isn’t commenting on the situation, so the full story may not ever be fully understood.

Here’s an excerpt of WL’s statement (the emphasis is mine):

As of this morning, August 22, 2008, we learned from our customers that Ning had unilaterally removed Widgetlaboratory.com and all of its products. We have received no formal notice or explanation at this time. We have not violated any Terms of Service, nor have we violated any published “guidelines” from Ning.

This action by Ning was completely without any notice, was without any merit, and in our opinion was done for the sole purpose of eliminating a company that had started to provide a useful and valuable service to all of you. We have a full and complete documentation of our relationship with Ning from the very first moment that we contacted them in November of 2007 and met with them subsequently to get their blessing for creating our company and products. The facts and details contained therein will substantiate our claims regarding Ning’s actions.

We have achieved a level of market penetration into the Ning community that has made WidgetLaboratory a somewhat “essential” resource for add-ons and widgets. Based upon the personal phone calls and correspondence from the entire Ning team, including their entire Executive staff, it would appear that they decided to elminate WidgetLaboratory for anti-competitive purposes alone. This is truly ironic to us, given the fact that our products have demonstrably INCREASED the popularity of Ning and caused more customers of Ning to purchase their Premium Services. This was truly a win-win-win relationship between Ning, WidgetLaboratory, and all of you.

Ning has responded by explaining that WidgetLaboratory has violated the social network’s Terms of Service, but says it won’t be providing any more additional details to the public.

This morning we removed WidgetLaboratory, a third party application developer, from the Ning Platform for violating Ning’s Terms of Service. WidgetLaboratory provided independently developed applications that could be added to a social network on the Ning Platform by a Network Creator. While we try to be as transparent as possible, it’s our long standing policy not to comment on specific cases where we remove networks or third party developers from the Ning Platform so we will not be providing any additional details publicly.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Source: TechCrunch
Original Article: http://feedproxy.google.com/~r/Techcrunch/~3/J3GEmWrPFTY/

Disney embarked on a cellular phone business in the US as early as June 2006 but pulled the plug at the end of last year, citing delays in the spread of 3G networks as the major reason.

In March this year, Disney carried out another attempt, but this time in Japan, where the brand has been super-popular for decades now. Disney Japan teamed up with local telecom conglomerate SoftBank to become the country’s first mobile virtual network operator (MVNO) offering both voice and data services.

In Japan, Disney strategically about-faced by pursuing an OEM-like strategy: They leave back-end operations (distribution, price planning, sales, billing, etc.) to their partner and focus on bringing content, design know-how and brand value into the partnership.

Japanese customers can sign up for Disney Mobile at over 2,000 SoftBank stores and buy jointly designed handsets featuring various Disney characters. Subscribers are able to download Disney cartoons, games or ringtones, jump to exclusive Disney web sites by pressing a dedicated button on their phones and use @disney.ne.jp as their mobile mail address. Another accommodation to local peculiarities: The main target customers in Japan aren’t kids but women in their 20s and 30s.

So far, the change in strategy seems to have worked out well. For example, Disney Mobile just recently reached agreements with mobile giants Mobage-town and Mixi Mobile (the cell phone version of Japan’s biggest social network), which now feature Disney characters on their sites.

Crunch Network: MobileCrunch Mobile Gadgets and Applications, Delivered Daily.

Source: TechCrunch
Original Article: http://feedproxy.google.com/~r/Techcrunch/~3/cLTc9w1OHjI/

There is no Google Earth app yet for the iPhone, but Earthscape has released the next-best thing: Earthscape Basic. The app is now available in the iTunes store for $10, and puts a little globe in your pocket that you can spin around and zoom into specific locations. It shows where you are based on your GPS coordinates, and highlights locations with Wikipedia entries (and lets you read those entries as well). As cool as it looks, though, it is less functional than a preview last May suggested it would be.

Frank Taylor at the Google Earth Blog takes the app through the paces in the video above. As he points out, there is no search capability, support for standard KML data sets, or accelerometer support. So you don’t really get much more out of the app than you can already get from Google Maps on the iPhone (which comes with a pretty awesome satellite view and search). As a standalone app, you can spin the earth and scroll through landscapes faster than waiting for Google Maps to update its data over the air. Is that really worth $10? (No, but I still want it).

Update: Earthscape CEO Tom Churchill says that the app will gain more features through future upgrades:

The application itself is quite basic (hence the name), but will see a number of feature additions over the next several months, as we include suggestions for improvement from users and look to take advantage of what a virtual globe can do in a mobile context.

He also notes that while the app maintains a cache of recently seen landscape “tiles,” up to thousands of them, it does rely on the network to download new information. So it is dependent on the network for its performance, and works best with WiFi and 3G.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Source: TechCrunch
Original Article: http://feedproxy.google.com/~r/Techcrunch/~3/iO2HsCbf8qU/

After hinting that it would do so last June, Google’s mobile team has released a Geolocation API for Google Gears. This works both on mobile phones and laptops running Gears, but developers will find it most useful for mobile applications. Unfortunately, they will be limited in that regard because Google Gears Mobile still only works on Windows Mobile phones, even though an Android phone is about to launch. (Maybe now that a new Android SDK is out, the mobile team can finally figure out how to make Gears work on Android too).

Google figured out how to find a mobile phone’s location for its own mobile apps, such as Google Maps, and is now opening that technology up as an API to outside developers. Two UK-based mobile startups—Rummble and lastminute— have already built the API into their services. The Google Mobile blog explains:

These two apps make use of the Gears Geolocation API. The API can determine your location using nearby cell-towers or GPS for your mobile device or your computer’s IP address for your laptop. Google provides this service for free to both developers and users.

Gears is available on IE Mobile on mobile and Internet Explorer and Firefox on desktop. To use the location-enabled lastminute.com and Rummble web apps you will need a Windows Mobile device that supports GPS or cell-id lookup (for example the Samsung Blackjack II and HTC Touch Dual, see supported devices FAQ). We are working hard to bring Gears to more mobile platforms, such as Android and others.

There is also more detailed information on the API on the Google Code blog.

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

Source: TechCrunch
Original Article: http://feedproxy.google.com/~r/Techcrunch/~3/jyD90nkZVgw/

Hi folks, this is my first guest blog post here on Ajaxian. It’s great to join the team.

Gears, the open source browser plugin that teaches web browsers new tricks, has pushed out a new 0.4 release. 

Andrei Popescu from the Gears team lets us in on some of the nifty new features:

We have added a new Geolocation API, which allows you to build applications that can do new and exciting things based on your users’ location. You can query Gears for the user’s current location using the getCurrentPosition() method or you can ask Gears to notify you every time the location changes, using the watchPosition() method. Of course, we take privacy issues very seriously, which is why we have a special permission dialog that allows users to decide which Web sites should have access to their location information. If you want to learn more about how the Geolocation API works, please see the Google Code blog post.

In addition, Gears now makes uploading large and multiple files on the web much easier, giving you the primitives to roll a resumable uploader, which means hopefully we can see custom desktop uploaders go away soon. In addition, Gears 0.4 introduces a new thing called Blobs:

Another cool new feature is the Blob API. Unlike strings, blobs let you reference arbitrary binary data — a first for JavaScript! Therefore, blobs can more naturally represent things like files and images, and they can be passed around efficiently. We have updated several existing APIs to work with blobs, such as WorkerPool sendMessage() and HttpRequest send(). And that’s not all! We have also extended the Desktop API with a new method, openFiles(), which allows users to select multiple files of a particular content type, and then returns them as blobs for easy uploading or worker processing.

As a final note, Gears is continuing to push new features and experiments like the Geolocation API into the standards process:

Finally, an update on how we are doing on Web standards: in line with our earlier promises, the Geolocation API is a W3C Editor’s draft and its current design is a result of open collaboration with many other people and organizations. We plan to continue to drive this standardization effort, as well as work with the community on new Web standards.

I decided to give the new Gears 0.4 APIs a roll to illustrate how powerful they are when put together, mashing them up to create a sample application. In addition, I needed a server-side implementation, so I created a Python server-side that runs on Google App Engine. This mashup is named Upload Movie Tool (not the most creative name, I know

This demo allows you to select multiple movies, and then upload them in a resumable way with feedback using the Gears Blob and File System API. We also use the Geolocation API to figure out what your location is for tagging the video, and the Google App Engine to store everything on the back-end.

Give the demo a try yourself, or check out its source code (see the client JavaScript and the Google App Engine Python). This code is open source so you can feel free to use it as the basis of your own Gears-based resumable uploader/geolocation app.

I put together a screencast where I run through the application. There is a bonus if you make it all the way to the end, with videos showing Dion and I using the new slide that was installed last week in the Google San Francisco office!

 
Disclosure: I work for Google

Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/371927784/gears-04-mashup-of-gears-and-google-app-engine

Earlier this week in a post comparing real estate sites Trulia and Zillow, I suggested that the most important success factor for these sites is how comprehensive they are. The more listings the better because home buyers want to go to one place to find every home on the market. They want a single dashboard from which they can filter down the choices.

But just how comprehensive are these sites, and how accurate are their listings? Trulia offers 3.5 million listings nationwide, and Zillow has 3.1 million. But people look for houses in local markets, not nationwide. What matters is comprehensiveness withing local market

A few hours after I put up that post, I heard from Roost, a competitor to both Trulia and Zillow (with only 1.4 million listings in the markets it covers) that differentiates itself by <a href=”
http://www.techcrunch.com/2008/01/22/real-estate-search-engine-roost-launches-with-full-mls-listings/”>getting its data directly from the same Multiple Listing Services (MLSs) that real estate brokers use. They just happened to have study in their back pocket (which they commissioned and paid for) that compares the “accuracy” of search results in three cities (Dallas, Miami, and San Diego) across different real-estate search services (Roost, Zillow, Trulia, Yahoo, and Google). The study, which was done by real-estate industry consultants the WAV Group, defines accuracy as the percentage of listing results that match listings the MLS for that city.

The results are in the chart above and, not surprisingly, Roost comes out looking great. For each city, it returns between 95 and 99 percent of the listings in the MLS. Trulia’s accuracy in the study ranges between a pitiful 9 percent for San Diego to 61 percent for Miami. (Zillow generally does worse across the board, with its accuracy ranging between 12 percent and 36 percent across the three cities).

Trulia disputes these results. Heather Fernandez, vice president of marketing, says:

The data looks very questionable, and not in line with our internal coverage data. Our data shows that we have roughly 70% coverage in most major metros.

And indeed, if you do a search for homes for sale in San Diego on Trulia, you get 4,395 results, compared to 6,036 on Roost. That’s 73 percent. (Zillow claims 7,661 listings in the San Diego city limits). Even if half of them are stale listings or not accurate in some other way, it’s hard to get to the 9 percent that the Roost-financed study claims. That’s because for some reason, the WAV study only compared homes in each city with exactly 3 bedrooms and 2 baths, within a $50,000 price range.

That methodology seems random and flawed to me. Would Trulia’s accuracy be greater if the study had looked at homes in San Diego that cost $400,000 to $450,000 instead of $300,000 to $350,000? Comprehensiveness would have been a virtue in the study’s methodology as well as in what it was trying to measure.

Still 70 percent accuracy is not that great, and it doesn’t seem like Zillow is any better. If the MLS in any given city is the benchmark, both have a lot of work to do. And Trulia, for one, is striking deals with different MLSs to incorporate their data. But it only has 14 so far, out of about 900 nationwide. MLS-based sites like Roost and Redfin may have more listings in the markets they serve, but they don’t serve every market yet. For instance, in San Diego, Redfin tracks 6,300 homes for sale, better even than Roost. Yet neither has any listings in New York, and Redfin only has 473,000 listings total.

Yet Redfin CEO Glenn Kelman also balked at my earlier suggestion that either Trulia or Zillow are even close to comprehensive within any given market. In an e-mail to me, he said:

What got me was that almost any real estate site has more homes for sale than Trulia or Zillow.

Frenandez doesn’t think that having the most listings matters. She responds:

Listings are commoditized –there are dozens of sites that offer basic listing information in every city across the country. It’s not a competitive advantage for an Internet company.

What is more important, she says, is the filtering the site allows home buyers to do to help them make an informed decision. I’d say it’s both. Those filtering tools (heat maps, sales comps, local school info) are also becoming commodities. You want to cast your net as wide as possible before you filter down so you don’t miss out on that one house that fits all of your criteria.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Source: TechCrunch
Original Article: http://feedproxy.google.com/~r/Techcrunch/~3/n63V3RScdd8/

Mark Pilgrim continues to keep us up to date with news in HTML 5 land. This week he talks to us about the birth of the event loop, and the hashchange event.

I saw this just after posting about the cross browser hashchange example by Zach Leatherman. In the future we will see a nice, standard way to do this work:

The other major news this week is the addition of the hashchange event, which occurs when the user clicks an in-page link that goes somewhere else on the same page, or when a script programmatically sets the location.hash property. This is primarily useful for AJAX applications that wish to maintain a history of user actions while remaining on the same page. As a concrete example, executing a search of your messages in GMail takes you to a list of search results, but does not change the URL, just the hash; clicking the Back button takes you back to the previous view within GMail (such as your inbox), again without changing the URL (just the hash). GMail employs some nasty hacks to make this work in all browsers; the hashchange event is designed to make those hacks slightly less nasty. Microsoft Internet Explorer 8 pioneered the hashchange event, and its definition in HTML 5 is designed to match Internet Explorer’s behavior.

Defining the event loop is a big deal:

The purpose of defining an event loop is to unify the definition of things that happen asychronously. (I want to avoid saying “events” since that term is already overloaded.) For example, if an image defines an onload callback function, exactly when does it get called? Questions like this are now answered in terms of queueing tasks in the event loop.

Thanks again to Mark for doing the work so we don’t have too. After seeing three episodes, it is interesting to see the velocity of changes in the spec. Kudos to the group for that.

Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/371865342/html-5-the-event-loop-hashchange-and-more

The $100 early bird discount for The Ajax Experience expires today, August 22! Don’t wait! Register now to reserve your spot at the lowest price.

The Ajax Experience conference takes place September 29 – October 1 in Boston. Register today to save $100 with the early bird rate.
The Ajax Experience is the original and most in-depth rich internet application conference featuring over 40 sessions with top industry experts on such topics as cross-browser compatibility, choosing the right framework, best practices on balancing Web 2.0 features with speed, and many more. See our full conference agenda for what we’ve lined up for 2008.

The best part of The Ajax Experience is being able to hear what others are working on and get a feel for where the community is headed.

We look forward to seeing you in Boston next month!

The Ajax Experience conference takes place September 29 – October 1 in Boston. Register today to save $100 with the early bird rate.

Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/371856354/the-ajax-experience-early-bird-deadline-is-today

IE 8 has an onhashchange event, and Ajax history / bookmark management has been a long time problem of choice for developers.

Zach Leatherman has revisited the problem and has another solution that doesn’t require setInterval to check on the location.

1. On initialization, we load an iframe onto the page that is positioned absolutely at -500px,-500px so the user can’t see it. It is a skeleton page that only needs cross browser code to add an “onscroll” event, and to be able to calculate the scrolled position of the iframe itself. For my example, I use jQuery and the dimensions plugin to accomplish this, but it could easily be trimmed down to only the bare essentials (or ported to a different library).
2. To add an AJAX history entry into the browser’s history under an assigned hash string, we first add a <a name="hashString">hashString</a> to the <body> tag of the iframe. Using css to increase the size of the a tag proportional to the iframe’s height, we can guarantee scrolling will happen.
3. Then, we change the location.hash of the iframe to point to that <a> tag. This will scroll the iframe to the content, and create a new entry in the browser’s history object.
4. Inside the iframe, we have our onscroll event that fires when the scrolling in the previous step took place. (Minor IE-related workaround: The browser’s history object is changed, but the hash property doesn’t when attempting to read it later. Instead, we find the <a> that matches up with the scrollY/pageOffsetY property inside of the iframe, and retrieve the matching hash from the <a> tag.)

The solution gives you history management and back button support in one fell swoop, with the side effect of not having bookmarkability (since the iframe is updated).

Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/371828042/emulating-onhashchange-without-setinterval