Archive for the ‘Ajax’ Category

File Under: Ajax, Programming

Meet Go, Google’s New Programming Language

Google has released a brand-new programming language it hopes will solve some of the problems with existing languages such as Java and C++.

The language is called Go, and it was released under an open source license Tuesday. Google is no stranger to the open source world. The company has released the underlying code for several of its tools and services under open source licenses over the years. Just last week, Google released its Closure JavaScript tools for building Ajax web apps. And now Google has considerably upped its investment in free software with the release of Go, which is an entirely new programming language.

At first glance, Go looks a bit like C++, but borrows some elements, such as garbage collection, from scripting languages like Python and JavaScript. But Go’s real standout feature is its speed. A demo video shows the entire language — over 120K lines of code — compiling in under 10 seconds.

As a systems language, Go is intended to be used for developer applications like, for example, web servers. In fact, the website is being hosted by a Go program. But as Go developer Rob Pike says in recent Google Tech talk, “although Go is designed as a systems language, it has a much broader use than that.” Pike goes on to cite front-ends and other general purpose programming that Go can handle.

One of the most appealing parts of Go is its ability to handle multicore processors and, as Google’s FAQ explains, “provide fundamental support for concurrent execution and communication.”

Existing systems languages like C++ evolved long before today’s modern, and very fast, processors hit the market and make supporting multicore chips more difficult. While Google could have concentrated on writing libraries that can handle those tasks in C++, the developers behind Go say that “too many of the problems — lack of garbage collection, long dependency chains, nested include files, lack of concurrency awareness — are rooted in the design of the C and C++ languages themselves,” and decided it was time for something entirely new.

Like many of Google’s open source projects, Go began life as a 20 percent time project (the time Google gives its engineers to experiment) and evolved into something more serious. Go has been in development for over two years now, but Google is hoping that, by releasing Go under a BSD-style license, a community will develop and build Go into a viable choice for software development.

At the moment, Go is still very young and experimental. Even Google isn’t currently using Go in “large-scale production” applications. While the site that’s hosting the code is running a server built with Go as a proof of concept, the primary purpose of this release is to attract developers and help build a community around Go.

Despite its fledgling status, Go already supports many of the standard tools you’d expect from a systems language and even includes support for other Google tools like Protocol Buffers.

Also, it’s worth noting that Google’s Go is not to be confused with an existing language entitled Go! (note explanation point). Google Blogoscoped reports that Go!’s developer Francis McCabe would like Google to change the name of Go, but thus far Google has not responded to that request.

At the moment Go is only available for Linux and Mac OS. If you’d like to learn more, check out the video of Pike’s tech talk below (it’s long, but offers a pretty thorough overview of Go) or head to the new Go website.

See Also:

File Under: Ajax, Frameworks, JavaScript

Google Releases Closure JavaScript Tools For Building Slick Interfaces

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.

You can go to Google’s Code blog to read about Closure’s release, inspect the license and download the tools.

From the post:

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!

File Under: Ajax, HTML

Same as it Ever Was: The History of HTML is a Conversation, Not a Spec

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.”

See Also: