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.

Blocked!

Will content-blocking change the Web?

tree-8810_620
“No one ever turns off JavaScript any more.” I remember when I first believed that, probably around 2007. The growth of Ajax had meant that more people were actually losing content if they turned off JavaScript. From what I could tell, most of the few folks still blocking JavaScript surrendered pretty quickly.

I don’t believe that any more, though, thanks to advertising and the doors that blocking advertising has opened.

While a key part of the last decade’s Web conversation has been performance, the walled gardens are taking advantage of our failure to deliver performance to make their own promises. Facebook’s Instant Articles offer a way for publishers to use the (relative) certainty of Facebook delivery, while Apple took a more direct route for demanding performance: blocking advertisements, and more.
Read more…

Learning the Web

Finding a gentle entry to a big space

html5_fundamentals

The Web welcomes, but it’s awfully big. While HTML, CSS, and JavaScript may all be appropriate entry points for newcomers who want to create, finding a solid starting point can be complicated. Social media has minimized the level of HTML and Web knowledge people need to start contributing, but when it’s time to make the jump, the Web offers perhaps too many options.

Part of the challenge is that HTML, CSS, and JavaScript may be the marquee technologies, but they’re not actually what hosts a website or app. Setting up a site requires an additional set of technologies, from domain names to hosting to web server choices. Setting up a site – long before you get to packaging an app! – requires mastering an additional technical toolset and vocabulary that will help you navigate where you need to put your projects. Our free report, Getting Started with the Web, provides the core foundations beginners need.

Those aren’t the only barriers, though. Read more…

CSS fundamentally transforms

Enabling the creation of maintainable sites and apps that look great across a variety of different devices and contexts.

css_lp_620

Choose your Learning Path. Our new Learning Paths will help you get where you want to go, whether it’s learning a programming language, developing new skills, or getting started with something entirely new.

CSS is different. Cascading Style Sheets provide a text-based way to describe what web pages should look like, but it isn’t a programming language and it relies on HTML document structures as a foundation. You need to have a grasp of HTML before you start CSS, but CSS doesn’t look anything like HTML. Nor does it look like JavaScript, the most common programming language on the Web. Whatever your background, getting comfortable with CSS’ unique approach can take some work.

CSS’ declarative model can be uniquely efficient, but requires an understanding not only of the features you want to use but the approach you want to take in decorating a document tree. That means understanding the document tree (and there may be many variations as you apply the same style sheet to multiple documents), the selectors used to identify points on the tree, the cascade that resolves conflicts among selectors, and the properties applied to that tree. Of course, the properties interact with each other and a shared model, so you’ll need to understand how the properties how to make those interactions produce your vision.
Read more…

The Web welcomes

Access not just to content, but technology.

stairs

“They learn a bit of Web stuff, and the next thing you know they think they understand programming.” I’ve heard variations of that lament for the past two decades. I’ve heard it less lately, because so many recent computing professionals built their technical careers from that bit of Web stuff.

The Web succeeded in large part because it was the easiest way for people to create electronic content and share it. Indexes and search engines made it easier to find that content. While administering files on a server and learning HTML weren’t trivial, they were much more approachable tasks than creating and distributing traditional (now largely considered desktop or native) applications.

For the most part, they still are easier.
Read more…

JavaScript shares its ubiquity

WebAssembly changes the rules of the JavaScript game.

engineroom

I’ve never seen a technology lay down its primary advantage and prepare to hand over its ubiquity. I’m proud of JavaScript for doing this, and I’m sure that in the long run this will be good for the Web, but in the meantime I’m wondering where WebAssembly will take us.

Brendan Eich’s announcement of the effort makes clear that this builds on the earlier asm.js (and Google’s similar PNaCl), a highly efficient JavaScript subset that compilers of other languages could target. Eich enjoyed using Unreal Engine for demos of the speed asm.js could provide, but compiling to JavaScript, even weird JavaScript, still needed to go through a JavaScript parser. (Other approaches compiled to more comprehensible but less optimized JavaScript.)

WebAssembly – wasm – skips that final step, producing a binary format, technically a compressed AST encoding. Unless you’re going to be building compilers, you can compare wasm to a bytecode system. There is a text format for debugging, but the binary emphasis yields substantial extra speed as it skips parsing and minimizes decompression.
Read more…

The power of connection

URLs are the Web's unique superpower.

iron_chain_620
Over the past two decades, the heart of the Web has come to seem ordinary, forgettable. Some software has gone so far as to bury it and make it invisible, but it still worked its magic behind the scenes. As competing systems have made it disappear, though, absence has made many hearts grow fonder.

The humble URL is pretty ugly. The Web’s creator, Tim Berners-Lee, was embarrassed that people looked at them. It’s plain text, the computing interface that came right after punchcards and switches. The openings are always verbose, with a long “http://” (or similar) preceding the actual place you want to go. Excessively abstract debates about URIs aside, automated systems’ fondness for opaque identifiers has made many URLs hideous piles of characters that only a lookup table could enjoy. (Are QR codes even uglier?)

Even done badly, however, the URL is perhaps the most powerful innovation in networking history. While prior systems (IP addresses, DNS, and similar) had let us connect computers, URLs let us connect people’s creations. URLs let us share other people’s ideas, and promote our own ideas. The power to say “this bit of text will (mostly) reliably get you this content today” is a basic feature fundamental to the Web’s triumph.
Read more…

Finding new in the Web

Learning from the Fluent Conference.

At Fluent 2015, we brought together a variety of stories about front-end engineering – some technical, some social, some more intricately intertwined.

From the very first day, it was clear that React was the big technical story of the conference, taking the place that Angular (which is still clearly important!) had had the previous year. Tutorials and sessions were busy, and I kept hearing conversation about React. Sometimes it was “what is React supposed to do?” but other times people were talking about exciting corners of React Native or techniques for integrating React with a variety of frameworks.

React makes me happy because it solves the problem a lot of people didn’t quite realize they had. Suddenly they are very enthusiastic about stuff that used to be really annoying. The Document Object Model (DOM) has been the foundation of most of the interactive work on the web since 1998, but it wasn’t very much fun then. As developers really get deeper into these things, the DOM has not exactly been a crowd-pleaser. In some ways React is a wrapper for the DOM, and in many ways it’s a just a better way to interact with the document tree.

The other technical key this year was JavaScript, often specifically ECMAScript 6 (ES6), the latest release. Brendan Eich talked about a world in which compiling to JavaScript has become normal, and how that frees much of the future development of JavaScript and the Web. Even Dart, which many of us saw as an attempt to replace JavaScript, has a home in this world.
Read more…

Cross-pollinating Web communities

The integration of the Web's diverse communities broadens horizons and technology.

Waterdrops inside The Animal Flower Cave, Barbados. By  Berit Watkin on Flickr.

Web projects are integration projects, combining skills from a number of disciplines. Lousy interfaces can obscure brilliant code, and ingeniously engineered back-end systems can still fail when they hit resource limits. “Content” lurks in many guises, requiring support not only from writers and illustrators but from video specialists, game designers, and many more. Marketers have built businesses on the Web, and influence conversations from design to analytics. You don’t have to be a programmer to do great work on the Web. The Web stack is vast.

Web development models include far more than code. Creating great websites and applications demands collaboration among content creators, designers, and programmers. As applications grow larger, supporting them requires adding a cast of people who can help them scale to demand. As projects grow, specialization typically lets people focus on specific aspects of those larger disciplines, supporting networking, databases, template systems, graphics details, and much more.

In some ways, that’s a recipe for fragmentation, and some days the edges are sharp. All of these communities have different priorities, which conflict regularly. Battles over resources sharpen the axes, and memories often linger.

At the same time, though, often even in environments where resources are scarce, different perspectives can reinforce each other or create new possibilities. Sometimes, it’s just because the intersection spaces have been left fallow for a long time, but other times, the combinations themselves create new opportunities. Read more…

Worship maintainers

The future is maintenance: build for the inevitable.

switch

Technology has had a cult of newness for centuries. We hail innovators, cheer change, and fend off critics who might think new and change are coming too fast. Unfortunately, while that drives the cycle of creation, it also creates biases that damage what we create, reducing the benefits and increasing the costs.

Formerly new things rapidly become ordinary “plumbing,” while maintenance becomes a cost center, something to complain about. “Green fields” and startups look ever more attractive because they offer opportunities to start fresh, with minimal connections to past technology decisions.

The problem, though, is that most of these new things — the ones that succeed enough to stay around — have a long maintenance cycle ahead of them. As Axel Rauschmayer put it:

“People who maintain stuff are the unsung heroes of software development.”

In a different context, Steve Hendricks of Historic Doors pointed out that:

“Low maintenance is the holy grail of our culture. We’ve gone so far that we’re willing to throw things away rather than fix them.”

That gets especially expensive. Heaping praise on the creators of new things while trying to minimize the costs of the maintainers is a recipe for disaster over the long term.
Read more…

Full-stack tensions on the Web

How much do you need to know?

Vista_de_la_Biblioteca_VasconcelosI expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.

In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.

Formal separation of concerns among HTML, CSS, and JavaScript made it easier to share responsibilities among specialists. As the dot-com boom proceeded, specialization accelerated, with dedicated designers, programmers, and sysadmins coming to the work. Perhaps there were too many titles.

Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
Read more…