"browser" entries

pushState to the future: progressive enhancement using HTML5 pushState at Twitter

Fluent is O’Reilly’s conference dedicated to the Web Platform and all that entails, with a focus on JavaScript and HTML5. In 2013, over 1000 attendees and speakers like Brendan Eich, the creator of JavaScript and CTO of Mozilla, Paul Irish of Google, and CSS guru Lea Verou came together to learn, share, and network.

One speaker at Fluent 2013 whose talk was particularly well received was Todd Kloots of Twitter who spoke about HTML5’s pushState API and demonstrated how it was used in Twitter’s Web-based interface.

Some key parts of Todd’s talk include:

  • The opportunity Twitter saw in pushState [at 01:45]
  • What you had to do with dynamic URLs before pushState [at 02:46]
  • A summary of the pushState API [at 06:10]
  • Gotchas and browser support [at 07:58]
  • How pushState sped up navigation on Twitter.com without re-architecting [at 12:15]
  • What Twitter had to do server-side to make progressive enhancement work [at 19:11]
  • Final thoughts [at 31:37]
  • Q&A [at 32:15]

Read more…

Toward Responsive Web Programming

Creating flexible expectations

“Expect the unexpected” has long been a maxim of web development. New browsers and devices arrive, technologies change, and things break. The lore of web development isn’t just the technology: it addresses the many challenges of dealing with customers who want to lock everything down.

Matt Griffin (and a lot of others) reminded me of these difficulties at Artifact, and his Client Relationships and the Multi-Device Web brings it home for designers.

Is there room for programmers to tell a similar story?

I don’t mean agile. Agile development is difficult enough to explain to clients, but applications that adapt to their circumstances are a separate set of complications. Iterating on adaptable behaviors may be more difficult than iterating on adaptable designs, but it opens new possibilities both for applications and for the evolution of the Web.

Responsive Web Design is (slowly) becoming the new baseline, giving designers a set of tools for building pages that (usually) provide the same functionality while adapting to different circumstances. Programmers sometimes provide different functionality to different users, but it’s more often about cases where users have different privileges than about different devices and contexts.

Adjusting how content displays is complex enough, but modifying application behavior to respond to different circumstances is more unusual. The goal of most web development has been to provide a single experience across a variety of devices, filling in gaps whenever possible to support uniformity. The history of “this page best viewed on my preferred browser” is mostly ugly. Polyfills, which I think have a bright future, emerged to create uniformity where browsers didn’t.

Browsers, though, now provide a huge shared context. Variations exist, of course, and cause headaches, but many HTML5 APIs and CSS3 features can work nicely as supplements to a broader site. Yes, you could build a web app around WebRTC and Media Capture and Streams, and it would only run on Firefox and Chrome right now. But you could also use WebRTC to help users talk about content that’s visible across browsers, and only the users on Firefox and Chrome would have the extra video option. The Web Audio API is also a good candidate for this, as might be some graphics features.

This is harder, of course, with things like WebSockets that provide basic functionality. For those cases, polyfills seem like a better option. Something that seems as complicated and foundational as IndexedDB could be made optional, though, by switching whether data is stored locally or remotely (or both).

HTML5 and CSS3 have re-awakened Web development. I’m hoping that we can develop new practices that let us take advantage of these tools without having to wait for them to work everywhere. In the long run, I hope that will create a more active testing and development process to give browser vendors feedback earlier—but getting there will require changing the expectations of our users and customers as well.

Securing User Content in the JavaScriptable Web

OSCON 2013 Speaker Series

Recent work by a W3 Working Group plans to expose many powerful cryptographic operations for web applications. Although the planned API adds much needed functionality to JavaScript, it doesn’t address the JavaScript runtime’s terrible security properties. For instance, any script running in the web application has the power to hijack the web app’s content and UX. Just last February a mistake in Facebook’s “like” button brought down millions of web sites. Further, if you are an online service provider wanting to support higher privacy use cases like encrypted chat or web-based PGP email, the trust model is fundamentally broken since you can’t serve cryptographic JavaScript code without making the server a potential attack point.

The security challenges faced by JavaScript are mitigated by Privly, also labeled “the Web Privacy Stack,” by addressing two issues: (1) scoping code to the data, and (2) pre-distributing the code to the clients when possible.

Scoping Code to the Data

Every website has its own navigation structure, layout, and audience, but when you strip away these unique attributes of websites, you are left with data– chats, emails, photos– that can be treated uniformly across all websites. Operations on these data like encryption and signing, can be performed with indifference to their context and their contents.

Privly uses data indifference to create the notion of “Injectable Applications,” which are full web applications that are injected into the context of other web application. Since these applications are scoped to data and not layout, their properties are simplified and usable across the web.

Privly works within browser extensions by scanning web pages for specially formatted hyperlinks. When the extension detects the hyperlink, it “injects” the link into an iframe that is served locally from the browser extension.(footnote 1: This is currently how the Chrome extension performs, but different platforms are at different levels of sophistication. This approach can be universally applied to all platforms and does not necessarily require locally-served JavaScript code. However, without serving the JavaScript code locally, the security properties of the system are lost) Since the injected application is a full web application, the app could potentially support any web-implementable feature, including APIs between the host page and the injected application.

In short, if you scope an application to the data, then the cryptography can be viewed in potentially untrusted contexts.

Pre-Distributing Client Code

Privly creates an ecosystem of apps with known properties because it allows us to reason about security uniformly across the web. However, security is only as strong as the weakest attack point, which is why great care must be taken to appropriately distribute these applications. By packaging a set of applications for integration into browser extensions and mobile apps, the code is not re-loaded from a remote source every time the browser loads a new page.

Requiring the pre-distribution of applications is not normally compatible with the free and open internet. However, pains must be taken to realize the differences between the limited use cases of injected applications, and the general cases supported by web applications in general. Distributing every website to the client before visiting a website is impossible, but distributing a set of general injectable applications is lightweight and perhaps the only way to achieve security within the modern JavaScript runtime.

Requiring users to install an extension before they can view content is likely an impediment for any security system looking to gain users. However, since Privly uses hyperlinks to reference the content, it provides opportunity for a hosted fallback application. Depending on the nature of the injectable application, clicking the hyperlink could either present the same application as normally delivered by the extension, or present a prompt to install the appropriate browser extension.
Read more…

What Kind of JavaScript Developer Are You?

Fault lines make conversation difficult

“JavaScript developer” is a description that hides tremendous diversity. While every language has a range of user skill levels, JavaScript has a remarkably fragmented community. People come to JavaScript for different reasons from different places, and this can make communication difficult. Sometimes it’s worse than that—not everyone likes everyone else.

“JavaScript developer” used to mean “web developer,” specifically a developer who spends a lot of time working in the browser. Even as JavaScript became a specialty of its own, most JavaScript developers came through a broader web practice first, learning HTML and CSS before tackling the DOM. This was my path, and is still a common one. It was reasonably easy to absorb JavaScript by example, using it as an object manipulation language before pushing into the harder corners.

Many programmers, however, started on the server-side, building code that filled templates. Server-side JavaScript existed, in the Netscape Enterprise Server, for example, but was a tiny fraction in a world dominated by Perl, Java, Python, Ruby, and ASP’s languages. Developers who spent most of their time writing code that ran on the server worked with a different set of tools and expectations, and had to shift gears as JavaScript became a more critical part of web applications. (Some of these developers generate a lot of JavaScript—JSON is, after all, JavaScript—but would prefer to think of JavaScript’s role in that as an accident.)

Another group of developers came from desktop applications, and expected more direct control over the interface. Many of these developers now understand JavaScript because the browser forces them, not because they want to.

Involuntary JavaScript creates a tremendous amount of tension around the language. Normally, the people who dislike a programming language can just work with something else. JavaScript’s browser dominance makes that hard.

Other developers, though, are much much happier and much deeper into JavaScript. The JavaScript revival that became visible with the rise of Ajax in 2005 gave the language greater credibility. Douglas Crockford’s work “Unearthing the Excellence in JavaScript,” JavaScript: The Good Parts demonstrated a powerful language lurking in a toolset many had considered trivial.

Over the past decade, JavaScript’s power and reach have grown thanks largely to a core group of developers whose focus on the language has created best practices and frameworks, while driving browser vendors to improve their implementations. Node.js emerged from this work, giving JavaScript a unique server-side framework that deeply reflects the language.

Read more…

Stop standardizing HTML

It's time for developers to create their own vocabularies

When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it’s time to stop worrying about this central core and let developers choose their own markup vocabularies and processing.

When the W3C first formed, it formed around HTML, the core standard of content on the Web, defining the structure, appearance, and behavior of content. Over the next few years, however, it became clear that HTML was doing too much, and the W3C and other groups refactored appearance, behavior, and many semantics into separate specifications:

  • Cascading Style Sheets (CSS) took responsibility for presentation and layout.

  • JavaScript took responsibility for behavior, aided by the Document Object Model (DOM) and a variety of APIs for handling device and multimedia interactions.

  • WAI-ARIA took responsibility for accessibility semantics, ensuring that content remained available to a broad audience even if developers pushed the current boundaries of markup.

It’s not a completely neat separation – some of CSS feels like behavior, and JavaScript can manipulate presentation, for example, but it certainly took a lot of pieces out of HTML. A few aspects of HTML, notably media inclusion, are still mostly handled at the markup level, but most of them aren’t any longer. Forms and linking are both still defined in HTML itself, but aren’t difficult to implement separately.

Read more…

Four short links: 1 February 2012

Four short links: 1 February 2012

The Invention-Commoditisation Cycle, Software Estimations, Fullscreen Browser API, and File Formats in Javascript

  1. Cycles of Invention and Commoditisation (Simon Wardley) — Explosions of industrial creativity rarely follow the invention or discovery of a technology but instead its commoditisation i.e. it wasn’t the discovery of electricity but Edison’s introduction of utility services for electricity that produced the creative boom that led to recorded music, modern movies, consumer electronics and even Silicon Valley. However, utility provision of electricity did more than just create a new world, it disrupted existing industries (both directly and through reduced barriers of entry), it also allowed for new practices and methods of working to emerge and even resulted in new economic forms – such as Henry Ford’s Fordism. This isn’t a one off pattern. The cycle of invention/commoditisation repeats throughout our industrial history, following a surprisingly consistent pathway. Understanding this pattern is critical to anticipating the changes emerging in our industry today – whether that’s the web, cloud computing or the future changes that 3D printing will bring. Simon explains the Business of the Internet in one blog post. Simon is king.
  2. Why Are Software Development Task Estimations Regularly Off By A Factor of 2 or 3? — never a truer word spoken in parable.
  3. Using the Full-Screen API in Browsers (Mozilla) — useful! The older I get, the more I like full-screen mode. I found myself wishing my email client had it, then someone pointed out that was called “mutt in a shell window”. Fair ’nuff.
  4. File Formats in Javascript (GitHub) — pointers to libraries for different file formats in Javascript.
Four short links: 4 October 2011

Four short links: 4 October 2011

Singaporean Incubator, Oracle NoSQL, Should Facebook have a Browser?, and GitHub has Competition

  1. jfdi.asia — Singaporean version of TechStars, with 100-day program (“the bootcamp”) Jan-Apr 2012. Startups from anywhere in the world can apply, and will want to because Singapore is the gateway to Asia. They’ll also have mentors from around the world.
  2. Oracle NoSQLdb — Oracle want to sell you a distributed key-value store. It’s called “Oracle NoSQL” (as opposed to PostgreSQL, which is SQL No-Oracle). (via Edd Dumbill)
  3. Facebook Browser — interesting thoughts about why the browser might be a good play for Facebook. I’m not so sure: browsers don’t lend themselves to small teams, and search advertising doesn’t feel like a good fit with Facebook’s existing work. Still, making me grumpy again to see browsers become weapons again.
  4. Bitbucket — a competitor to Github, from the folks behind the widely-respected Jira and Confluence tools. I’m a little puzzled, to be honest: Github doesn’t seem to have weak spots (the way, for example, that Sourceforge did).
Four short links: 22 September 2011

Four short links: 22 September 2011

Feedback, Open Source Marketing, Programming in the Browser, and Twitter's Open Source Realtime Engine

  1. Implicit and Explicit Feedback — for preferences and recommendations, implicit signals (what people clicked on and actually listened to) turn out to be strongly correlated with what they would say if you asked. (via Greg Linden)
  2. Pivoting to Monetize Mobile Hyperlocal Social Gamification by Going Viral — Schuyler Erle’s stellar talk at the open source geospatial tools conference. Video, may cause your sides to ache.
  3. repl.it — browser-based environment for exploring different programming languages from FORTH to Python and Javascript by way of Brainfuck and LOLCODE.
  4. Twitter Storm (GitHub) — distributed realtime computation system, intended for realtime what Hadoop is to batch processing. Interesting because you improve most reporting and control systems when you move them closer to real-time. Eclipse-licensed open source.

If you're a content designer, the web browser will be your canvas

Peter Brantley on designing and thinking browser first.

The Internet Archive's Peter Brantley discusses the influence of web browsers on content design and the challenges of complex media.

Four short links: 22 August 2011

Four short links: 22 August 2011

Cooked Brands, HTML Bootstrap, Browser Security Headers, and Swarming Robots

  1. Cities in Fact and Fiction: An Interview with William Gibson (Scientific American) — Paris, as much as I love Paris, feels to me as though it’s long since been “cooked.” Its brand consists of what it is, and that can be embellished but not changed. A lack of availability of inexpensive shop-rentals is one very easily read warning sign of overcooking. I wish Manhattan condo towers could be required to have street frontage consisting of capsule micro-shops. The affordable retail slots would guarantee the rich folks upstairs interesting things to buy, interesting services, interesting food and drink, and constant market-driven turnover of same, while keeping the streetscape vital and allowing the city to do so many of the things cities do best. London, after the Olympic redo, will have fewer affordable retail slots, I imagine. (via Keith Bolland)
  2. Bootstrap — HTML toolkit from Twitter, includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more. Open sourced (Apache v2 license).
  3. Extra Headers for Browser Security — I hadn’t realized there were all these new headers to avoid XSS and other attacks. Can you recommend a good introduction to these new headers? (via Nelson Minar)
  4. Swarmanoid — award-winning robotics demo of heterogeneous, dynamically connected, small autonomous robots that provide services to each other to accomplish a larger goal. (via Mike Yalden)