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.

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

Formulating Elixir

Simon St. Laurent and Jose Valim explore a new functional programming language

I was delighted to sit down with Jose Valim, the creator of Elixir, earlier this month at Erlang Factory. He and Dave Thomas had just given a brave keynote exploring the barriers that keep people from taking advantage of Erlang’s many superpowers, challenging the audience with reminders that a programming environment must have reach as well as power to change the world.

Elixir itself is a bold effort to bring Erlang’s strengths to a broader group of developers, adding new strengths, notably metaprogramming, along the way.

Watching Elixir grow has been a unique experience for me. I’ve seen other languages (JavaScript and XSLT) emerge, but Elixir combines solid foundations on prior (Erlang) work with a remarkably open conversation about how to structure the language. Jose tries things and asks for feedback, takes suggestions well, and values questions about how best to make the language accessible. Even without a standards organization, the process has remained open, stable, and productive.

Whether you’re interested in Elixir itself or just in the challenges of creating a new combination in a world filled with past experiments, it’s well worth listening to Jose Valim.

  • We’ve had functional programming since 1959 – why the burst of interest now? [2:10]
  • Moving from Ruby to Erlang “making Rails thread-safe, that was my personal pain-point” [3:13]
  • “Every time I got to study more about the VM, the tooling and everything it provides, my mind gets blown.” [6:12]
  • Why Elixir started, and how it’s changed as Jose learned more. [10:08]
  • Integrating new Erlang features (R17 maps) into Elixir. [15:43]
  • When can you use Elixir in production? [18:07]

I’m looking forward to seeing a lot more Elixir, even as I need to catch up on updating Introducing Elixir. I’m not sure it will conquer the world immediately, but it will certainly leave its mark.

Comment

Yes, CSS is code

Learning from "The Humble Border-Radius"

One of the best things I overheard at the Fluent Conference was (more or less):

“CSS live coding? I was like, that isn’t code. But then it was.”

Lea Verou had changed the mind of a skeptic.

CSS is not Turing complete (Update: Lea points out that I’m wrong about that), and I’ve long been grateful that it wasn’t designed as an imperative programming language. It can be too much code for designers, too little code for programmers, and yet it’s code.

I think about the graphics work I tried to do with shapes and sprites and assorted kinds of vectors over the years, and then watch this keynote. Even with the glitches and coming improvements she notes, it’s clear that whatever tools I was using at the time, they weren’t declarative enough. (I’d also just seen this JSFest talk on CSS box-shadow by Vince Allen, so I was looking forward to more CSS graphics magic.)

Read more…

Comments: 3

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

Implementing hypermedia clients: it’s not rocket science

Not ugly, not complicated

hypermedia

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Layer 7 Principal API Architect Mike Amundsen demonstrated how to build hypermedia clients, for situations with and without humans in the driver’s seat.

(If you’d like to know more about hypermedia in general, this interview provides more background.)

In his talk, Implementing Hypermedia Clients: It’s Not Rocket Science, Mike explored how hypermedia approaches drive conversation between clients and servers, and the application structures that result from those structures.

  • 1:44 – “The Semantic Gap: Hypermedia tells us what we can do, but it doesn’t say why.”
  • 6:04 – Hypermedia and application control information – links!
  • 8:09 – Control factors – “I accept RSS, can you give me RSS?”
  • 10:41 – Foundations of the class scheduling domain example
  • 16:30 – “What is a hypermedia client that a human would use?”
  • 19:24 – “Faithful Hypermedia Clients (FHCs) pass along whatever the server returns, and lets a human sort it out.”
  • 31:20 – “So what’s a Hypermedia for machine client?… Makes choices, not waiting for a human”
  • 33:25 – Working with Maze+XML
  • 37:10 – The power of generic types

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

Comment

How to (semi-)automate JavaScript refactoring

Disposable robot assassins and spreadsheets

Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Giles Bowkett demonstrated a wide variety of ways to write code that helps refactor code, showing developers a variety of ways to clean up and simplify their JavaScript. He gave ‘disposable robot assassin at large’ as his title, but it fit better with the code he was demonstrating.

Bowkett explored many options and iterations of his automation ideas,

  • The roots: Martin Fowler’s classic Refactoring. [at 00:50]
  • “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
  • Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
  • “More complex information… surfacing an implicit object model.” [at 7:45]
  • Filter scripts and text streams [at 14:45]
  • “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
  • Building on JSLint [at 20:10]
  • Switching to a Ruby parser for JavaScript to calculate differences [at 21:49]
  • JavaScript parsers: Esprima [at 27:26]
  • “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
  • Grepping through git history [at 32:53]
  • “Automatic refactoring will let you get to better code much faster.” [at 36:25]

It’s an amazing mix of capabilities that let you build your own robot (code) assassins.

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

Comment

Writing without knowing

Sometimes you need to be your customer

Sometimes you just need to leap into sharing your learning, even when you haven’t yet learned much. “Beginner’s mind” usually becomes more abstract as a person advances, making it difficult for beginners to learn from experts. If you can dare to write while you’re learning, you may find unique opportunities to create content that appeals first and foremost to learners.

Despite that, the “learn from the master” story remains powerful: of course, only those who know best should be trusted to teach! Sometimes that comes with the old guild-flavored model: masters should select worthy apprentices and mentor them for a long while.

The apprenticeship model has its benefits, but I’ve spent most of my career promoting what I generally call the DIY model. Even in the thriving field of programming, we don’t have enough masters willing to spend their time with apprentices. Masters seem better at talking with masters than with newcomers, and even the journeywomen and journeymen sometimes forget the difficulties of the paths they’ve followed to get there. The DIY model drops that lost formality and replaces it with books, videos, and occasional classes, combined with a lot of self-study.

Getting the DIY story right is incredibly difficult. Unless you’re lucky enough to be teaching in person, which has its own challenges, you have to anticipate what a reader or viewer will need. The feedback loop runs mostly through reviews, both during and after the creation of the piece. Getting ahead of that feedback loop means doing something scary: write about what you don’t know.

Read more…

Comments: 4

Go node without code

Command line tools improve development workflow

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Adobe Community Manager Brian Rinaldi showed off ways Node makes possible a new world of utilities, showing JavaScript developers a toolkit they will want to integrate into their workflows.

In his talk, Go Node Without Code, Brian talked about the many ways Node and the npm ecosystem of JavaScript packages can help front-end developers, even if they don’t want to leap to server-side programming.

Tools Brian explored include:

  • UglifyJS, the “JavaScript parser / mangler / compressor / beautifier toolkit” [at 02:00]
  • Less, “for building CSS, but offers a lot of features you don’t get in straight CSS” [at 06:15]
  • Grunt, addressing the “just adding steps to my workflow” problem. [at 9:09]
  • GruntIcon, “A mystical CSS icon solution” [at 18:18]
  • Automaton, a “task automation tool” [at 25:00]
  • HTTPster, a dead-simple “local static development server” [at 30:05]
  • The slightly more configurable Node-static [at 32:00]

You will need to be familiar with the command line for a lot of it – if you’re not, it’s a great time to learn!

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

Comment

What should programming look like?

Can it really be simplified?

Even as we all scramble to use the programming tools we have today, developers look ahead hopefully, dreaming of better tools. What shape should those tools take? Who should they be for?

A few months ago, I had the privilege of talking about programming’s future with three great and very different programmers:

I’d encourage you to listen to the whole conversation, but to get started, you might explore these highlights.

Read more…

Comments: 3

Web application development is different (and better)

On both front and back end, the Web challenges conventional wisdom

The Web became the most ubiquitous distributed application system because it didn’t have to think of itself as a programming environment. Almost every day I see comments or complaints from programmers (even brilliant programmers) muttering about how many strange and inferior parts they have to deal with, how they’d like to fix a historical accident by ripping out HTML completely and replacing it with Canvas, and how separation of concerns is an inconvenience. Everything should be JavaScript.

(Apologies to Tom Dale, who tweeted a perfect series of counterpoints just as I was writing. He has visions of rebuilding the rendering stack in JavaScript, but those tweets are not unusual opinions.)

The Web is different, and I can see why programmers might have little tolerance for the paths it chose, but this time the programmers are wrong. It’s not that the Web is perfect – it certainly has glitches. It’s not that success means something is better. Many terrible things have found broad audiences, and there are infinite levels to the Worse is Better conversations. And of course, the Web doesn’t solve every programming need. Many problems just don’t fit, and that’s fine.

So why is the Web better?

Read more…

Comments: 2