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.
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…
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.
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.
Transforming the web (through transformation)
Decorating content may no longer be enough
Thousands 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.
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.
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.)
The web is eating software
Web technologies have become the default, and are spreading
A 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.
Implementing hypermedia clients: it’s not rocket science
Not ugly, not complicated
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.
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.
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.