A Wired.com user account lets you create, edit and comment on Webmonkey articles. You will also be able to contribute to the Wired How-To Wiki and comment on news stories at Wired.com.
Now, you can do the same crazy user interface stuff Google does on sites like Gmail and Google Docs on your own website.
The company announced it is releasing its Closure toolset under and open-source license on Thursday. The core pieces are the Closure Library, which contains the actual scripts themselves, the Closure Compiler, which optimizes and compresses the JavaScript code and the Closure Templates, which are pre-built templates for elements you can snap together to build your website’s interface. There’s also a JavaScript inspector.
It’s often hard to remember, but when Gmail first arrived on the scene in 2004, it was something entirely new. Ajax wasn’t as widely used yet, and Gmail showed off what a JavaScript-powered web app could do in a simple and straightforward way. Not only was it a great productivity tool, but the way it refreshed and allowed drag-and-drop seemed, to many of us, like magic. It turned the webmail inbox — and the web app rule book — upside down.
Closure Compiler, Closure Library, Closure Templates, and Closure Inspector all started as 20% projects and hundreds of Googlers have contributed thousands of patches. Today, each Closure Tool has grown to be a key part of the JavaScript infrastructure behind web apps at Google. That’s why we’re particularly excited (and humbled) to open source them to encourage and support web development outside Google. We want to hear what you think, but more importantly, we want to see what you make. So have at it and have fun!
Developer Mark Pilgrim has posted a fascinating look at how the HTML img tag came into existence. The history Pilgrim digs up — mailing list conversations between the creators of the first web browsers like Marc Andreessen and the webs early pioneers like Tim Berners-Lee — show that far from being a carefully planned specification, the lingua franca of the web evolved a bit like the early universe — out of a murky chaos.
That from the chaos we got a workable — some would argue good — solution for creating the web is proof on some level that conversations and not abstracts, proposals and design by committee are the key to HTML’s success.
As Pilgrim writes:
HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction.
You might be wondering, why did img succeed where other proposals, like an include or an icon tag failed? The answer is simple, because Marc Andreessen shipped code — Netscape Navigator — while those backing the other proposals, for most part, did not.
Of course that doesn’t mean that just shipping code is always good plan. Shipping code before a standard doesn’t necessarily produce the best solutions, as Pilgrim says. Or, put another way by a commentator on Pilgrim’s post, “shipping doesn’t mean you win, but not shipping means you lose.”
From those who shipped without the official blessing of a standard, we’ve come to have an img tag, the basis for AJAX, all of the HTML5 tools available in browsers today and much more.
Critics of HTML’s disorganized evolution will be quick to note that we’ve also come to have the blink tag, cross-browser rendering issues and other pains of web development.
Indeed we’re not suggesting that shipping features without at least engaging in the conversation is a good idea, but, when it comes to the future of HTML, if browser makers don’t ship HTML5 features before the standard is official we’ll be waiting until 2022 to use the new tools.
But while the future of HTML5 might be moving at a rather slow and convoluted pace. Pilgrim’s post is reminder that HTML has always progressed that way.
Perhaps the truly remarkable part is that, for all its flaws and convoluted evolution the core tech behind the web remains essentially the same now as it was then. “HTML is an unbroken line… a twisted, knotted, snarled line, to be sure… but still… Here we are, in 2009, and web pages from 1990 still render in modern browsers.”
User input is critical to the success of any project, be it a piece of desktop software, a web-based app or a simple brochure-ware website. And I’m not just talking about usability testing, e-mail forms or demographic surveys, which most of us consider a necessary evil. The truth is that your project, and your creative skills, can gain significantly from involving the user in the process of building and improving your app.
Granted, user communities can be a burden to manage, but the happiness of that very community determines how its members are going to engage with your app. If you ignore them or cheese them off, they’ll leave and refuse to come back. If you do what you can to satisfy them even a little, they’ll not only stick around, but they’ll encourage their friends to participate as well. And once you do engage your users directly, you’ll probably end up stunned at how rewarding the results can be.
The video above is of a talk by Google’s Ben Collins-Sussman and Brian Fitzpatrick — who is also head of Google’s Data Liberation Front, and who we interviewed last week on Webmonkey — at the company’s I/O developer conference last May. Ben and Brian talk in-depth about the “lost art of customer service” and the complicated relationship between engineers, user communities and marketing priorities.
A must watch for engineers, designers and project managers alike. About an hour long.
One significant aspect of web design that we at Webmonkey often ignore is so-called “search engine optimization,” or the art of making sure Google and its brethren can find, crawl and index your websites.
Part of the reason we typically ignore SEO is that it’s an industry full of what Derek Powazek, who has worked at both Google’s Blogger and Technorati, and is a former Webmonkey contributor, recently called “scammers.” Indeed, black hat SEO outfits are responsible for creating billions of bad results for users — highly ranked sites that actually offer little more than advertisements and spam.
It’s too bad the SEO industry ended up this way, but with the rise of Google and the importance of PageRank, as Powazek puts it, “like the goat sacrificers and snake oil salesmen before them, a new breed of con man was born, the Search Engine Optimizer.”
Naturally Powazek’s rant against SEO raised the ire of folks like Danny Sullivan over at Search Engine Land — people that focus on optimizing sites for Google without resorting to black hat techniques.
Leaving the ranting aspects of Powazek’s post aside, you’ll find that he and Sullivan actually agree. They just use different terms to describe what they’re talking about. The real message of Powazek’s rant is not that SEO is wrong, but that you shouldn’t have to pay extra to get it.
SEO is actually just a subset of good web design. Powazek writes:
Good SEO techniques are just good web development techniques. They should be obvious to anyone who makes websites for a living. If they’re not obvious to you, and you make websites, you need to get informed. If you’re a client, make sure you hire an informed web develeper.
Powazek is actually echoing Google’s own advice, which says: “if you’re thinking about hiring an SEO, the earlier the better… that way, you and your SEO can ensure that your site is designed to be search engine-friendly from the bottom up.”
In other words, if you’re a web developer and SEO isn’t part of your toolset you’re doing your customers and yourself a disfavor.
The developers behind the Django Project are getting ready to start work on the next version of the popular web development framework. Although Django 1.2, as the next release will be known, won’t be available in final form until March 2010, the project is currently voting on which proposed new features will be included in the next release.
Django is a powerful open-source web framework, written in Python. Compared to other open-source (or even proprietary) frameworks for building specialized, database-driven websites, Django makes the core tasks remarkably easy and fast.
Django already powers numerous high-profile websites, from the geo-aware EveryBlock to Google’s App Engine tools. In a testament to Django’s rapid development capabilities, developers Concentric Sky recently rebuilt the high-traffic michaelmoore.com using Django. From proposal to launch was a mere five weeks; you can read more about building the site over at the Concentric Sky website.
With Django gaining in popularity and more high-profile websites using the framework, the release of Django 1.2 in 2010 will be an important milestone for the framework.
Proposed new features for Django 1.2 include some features clearly geared at larger sites — support for multiple databases as well as a number of new database backend options will no doubt be a boon to developers should they make the final list. Other proposals include adding some more options to the Admin user interface and providing better built-in cross-site forgery protection. A complete list of proposals can be found on the Django wiki.
So far, no decisions have been made regarding any of the proposed features. Voting will continue until October 20, after which time an official list of what’s to come in Django 1.2 will be released.
If you’d like to contribute (and voting for a feature means committing to contribute to it) head over the the Django wiki and read through the guide to Contributing to Django.
Yahoo has announced the official release of version 3 of its open-source Yahoo User Interface (YUI) library. The new framework is designed to simplify the process of building complex web interfaces.
With several popular JavaScript-heavy websites like Flickr, Yahoo Mail, MyYahoo and Yahoo Sports, Yahoo has long been at the web’s cutting edge for producing rich, interactive user interfaces. The company’s freely available YUI library has helped popularize various web interfaces we now take for granted, like drag-and-drop actions, tabbed interfaces and click-to-edit text fields.
YUI 3 represents a total, ground-up redesign of the framework and brings some much needed modernizations, including simplified syntax, JQuery-style selector support and a much lighter (6.2kb) “seed” file that makes for much faster page load times.
Developers first got a taste of YUI 3.0 over a year ago when Yahoo began offering a testing version of it, along with suggestions on migrating from YUI 2.0. Since then, Yahoo has vastly improved the library and launched it into the wild on the front door of Yahoo.com.
“The code we’re shipping today in 3.0 is the same code that drives the new Yahoo Home Page, and it goes out with confidence that it has been exercised vigorously and at scale,” writes Yahoo’s Eric Miraglia.
YUI 3.0 brings the framework up to par JQuery and other popular tools for building rich JavaScript interfaces, especially Yahoo’s decision to embrace selectors. While previously controversial since they involve some processing overhead, modern web browser have no trouble parsing selector libraries.
The nice side effect of selectors in YUI is that developers familiar with the JQuery or Prototype JavaScript libraries should be able to transition to YUI without too much trouble. That gives web developers yet another option when it comes to designing and creating rich web interfaces.
Not all the time — in fact, there are an increasing number of great, dare we say fun, tools out there. Frameworks like Ruby on Rails and Django take a lot of the pain out of web development, and JavaScript libraries like JQuery or Dojo make creating slick user interfaces easier.
But even with the fantastic tools we have, there are still plenty of mundane tasks that, well, suck. In fact, most advancements in web development have come from a very basic developer problem: how can I make this suck less?
That’s the question Django developer Jacob Kaplan-Moss recently set out to answer at a Python Conference in Argentina. As Kaplan-Moss says in his talk, embedded above, “we’ve already made a great transition from thinking about ‘web pages’ to thinking about ‘web applications’.” His key point, however, is that, “it’s time for a new transition, for us to start thinking about a holistic ‘web site,’ and all its associated related tech.”
For Kaplan-Moss “all its associated related tech” means everything from backend frameworks to HTML 5, which is going to change the way web developers work. If you don’t believe that claim yet, check out 280Slides.com, which looks and behaves like a desktop app — drag and drop things within the app, to desktop and from the desktop. Sadly, as Kaplan-Moss points out, the developers of 280Slides had to create not just a new framework (Cappuccino — which you can read our assessment of), but what amounts to whole new language (ObjectiveJ) to realize their goals.
Creating a custom framework sucks, so imagine how much it sucks to create a new language. Surely there’s a better way?
Maybe. But, according to Kaplan-Moss, we should look to rethink the frameworks themselves since they’re largely to blame whenever modern web developers paint themselves into a corner.
Frameworks have two problems — they don’t scale beyond a certain point and, much worse, they trap you inside the framework. Frameworks are optimized for the generic, which is why they work for so many sites. But as those sites grow, they need specific solutions, not generic ones. Django, Ruby on Rails and other frameworks are great ways to get up and running quickly. But over time, as your site grows, the “Twitter moment” eventually arrives when, as Kaplan Moss says, “all hell breaks loose.” You’ve outgrown your framework and you’re screwed.
If you were an outsider looking in, it would seem logical to assume that if Ruby on Rails were letting you down in some place — say the concurrency problems that plagued Twitter — you could simply swap out that chunk of code for another written in Haskell, Erlang or another language optimized to solve concurrency problems. Sadly, that idealized vision of web development bears no resemblance to reality. Where we web developers find ourselves right now, there’s simply no way to easily write a part of your site in Django, a part in Rails and part in Erlang.
What’s the solution? Well, there may not be one. But if one does exist, it most likely involves taking a major leap and leaving monotheistic frameworks behind.
Kaplan-Moss is at heart a Python fan, so he wants the solution to come from Python. And indeed, Python does have quite a history as a “glue” language. Desktop and game developers have long written the performance-critical parts of their applications in C++ or Java, then used Python to tie together the higher-level customization tasks.
Something similar might be possible on the web — using Python to tie together Haskell, Erlang, Ruby and other languages. The problem is that we’re a long way from any solution — Python-based or otherwise — and the web is continues to grow both in size and, with HTML 5, complexity.
It’s true that most sites are small enough that they’ll never have to face the sort of traffic and scale woes that Twitter, Facebook and Google have had to deal with. But it is precisely the edge cases of high-traffic sites that have created many of the tools we have to day — Twitter, Google and others are the crucible in which all our current tools are truly tested and from which — ideally — new solutions will emerge.
While the average web developer might not face the sort of challenges those sites do just yet, the potential solutions will affect all of us and, hopefully, make the web development suck just a little less.
Until the code showed up on Github though, the Tr.im announcement was, well, just talk. But now you can grab a copy of the code and start exploring. At the moment, the Github page has the first two modules for tr.im. The final tr.im website module will be released in a few days.
The tr.im developers caution that the authentication and login system needs to be updated, and some bug fixes need to be applied as well. However, if you’re impatient and you’d like to start digging into how the tr.im code works, what’s available now should get you started.
The tr.im blog also says that final steps are in motion to donate the tr.im domain name to a third party that will hold it in trust for the sole use of the tr.im project.
When Facebook acquired FriendFeed back in August, the big question was, what would Facebook do with FriendFeed? While that question remains up in the air, Facebook has done something with the code that powers FriendFeed, namely, released it as an open source framework.
Tornado, as the new, Python-based web framework is known, is designed specifically to handle the massive server loads of FriendFeed’s real-time updates. By releasing Tornado as open source, Facebook is giving developers a way to use FriendFeed’s core infrastructure in their own real-time web projects.
While most large scale web services, for example Twitter, have had trouble scaling as their user base grows, FriendFeed managed to avoid most of those problems, which makes Tornado all the more appealing to developers looking to build the next generation of real-time web apps.
Under the hood Tornado looks a bit like other Python frameworks such as Django or web.py, but specializes in handling concurrent connections — the sort of thing you need to build a news aggregator, real-time chat app or your own version of FriendFeed or Twitter.
The FriendFeed developers have benchmarked Tornado handling over 8,000 requests per second when run as four load-balanced processes (behind Nginx) on a four core server. Compare that to Django, which can handle only about 2200 requests per second on the same hardware setup. Tornado’s impressive capabilities are the result of its non-blocking architecture and its use of epoll to handle thousands of simultaneous standing connections
Tornado also comes with all the basic building blocks you’d typically need for a social network site — user authentication, cross-site request forgery protection, templates, signed cookies, localization, aggressive static file caching and more.
Tornado follows in the footstep of web.py and Django as a loosely coupled framework — you can use only what you want and mix in other Python libraries as the need arises. In other words, Tornado is not an all or nothing framework.
So what can you do with Tornado? Well, if you’re developing any sort of real-time web app we strongly suggest giving Tornado a look. While it seems that at a certain point just about any framework will fail and you’ll be forced to write a custom solution, Tornado’s real-world experience at FriendFeed means that it may well get you farther down the path to becoming the next Twitter than most frameworks.
The creator of some of our favorite mashups is back with an awesome new creation: Delicious TV.
Tony Hirst, whose previous creations include map-oriented mashups that turn Google Maps into a blogging tool or even a geo-calendar, has created a way to send your Delicious video bookmarks on to Boxee.tv.
The result is Boxee playlist you can easily update simply by bookmarking a video and adding a specific tag.
Hirst’s tool uses Yahoo Pipes to then parse through the resulting Delicious RSS link and create a playlist in a format Boxee can understand. The results show up in a Boxee playlist like the one pictured above.
There are some caveats to keep in mind, namely that only certain videos sources will work. But if you’ve been looking for an easy way to get web video over to your television, Hirst’s Delicious TV is a slick and easy way to do it.
Check out Hirst’s Delicious TV write up for full instructions on how to make it work (naturally you’ll need to have Boxee installed and a Delicious account).
Now, you can do the same crazy user interface stuff Google does on sites like Gmail and Google Docs on your own website.
Developer Mark Pilgrim has posted a fascinating look at how the HTML 
The developers behind the 
Yahoo has announced the official release of version 3 of its open-source Yahoo User Interface (YUI) library. The new framework is designed to simplify the process of building complex web interfaces.
Tr.im, the popular URL-shortening service for Twitter and other social networks has 
When Facebook 
The creator of some of our favorite mashups is back with an awesome new creation: 
