ENTRIES TAGGED "html"

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

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…

Comment

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.

SiteMap

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…

Comment

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…

Comment

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…

Comment

JavaScript Flexibility: Fun, But Use with Care

JavaScript is dynamically typed

When you begin programming in JavaScript, you’ll need to use variables. A variable is just a bit of storage to hold a value. Just about every line of code you write will use a variable of one kind or another, so it’s a good idea to get familiar with the kinds of things you can put in variables, and how you can use them. Now, if you’re coming from another programming language, like Java, you might be surprised to see how loose JavaScript is about variables and their type. JavaScript doesn’t care if your variable starts out with a string value, and ends up being a number: JavaScript’s dynamically typed.

In this installment of Head First JavaScript Programming Teasers, you’ll learn about the basics of variables, how JavaScript is dynamically typed, and why it’s a good idea to stick with one type for your variables.

Comment

JavaScript Makes Browsers Behave

Start adding functionality to your HTML and CSS with JavaScript

If you know HTML and CSS, you’re ready to begin learning JavaScript. But you might be surprised, because JavaScript looks quite different from both HTML and CSS. That’s because JavaScript is a language for computation. Unlike HTML, which is for marking up content to add meaning and structure to that content, and CSS, which is a set of declarative rules for adding style to selected elements, JavaScript is for describing computation: it’s a language for describing how things get done.

A JavaScript program consists of a series of statements, each of which does a little bit of computation. A statement might store some data in a variable, or modify data with an expression, or make a decision about what to do based on the value of a variable, or even tell the browser to do something, like pop up an alert.

Want to know more? In part four of Head First JavaScript Programming Teasers, Eric shows you how JavaScript is different from HTML and CSS, and why. He also steps you through a simple example of JavaScript code, so you can get a taste of how it works.

Comment

Cutting Your Programming Teeth on JavaScript

Why it's a great first programming language

JavaScript is a bit different from other programming languages. How? Well, JavaScript runs in an environment, and that’s usually the browser. So when you learn JavaScript, you’ll learn both the language basics, as well as how to use JavaScript in the browser to do things like interact with the page, add and remove elements, draw graphics, or store data locally in the browser.

Another way that JavaScript is a bit different is that it’s so easy to get started with: all you need is a basic text editor and a browser, and you’re ready to go. This also makes JavaScript a great first language. For instance, the fact that you can run JavaScript in the browser means you have a built-in, easy way to see your results, and you can create and interact with a web page interface, without having to write a huge amount of code.

We’re designing Head First JavaScript Programming so that you can learn JavaScript, from scratch, even if you’ve never programmed before. All you need is just some background in HTML and CSS. If that’s where you’re coming from, and you’re itching to learn how to program, check out part three of Head First JavaScript Programming Teasers, where we step you through what makes JavaScript unique, and why it’s a great first programming language.

Comments: 2