ENTRIES TAGGED "browser"

The Web is eating software

Web technologies have become the default, and are spreading

photo: KF - http://en.wikipedia.org/wiki/User:KF/DetailsA few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:

Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.

That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).

Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.

On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.

Read more…

Comments: 2 |

Why polyfills matter

The changing landscape of web platform extensibility

From its nascent days, the growth of the web has been marked by the waxing and waning of technologies, frameworks and ideas. Old ideas and technologies expire and fade away, and new ones arise in their place. Much as the cicada molts and leaves behind an old shell as it moves into adulthood, the web has seen countless ideas come and go as it has evolved.

Relics (and Catalysts) of the Web

Remember XHTML? More specifically, do you remember caring deeply about XHTML? You likely do. Do you still care about XHTML? Chances are, the answer is no. The same goes for Flash, DHTML, HTML Components and countless other buzzwords of the web that once felt so alive and important, and now feel like relics of another time.

Occasionally, however, we collectively stumble upon ideas and technologies that stand the test of time. These are ideas that don’t just evolve with the web–they are often a catalyst for the evolution of the web itself. Ideas like Cascading Style Sheets and XMLHTTPRequest, the vendor hack that spurred the AJAX revolution, are two examples among many.

Read more…

Comment |

Building rich web UIs with knockout.js

Live coding a shopping cart and other rich web UI goodness

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Microsoft’s Steve Sanderson gave a tight 20 minute introductory tour of Knockout.js, a popular JavaScript UI library built around declarative bindings and the Model-View ViewModel (MVVM) pattern.

In his talk, Rich Web UIs with Knockout.js, Steve quickly summarized the problems Knockout solves and why Knockout is a particularly strong candidate to solve those problems, before working on a shopping cart example to show off how bindings, including custom bindings, work within Knockout.

Some key parts of Todd’s talk include:

  • A description of the problem Knockout solves [at 00:41]
  • What is Knockout and MVVM? [at 01:38]
  • 4 unique things about Knockout [at 03:12]
  • Live coding a shopping cart [at 06:02]
  • Summary [at 20:15]

Anyone with a further interest in Knockout should check out the project’s homepage and particularly the live Hello World example and interactive online tutorial which guides you through building a Web UI using the MVVM pattern with Knockout.js in an interactive sandbox-style environment.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment |

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…

Comment |

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.

Comment |

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…

Comment |

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…

Comment |

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…

Comments: 62 |