Simon St. Laurent

Simon St. Laurent is a web developer, network administrator, computer book author, and XML troublemaker living in Ithaca, NY. His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference.


You can find his writing on everything from technology to Quakerism to life in Dryden to gardening to New York State politics aggregated at simonstl.com.

Your money or your life

Microsoft, Google and pushing business models too far.

Photo by Didier, used under a Creative Commons license.I know it’s hard to run a large company. I know that organizations can get too deep into their own visions to imagine conflicting values.

I realized yesterday, though, that:

  • Microsoft ruined their brand for me by holding too tightly to things that they considered theirs. (Software.)
  • Google is ruining their brand for me by holding too tightly to things that I consider mine. (Identity, everything they can possibly learn about me.)

It’s a weird difference, but the Google version makes me much sadder about the world. As I’d tell a mugger, “You can have my wallet, just don’t take me.”

Photo by Didier, used under a Creative Commons license.

Comment

It’s the end of the web as we knew it

You might feel fine.

For the past 15 years, Google has enforced the classic “HTML as foundation” architecture at the heart of the Web. Content creators and the developers who support them had to present content and link information as part of their pages’ HTML if they wanted Google’s spidering bots to see them. Google effectively punished developers who made links or content available only through JavaScript (or images, or CSS), giving them low or non-existent search results.

Google did this to keep their processing simple, not because of a deep fondness for HTML. Even as Google’s bots stuck to a simple diet of HTML, other parts of Google were developing JavaScript-centric approaches, like AngularJS: a “Superheroic JavaScript MVW Framework” that “is what HTML would have been, had it been designed for building web-apps.”

Angular is far from alone. As JavaScript grew, more and more programmers wanted to build their apps as programs, not as pages. Or, as Jen Simmons summarized it at Fluent, “Dang that stupid HTML, I’m just going to load an empty page… then I’ll run the real program, I’ll run the JavaScript.” Read more…

Comment

Applying design values to programming

Can we create more vibrant intersections?

Design by connection by Dave Gray, on FlickrFor the past two decades, the web has been a vibrant intersection of design and programming, a place where practices from art and engineering both apply. Though I’ve spent my career on the programming side – you don’t really want to see the things I design – I’ve loved the time I’ve spent working with designers.

Much of that time was frustrating, because I was frequently stuck telling designers that no, 1990s HTML couldn’t produce page layouts like QuarkXPress. The medium was different, with its own complications. However, as designers became familiar with the web, and found new ways to apply it, the conversations became richer and richer. Front-end web development became an amazing place where designers and technicians could work (and sometimes curse) together. Read more…

Comment

Who holds your keys?

DRM makes a mash of security and privacy.

Put your books, movies, and music on a gleaming shelf. Close the door to keep the dust off. Lock the door, so no one can take it, and hand me the key. I’ll let you have the key when you need it if you promise not to share these with anyone else.

I might keep track of when you borrow the keys, and what you check in and out. You understand, of course, that it’s just data I need to collect and aggregate to keep my costs down, right? I wouldn’t want to have to charge you very much for my key-keeping service.

It’s the Deal of the Century!

Or, at least, it will be if some kinds of content publishers and distributors get their way. Terrified by the sudden collapse in the cost of duplication and distribution, locking everyone’s shelves down seems like the only way to maintain their balance (sheets). Worse, products from beyond publishing are appearing with the new key-management practices built in, including cars, coffee, and of course printer cartridges. Read more…

Comment

Who holds your keys?

DRM makes a mash of security and privacy.

Put your books, movies, and music on a gleaming shelf. Close the door to keep the dust off. Lock the door, so no one can take it, and hand me the key. I’ll let you have the key when you need it, if you promise not to share these with anyone else.

I might keep track of when you borrow the keys, and what you check in and out. You understand, of course, that it’s just data I need to collect and aggregate to keep my costs down, right? I wouldn’t want to have to charge you very much for my key-keeping service.

It’s the Deal of the Century!

Or at least it will be if some kinds of content publishers and distributors get their way. Terrified by the sudden collapse in the cost of duplication and distribution, locking everyone’s shelves down seems like the only way to maintain their balance (sheets). Worse, products from beyond publishing are appearing with the new key-management practices built in, including cars, coffee, and of course printer cartridges.

Read more…

Comment

Just fork it

Making forking the norm

Brian Kardell (вкαя∂εℓℓ)tweeted:

Kip Hamptonreplied:

Free and Open Source software licenses make forking legal. Git makes forking easy. GitHub makes it easy to fork sociably. Can we just make this normal?

The most visible recent fork – LibreSSL‘s blunt forking of OpenSSL – was widely reported as conflict. It’s certainly not a polite break, but the OpenSSL’s Apache-style license means it’s legal.

Meanwhile, in a reminder that specifications can fork too, Ian Hickson put his objections to the W3C forking a WHATWG spec on www-archive to make sure his complaints of plagiarism would be part of the permanent record. WHATWG specs are licensed CC0, so once again, it’s legal.

It seems to be a common pattern to want to grant rights, but only want other people to use those rights if they acknowledge our control. (I sometimes have similar tendencies, granted.) We hope that people will contribute to our works while recognizing our power and our ownership over those works. Even the fact that we have to choose licenses at the start of a project gives us a sense of ownership and control, often hiding the (excellent) lack of control that comes once those licenses are applied.

Read more…

Comments: 3

Fun, functional, and teachable?

Can Elixir bring functional programming to a much wider audience?

I was delighted to talk with Dave Thomas, co-founder of the The Pragmatic Programmers and author of their in-progress Programming Elixir. I’m writing Introducing Elixir for O’Reilly, and we both seem to be enjoying the progress of the language. Read more…

Comment

Can we extend the web cleanly?

The DOM and human nature create some challenges

“Design by Committee” is rarely a compliment. Can the Web shift away from that model, retaining some order without falling into troublesome chaos?

The Manifesto

Part of the excitement around the Extensible Web Manifesto was that it wanted to move the Web to more of an evolutionary model:

We aim to tighten the feedback loop between the editors of web standards and web developers.

Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.

Read more…

Comment

The power of HTML

Acknowledging the source of the Web's strength

For a growing number of developers, “web” means “JavaScript”. Programmers like to focus on programming languages, but the Web’s basic power comes from its support for communications, not programming.

I asked Jen Simmons, host of the Web Ahead podcast, to keynote Fluent after seeing her give a talk on responsive layouts at the ARTIFACT conference last year. It wasn’t just a great talk on responsive layout, but an exploration of the Web foundations that make responsive layout possible. Responsive layout’s foundations are deep in HTML, which contained those multi-device values from the beginning.

At Fluent, Simmons delivered A Love Letter to HTML, exploring HTML’s origins. The goals driving a memo written 25 years ago gave the Web strengths that developers need to study today.

Read more…

Comment: 1

Transforming the web (through transformation)

Decorating content may no longer be enough

Photo: http://commons.wikimedia.org/wiki/File:Metamorphosis_frog_Meyers.pngThousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.

Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.

“Templating” doesn’t quite capture what’s happening here. While templates are often a key tool, describing that tool doesn’t explain the shift from server to client. Templating also misses the many cases where developers are using plain JavaScript to insert, delete, and modify the document tree in response to incoming data.

These practices have been emerging for a long time, in many different guises:

  • In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
  • Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
  • Ajax opened the door to shell pages, apps that set up a UI, but get most of their content elsewhere, using JavaScript to put it in place.
  • New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
  • Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
  • The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
  • Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.

Read more…

Comment