Better Web Templating with AngularJS 1.0

By Miško Hevery, Google AngularJS team

AngularJS lets you write web applications as if you had a smarter browser.  It lets you extend HTML's syntax to express your application's components clearly and succinctly and lets use standard HTML as your template language.  And it automatically synchronizes data from your UI (view) with your JavaScript objects (model) through 2-way data binding.

Today we are announcing the 1.0 release of AngularJS.  We’d like to thank our early adopters, and we’re excited to share it with you who haven’t yet experienced it.

Our goal with AngularJS is to eliminate the guesswork in creating web app structure and take the pain and the boilerplate out of web client apps.  We think we’re there and we’d love for you to take a look.

AngularJS’s core features are:

• Unobtrusive data binding. AngularJS automatically moves data from the UI to your model and back whenever either of them change.  There are no classes to inherit from, and no wrapper or getter/setter methods to call. Your model can be as simple as a as primitive, native array or as complex as you make it via your custom JavaScript type.
  
  
• HTML as the template. You, your browser, your editors and your other tools already know all about working with HTML.  Why introduce something else?  AngularJS lets you expand HTML’s vocabulary with your own app-specific elements, attributes, and class-types that are fully compatible with the HTML specification.
  
  
• Reusable components -- in HTML! AngularJS gives you the power to extend HTML’s syntax with your own elements, attributes that adds behavior or transforms the DOM.  Want to write <tab>, <calendar>, or <colorpicker> instead of <div><div><div>...?  Want to attach keyboard shortcuts to any element by adding an attribute like key=’ctrl-s’?  You miss the <blink> tag?  All these things and more are possible.
  
  
• Views and Routes. AngularJS lets you switch sub-views in your app with a simple route configuration.  And you get URL deep-linking for free.
  
  
• Tests and Testability. Shipping apps means testing them.  We provide common mocks, we take full advantage of dependency injection, and we encourage MVC structure making it easy to test behavior separate from view. It also comes with an end-to-end scenario runner which eliminates test flakiness by having the runner truly understand application state.

Come and check out our many examples, tutorials, videos and our API docs at angularjs.org.  And we’d love to hear your thoughts and questions on Google+ or on our mailing list.

Miško Hevery is a software engineer on the AngularJS team in Mountain View, CA.  Miško focuses on imagining a future where web development is actually simple.

Posted by Ashleigh Rentz, Editor Emerita

Chrome Extensions for Web Development

The Chrome Developer Tools are great for debugging HTML, JavaScript and CSS in Chrome. If you're writing a webpage or even a web app for the Chrome Web Store, you can inspect elements in the DOM, debug live JavaScript, and edit CSS styles directly in the current page. Extensions can make Google Chrome an even better web development environment by providing additional features that you can easily access in your browser. To help developers like you, we created a page that features extensions for web development. We hope you’ll find them useful in creating applications and sites for the web.

For example, Speed Tracer is an extension to help you identify and fix performance issues in your web applications. With Speed Tracer, you can get a better idea of where time is being spent in your application and troubleshoot problems in JavaScript parsing and execution, CSS style, and more.

Another useful extension is the Resolution Test that changes the size of the browser window, so web developers can preview websites in different screen resolutions. It also includes a list of commonly used resolutions, as well as a custom option to input your own resolution.

With the Web Developer extension, you can access additional developer tools such as validation options, page resizing and a CSS elements viewer; all from an additional button in the toolbar.

Another extension you should check out is the Chrome Editor that allows you to easily code within your browser, so you don’t have to flip between your browser and code editor. You can also save a code reference locally to your computer for later use.

These are just a few of the extensions you can find in our extensions for web development page. You can also look for more in the extensions gallery.

By Koh Kim, Google Chrome Team

Introducing Google Doctype

By Mark Pilgrim, Google Code Team

The open web is the web built on open standards: HTML, JavaScript, CSS, and more. The open web is a beautiful soup of barely compatible clients and servers. It comprises billions of pages, millions of users, and thousands of browser-based applications. You can access the open web with open source and proprietary browsers, on open source and proprietary operating systems, on open source and proprietary hardware.

Google has built its business here, on the open web, and we want to help you build here too. To that end, we are happy to announce the formation of an encyclopedia for web developers, by web developers: Google Doctype.

In its current (beta) form, Google Doctype contains dozens of articles written by top Googlers on topics important to all web developers: security, performance, caching, DOM manipulation, CSS styling, and more. It contains over 8,000 lines of JavaScript code: Google's own battle-tested JavaScript library, released today under a liberal open source license. And it contains the beginnings of a test-driven reference of the open web: a reference of every element, every attribute, every DOM method, every CSS property, all backed up by test cases.

Well, not quite every property; at least, not yet. We're still working on filling in a few of the details about the world's largest development platform ever, and we need your help. And so we humbly offer this fledgling encyclopedia under a Creative Commons Attribution license, and we invite the web developers of the world to contribute to it. Sign in with your Google account and edit any page, any article, anywhere. Create new ones, update old ones, and help expand the world's understanding of the open web.

Optimisation data for HTML5 parser implementors

By Ian Hickson, editor of the HTML5 specification

Last month, just before I left on vacation, I posted three sets of data to help implementors of the HTML5 parser specification optimise their code. There are several implementations coming along, for example those that are part of the html5lib project and the one behind Validator.nu.

The three sets of data that I posted are all derived from parsing several billion documents from Google's Web search index using a parser I wrote in Sawzall.

The first set of data gives the relative aggregate distribution of invocations of the "in head", "in body", and "in table" insertion modes, for each of the insertion modes. This allows implementors to determine, for instance, that invoking the "in body" code while in a cell must be very efficient, while invoking the "in body" code from the "after frameset" code need not be as efficient, in case the implementor has a strategy that optimises one at the cost of another. See: documentation, data.

The second set of data gives the relative aggregate distribution of tokens for each phase/insertion mode pair. This can help implementors that are using a cascade of if statements decide on the right order for their statements. For instance, the most common token type seen in the "in body" insertion mode is character data, and the second most token is the start tag token for an a element, but the isindex start tag was almost never seen. This tells implementors that they should check for characters and a start tags long before checking for isindex tags. See: documentation, data.

The last set of data examines the number of attributes per element. It allows implementors to decide on the optimum memory allocation strategy for attributes. For example, since most elements have 9 or fewer attributes, the data structure that stores attributes can be optimised for simply having 9 attributes, using little memory, and if an element has more than this number of attributes, the implementation can switch to a separate implementation that is more memory-heaving but is optimised for large numbers of attributes. See: data.

I hope this data is useful!

Interview with Ian Hickson on X/HTML 5

Posted by Dion Almaer, Google Developer Programs

What is more important to the future of the web than the future of HTML, and adoption of technology in the browsers? Our own Ian Hickson has been blazing a trail under the WHATWG umbrella, as he tries to do the right thing, and standardize what is already being down, instead of making a specification in an isolated room.

Back in 2005, Ian conducted a comprehensive, detailed analysis of how markup is used on the Web which gives his real world metrics to go by.

Vlad Alexander from xhtml.com was invited to post a series of questions to the X/HTML 5 team on their public mailing list, and recently published their Q & A session.

If you haven't stayed up to date on what is happening around the standards, take a peek to see how the team answered questions such as:

• Why do we need X/HTML 5? When did this need become apparent?
• X/HTML 5 is currently in Working Draft stage. What is the tentative timetable for moving X/HTML 5 through the standards approval process towards Recommendation stage?
• X/HTML 5 introduces new markup constructs such as sectioning elements, enhancements to the input element, a construct for dialogs, a way to mark up figures, and much more. Can you briefly describe these new constructs and the reason they were added?
• X/HTML 5 has a construct for adding additional semantics to existing elements using predefined class names. Predefined class names could be the most controversial part of X/HTML 5, because the implementation overloads the class attribute. XHTML 2 provides similar functionality using the role attribute. Which approach is better and why?
• Is it due to a flaw in HTML that it is difficult to build authoring tools, such as WYSIWYG editors, that generate markup rich in semantics, embody best-practices and that can be easily used by non-technical people?
• Since much of the content on the Web is created using such authoring tools, can we ever achieve a semantically rich and accessible Web?
• The XHTML 5 spec says that "generally speaking, authors are discouraged from trying to use XML on the Web". Why write an XML spec like XHTML 5 and then discourage authors from using it? Why not just drop support for XML (XHTML 5)?

The full writeup can be read here.