"html" entries

Build Reusable Widgets for the Web with Polymer and Dart

Don't wait for browsers to implement Web Components, try them today

Web Components, the family of new web specifications for reusable and encapsulated widgets, are coming to a browser near you. Thanks to Polymer, a new type of library for the web built on top of Web Components, and Dart, a new structured language and libraries for modern web development, you can build custom HTML elements that encapsulate style, structure, and behavior.


I’m personally a fan of Polymer.dart, a Dart port of Polymer. If you want to use JavaScript, you can use the original Polymer library, though some of the details are different. Both Polymer and Polymer.dart are under heavy development, and the engineers behind the projects are looking for feedback.

In this article, I’ll show you how to build a simple auto-complete widget as a custom element. As a user types into a field, a list is searched by prefix. The user can keep typing for a more exact match, use up and down to select, or use their mouse.

Read more…

Comments: 2

From “Web Development” to the “Web Platform”

Defining a powerful toolkit

The rise of the phrase “web platform” over the past few years makes me very happy.

For years, I’ve been looking for a good term that would cover HTML, CSS, JavaScript, and a few related technologies. The terminology has long been tricky, as the mostly-forgotten “webmaster” broke into smaller pieces: “web designer”, “web developer”, and sometimes “web administrator”. (Some web administration faded into general system administration, while other aspects have grown into their own discipline of web operations.)

Read more…

Comments: 4

Walking Trees and Handling Events

The core of web programming, in JavaScript and beyond

This summer, I’ve seen all kinds of programming approaches as I’ve bounced between the Web, XSLT, Erlang, and XML, with visits to many other environments. As I look through the cool new possibilities for interfaces, for scaling up and down, and for dealing with data, I keep seeing two basic patterns repeating: walking trees (of data or document structure), and handling events.

Walking trees can be annoying, to put it mildy. The Document Object Model (DOM) is famously a headache for JavaScript (and other) developers. There are obvious opportunities for advanced developers to focus on graphs and other more flexible data structures as well. Trees are not necessarily the most efficient way to store information, especially when their content changes regularly.

Read more…

Four short links: 16 August 2013

Four short links: 16 August 2013

Robo Regex, Crappy Code, HTML5 Parsing, and Play v App Numbers

  1. fraktransforms collections of strings into regular expressions for matching those strings. The primary goal of this library is to generate regular expressions from a known set of inputs which avoid backtracking as much as possible.
  2. The Boolean Trap — crappy APIs where true/false don’t mean what they seem. None of this is new, but every generation has to learn it anew. (via Pete Warden)
  3. Gumbo — open source pure C HTML5 parser.
  4. All Those People With Cheap Android Phones Have Started Buying Apps (Quartz) — revenue generated by the Google Play Store, from which many Android users get their apps, has grown 67% over the past half-year. By contrast, Apple’s App Store revenue grew 15%, according to Distimo estimates, which cover the top 18 countries. That sounds less impressive if you consider that the App Store brought in twice as much revenue in absolute terms. But the numbers are shifting fast. In February, the App Store was generating three times as much revenue, and last November it out-earned Google Play by a factor of four. Google is gaining.

Using XSLT 2.0 as a Web Scripting Language

Stunning JavaScript implementation suggests more is possible

A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.

That’s JavaScript, all right—but now, thanks to JavaScript, it is also XSLT. After all the discussion I heard about templates and JavaScript at Fluent and OSCON, starting with a language built on templates seems like a better and better option.

Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.
Read more…

Comments: 6

Can Markup Unite?

Getting past the HTML / XML splits

A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.

Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.

Line at Balisage

Read more…


A Birds-eye View with Lift

Organize and control content with the Lift web framework

Lift is a web framework built for the Scala programming language, running on the Java Virtual Machine. Version 2.5 recently shipped, and I’m highlighting features of the framework that I find appealing.

Last time it was transforms and REST services, and this time it’s two features around organizing and controlling access to content.


How do you manage the HTML pages on site? Maybe some pages are available to everyone, others require login or some condition for access, and often pages are grouped in some way. Lift has an optional mechanism for expressing all this in one place, and it’s called SiteMap. This is how it looks in code:

We’ve defined a site made up of a home page, and pages for poets we like. Why is this a good thing?

First, it’s a pretty readable representation of the site in (compiler checked) Scala code. You can probably figure out that we have a page called “home” found at /index.html (or / as it’s usually known).

What might not be obvious is that Menu.i is using “home” as a key into your translation resources, meaning the link text will be the localized version—if you’re building an internationalized site. The link to the page can be generated by a Menu.builder, a snippet you can use on pages to give your users navigation of the SiteMap.

The second menu item is called “poets,” served up from a template called list.html. On the home page, the navigation snippet would give you a link to the “poets” page, but by default is smart enough to hide the submenus until you visit the list of poets.

SiteMap also performs access control: if you use SiteMap, HTML pages have to be listed in it to be accessed. It’s a simple line of defense, but you can improve on this by adding location parameters. These are rules for controlling access to a page.

Let’s say we wanted to only offer some content to customers paying for our premium plan:

This is an if-then-else construct, made up of two functions. The first function is a test for what qualifies as a premium customer. It’s an arbitrary computation, and in this example it’s false, meaning nobody is a premium customer (in reality, we’d perhaps check a property of the logged user). If you nevertheless try to get to the page, the second function kicks in, and you’d be sent to our store front.

We can apply the “premium customer” rule to any part of the site, but we’re going to just restrict Tennyson poems:

If you don’t like the >> method name, use rule instead. If you just don’t like this domain specific language (DSL), you can construct a SiteMap in longer-form method calls.

What’s great about SiteMap is the flexibility it gives you: if you can’t get the behavior you want out of the box, you can write custom functions and classes, and drop them into the SiteMap. If you want menus displayed in a completely different way, not handled by Menu.builder customization, you can write a different navigation snippet. Location parameter rules allow you to isolate logic, and combine them as needed to parts of your site.

Read more…


JavaScript Is Way Too Slow – for What?

There's more to mobile web apps than JavaScript

I keep finding that programmers—even web programmers—frequently think “web application” means “JavaScript application.” Programmers are, of course, used to working with programming languages, and often see application environments from the perspective of the programming language in use.

These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:

JavaScript is too slow for mobile app use in 2013 (e.g., for photo editing, etc.).

Do we need to run Photoshop on our mobile phones using JavaScript underneath? I agree that cramming everything into an interpreted language on a memory-, processing-, and bandwidth-constrained device is a stupid idea—but “photo editing” is an extreme case, to put it mildly. Perhaps critics will move on to video editing when we eventually get to the next round.

Despite that flaw, if the rant had been titled “Why mobile JavaScript apps are slow,” it would have done better. His lists of benchmarks, discussions of processor challenges, and recognition that the easy work in JavaScript optimization is already done, are all tremendously useful. There is little reason to expect JavaScript performance to improve in the future at the rate is has achieved for the last decade.

It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding querySelector to the DOM was a massive one-time speed upgrade, letting JavaScript developers drop most of their tree walking in favor of a more declarative approach relying on native code in which vendors had already invested heavily.

So how can we optimize mobile web development?

The first answer is pretty simple: don’t try to use JavaScript for tasks (like photo or video editing) that push it past its limits. As far as JavaScript has come, it wasn’t built for that. Native apps are indeed good for more than building browsers.

The second answer is trickier: it means recognizing that web applications include much more than JavaScript. JavaScript began as a scripting language for gluing together objects written in other languages, and it still excels at that. Build your application from the HTML—the easiest stuff to process!—up. (If you want graphics, SVG might be a better path.) Then layer CSS on top of that. Rely on APIs built into the browser whenever you can, using JavaScript to connect with their much faster processing. HTML5 keeps making that a better and better option.

When I was programming our HTML 4 & 5: The Complete Reference, I marveled regularly at how tasks that seemed huge, like loading a new CSS stylesheet, moved rapidly compared to implementing smaller changes using JavaScript. More broadly, Estelle Weyl’s JavaScript: You Don’t Need a Framework For That (slides) resonates both because it shows how to use smaller chunks of JavaScript and because it explores how to use CSS creatively to avoid using JavaScript at all.

Building great applications using JavaScript, especially great mobile web applications, often means using JavaScript itself as sparingly as possible. That’s always been a feature of JavaScript, not a bug.

Comments: 28

Safe and Sane Windows 8 Programming Experiences with HTML and JavaScript

Windows 8 is mostly about touch.

There was a time, some fifteen years ago, when the choice of the programming language was a delicate decision. It stopped being a problem when .NET arrived. Because .NET languages compile to the Common Language Runtime, .NET compatible languages became more or less indistinguishable other than syntactically, and developers could happily mix Visual Basic with C# and even JScript.

The JScript language you could use to build plain .NET applications was simply a programming language with syntax close to JavaScript. Choosing JScript didn’t mean you were going to write .NET applications following the web metaphor.

In Windows 8, things are different.

A Windows 8 application runs on top of a new runtime environment—called “Windows Runtime” or WinRT for short. WinRT is a modernized and redesigned version of the .NET Common Language Runtime. You can write a Windows 8 application using C#, Visual Basic, or C++ for the logic and XAML for the layout. In doing so, you can take advantage of patterns that are made-to-measure for XAML, such as the Model-View-View-Model pattern (MVVM). In this regard, developing for Windows 8 is not that much different from developing for Silverlight or Windows Phone.
Read more…


From JavaScript to Declarative Markup

Evolving enhancements for web developers

Web architecture separates structured content (markup), presentation (style), and behavior (JavaScript). As recently as a decade ago, many developers worked in all three, but the years since Ajax arrived have brought more specialization. The rise of JavaScript in particular has led to approaches that have JavaScript carry the load. In the past few weeks, I’ve been delighted to see work that suggests a different path forward, one that takes greater advantage of the flexibility markup offers.

Last week, at the Artifact Conference, I was delighted to return to the world of web designers. The crowd was full of people who know very well what JavaScript can add to their site and how they want to include it, but who don’t focus on it. JavaScript is just a tool, often even a tool wielded later in the process after the basic framing of the site is complete.

Read more…