Web Dev - Armchair Philosophy

Web Dev

The Smashing Editor’s Choice: A Free eBook

Smashing Magazine Feed May 7, 2013 | 1:51 pm UTC

Nearly half a year ago, we introduced our eBook subscription model, also known as the Smashing Library. We knew we were onto something good, realizing that the Smashing Librar...

Whiteboards, Visions And Banned Words: How To Help A Real-Life Knight Achieve His Goals

Smashing Magazine Feed May 7, 2013 | 10:44 am UTC

This article is about design consultancy. It’s about wrangling that client who uses empty sentences like, â€œWe want a snappy, simple experience,â€ or, â€œIt should be...

What Soccer Teams and UX Teams Have in Common

UX Magazine May 7, 2013 | 10:05 am UTC

Soccer teams, just like teams in any other sport, share a lot of difficulties and joys with UX teams. Think about how each player needs to have his or her role in the tactic scheme. Isnâ€™t that the s...

The Two Flavors of a â€˜One Webâ€™ Approach: Responsive vs. Adaptive

Webmonkey May 6, 2013 | 1:28 pm UTC

A handful of the many screens your website must handle. Photo: Ariel Zambelich/Wired.com ï»¿[Editor's note: The following is a guest post from Igor Faletski, CEO of Mobify, which provides tools...

Libraries: A Canvas for Creating Meaningful User Experience

UX Magazine May 6, 2013 | 12:57 pm UTC

The patron enters the library with a VHS tape he has not viewed in thirty years. He's reserved the Digital Media Lab, a digitization space, to convert his tape to DVD. I, a librarian, push the tape in...

VIDEO: “If you wanna meet with me… comeâ€¦

Signal vs. Noise May 5, 2013 | 7:28 pm UTC

“If you wanna meet with me… come to the garden… with your shovel… so we can plant some shit.” -Ron Finley

Wanted: 25 special customers.

Signal vs. Noise May 2, 2013 | 3:21 pm UTC

We’re working on a entirely new product, and I’m looking to meet some potential customers. We can meet in person, over the phone, or via Skype, etc. The tool is for the small busi...

Karen McGrane on Content: WYSIWTF

A List Apart: The Full Feed May 2, 2013 | 11:43 am UTC

Arguing for â€œseparation of content from presentationâ€ implies a neat division between the two. The reality, of course, is that content and form, structure and style, can never be fully separated....

Why You Should Hire a VP of User Experience Design

UX Magazine May 2, 2013 | 10:37 am UTC

Searching on LinkedIn for titles such as VP User Experience Design or VP Global Design turns up very few people with those titles and roles. There are plenty of Head of ____ and Director of ____ roles...

Internet Explorer 10 Doubles Its Desktop Market Share

Webmonkey May 1, 2013 | 4:05 pm UTC

NetMarketShare’s browser stats for April 2013. Image: Screenshot/Webmonkey Microsoft’s Internet Explorer 10 saw a meteoric rise in market share last month, jumping from 2.93 pe...

WebRTC, Online Code Editor Team Up for Real-Time Coding

Webmonkey May 1, 2013 | 2:20 pm UTC

Collaborating with Codassium Image: codassium.com. It’s still going to be some time before WebRTC technology starts to deliver cool apps, but even today developers are quickly moving from...

Are You Putting the Home Button to Good Use?

UX Magazine May 1, 2013 | 10:44 am UTC

I have a three-year-old daughter going through a struggle at the moment. Itâ€™s time for her to give up the teddy bear that follows her wherever she goes. But weâ€™ll hear a little more about her late...

LINK: The importance of quick and dirty

Signal vs. Noise May 1, 2013 | 12:00 am UTC

The importance of quick and dirty Quick and dirty is a skill. Use it or lose it. My latest article for Inc. Magazine.

Magic Numbers and Progressive Enhancement

A List Apart: The Full Feed Apr 30, 2013 | 6:23 pm UTC

Chris Coyier explains Magic Numbers: Magic numbers in CSS refer to values which â€œworkâ€ under some circumstances but are frail and prone to break when those circumstances change. They are u...

Video: What Does 10 Petabytes of Data Look Like?

Webmonkey Apr 30, 2013 | 4:01 pm UTC

The Internet Archive’s Wayback Machine is deceptively simple — plug in a website and you can see copies of it over time. What you don’t see is the massive amount of eff...

The Very First Website Returns to the Web

Webmonkey Apr 30, 2013 | 1:09 pm UTC

Robert Cailliau’s original WWW logo. Image: CERN. Twenty years ago today CERN published a statement that made the World Wide Web freely available to everyone. To celebrate that moment in h...

Node at Work: A Walkthrough

A List Apart: The Full Feed Apr 30, 2013 | 12:00 pm UTC

In my first article, â€œEven Better In-Browser Mockups with Node.js,â€ I explained why Node.js makes designing applications easier and more efficient, and how to get started. Now itâ€™s time to see y...

Rather than figuring out all your requirements and API schemas just to design your comps with mockup content hard-coded and server interactions fakedâ€”only to throw it all away when you go back and implement things â€œfor realâ€â€”you can use Node.js to skip the hard-coding and produce client-side code thatâ€™s ready for beta at the end of the design stage.

The process looks a lot like good olâ€™ designing in the browser, but with more JavaScript and an additional layer:

Design the layout and styling
Convert the markup to a JavaScript template
Create an initialization function
Create a simple Node.js server
Add a mockup data object to the server
Add server functions to serve static pages and JSON
Request and consume the JSON on the client

Sound daunting? Donâ€™t worry. The first step takes approximately a zillion times longer than any of the others. So if youâ€™ve already mastered the design, youâ€™ll find the rest of these steps more than manageable.

In this walkthrough, weâ€™ll build a feature for a mock art store. If you want to follow along at home, you can clone my GitHub repository. (If you need help installing, see the README, or just take a peek at the live demoâ€”Iâ€™ll cover all the steps and code below.)

Creating templates

Once you have a solid design and the markup to accompany it, converting it to a template you can use for all examples is more efficient than creating duplicate markup for each one. The hard partâ€™s over; you already thought about where data points would be used in the design when you created it. With those choices fresh in your mind, go back and mark up your HTML with data in whatever template language you prefer.

For my example, Iâ€™m using a store selling art prints. Hereâ€™s a snippet of my initial markup:

<h2>Two Acrobats with a Dog</h2>
<h3>Pablo Picasso</h3>
<img src="img/102.jpg" alt="Two Acrobats with a Dog" class="active" />
<ul class="info">
	<li>8" x 11"</li>
	<li>acid-free paper</li>
	<li>suitable for matting</li>
</ul>
<span class="price">$49.99</span>

Think of your templates as places to define your requirements for both data and its formatting on the client side. If you can also reuse it for client-side rendering, thatâ€™s awesomeâ€”but that may not be relevant to your application. As long as you have good data, converting from one template language to another is trivial, so donâ€™t agonize over which template engine to use.

You do need a template engine that will work in both the browser and Node.js, however. If youâ€™re unsure, search for your template engine on GitHub and verify that thereâ€™s a guide to installing it via npm in the manual, as well as a minified script for use on the client. I prefer doT.js, so hereâ€™s that snippet again marked up to add data using doT:

<h2>{{=it.title}}</h2>
<h3>{{=it.artist.name}}</h3>
<img src="img/{{=it.id}}.jpg" alt="{{=it.title}}" class="active" />
<ul class="info">
	{{~it.info :info_item}}
	<li>{{=info_item}}</li>
	{{~}}
</ul>
<span class="price">{{=it.price}}</span>

I like to save my templates in their own directory at the same level as my JavaScript directory, so now I store that as tmpl/detail.dot.

Initializing the client

Since we want to be able to use our templates in both Node and the browser, they need to be stored outside of the HTML and loaded and compiled when we open the page. To start, save the minified version of your template engine and add a script tag to your page to include it. Once thatâ€™s done, you can fetch the template, compile it, and then continue on with any other initialization work in your main JavaScript file. Iâ€™m using jQuery in my example, so my code looks like this:

var detailTmpl;

$.when( 
	$.get( "tmpl/detail.dot", function( tmpl ) {
		detailTmpl = doT.template( tmpl );
	}, "text" ) 
).then( init );

That mysterious init function? Thatâ€™s where Iâ€™ll put any interactivity I want to add to my currently static mockup. For the moment Iâ€™m only creating one interaction, so my init function is pretty simple:

function init() {
	$( "div.content" ).on( "click", "div.result", showDetail );
}

This code can be made much more elegant using Require.js with its text plugin. Thatâ€™s beyond the scope of this demo, but I highly encourage it for production.

Weâ€™ll handle template rendering in showDetail(), but we have to add a server and data store before writing that function, since right now we lack any data to render.

Creating a server

If I reload my page now and open the browser console, I get a JavaScript error. Thatâ€™s because Iâ€™m trying to load my template via an XMLHttpRequest (XHR) on a page being served from the file system, in violation of the same origin policy. I canâ€™t even check that my template works until the page is served properly (i.e., from a server).

To whip up a simple Node server that allows me to run my XHRs, I do a few things:

Move all my existing assets into a new subdirectory called public
Open my terminal or command line to my working directory and run npm install express
Add a server.js file to the working directory

We could write everything from scratch, of course, but itâ€™s more work than is necessary for a basic server. The Express framework provides a number of abstractions of server and application concepts. For the initial version of the server, the only one weâ€™ll need is its ability to serve static resources. We can use it by adding four lines of code to server.js:

var express = require( "express" ),
	app = express();

app.use( express.static( __dirname + "/public" ) );

app.listen( 3000 );

Once you start your server by typing node server.js in your open terminal or command line, you can view your page at http://localhost:3000 (adding a filename if necessary), and the error related to loading the template ought to disappear.

Adding server-side data

While itâ€™s certainly nice to be able to use XHRs, we’re creating the Node server to use it as a representation of the real serverâ€”and real servers store data. Though itâ€™s not hard to create a data store that works with a Node server, itâ€™s even less difficult to create one big object literal. For a mockup, thatâ€™s all we really need. One of the goals here is to define the data objects we need to support in our new design, so the format of this object can be determined by the template we just added. For my example, I need an object structured something like this:

var products = {
	"102": {
		id: 102,
		title: "Two Acrobats with a Dog",
		artist: {
			name: "Pablo Picasso"
		},
		price: "$49.99",
		info: [
			"8\" x 11\"",
			"acid-free paper",
			"suitable for matting"
		]
	}
};

Note that products could just as easily be an array, but I want to be able to quickly find my productsâ€”once I have more than one in my fake data storeâ€”by ID. Aside from that little twist, the data look exactly like the content hard-coded in my original HTML. If I want to add more data, including things that might break the layout in unpredictable ways, I can just copy this structure and make substitutions. Well, almost.

Returning data from the server

If youâ€™ve dealt with other server-side frameworks, creating endpoints for XHRs might seem intimidating, but Express makes it really easy. We donâ€™t need any special setup to define a server endpoint as a target for asynchronous requests. All we have to do is define the path on the server where we want to accept requests and a callback. The callback receives a request object (for doing things like getting passed-in data) and a response object (for defining what we return to the client). To return the data in my products object, I add a few lines of code at the bottom of server.js:

app.get( "/detail/:id", function( req, res ) {
	res.send( products[ req.params.id ] );
});

app.listen( 3000 );

See? Easy. If I restart my server and go to http://localhost:3000/detail/102, I should see my object data. To break down whatâ€™s going on with the ID in the path, weâ€™ve named the data at that position in the path "id" with the :id bit, and it then becomes available as a property of req.params.

The names and positions of parameters are up to us, and if our path were super complex, we could also use regular expressions to split out multiple pieces of data. Express also gives us the option of accepting data from the query string or from a POST. Of all the pieces weâ€™re creating, however, the paths are the most likely to change in production, so itâ€™s to our advantage to keep them as readable as possible.

Besides sending pure data to the client, we also want to be able to send rendered HTML, in case a user is linked directly to a product detail or doesnâ€™t have JavaScript available. We might also want HTML for our own consumption via XHR, if we find that client-side rendering is slowing us down. So we add a second endpoint below the one we just created to do that:

app.get( "/product/:id", function( req, res ) {
	res.render( "detail", products[ req.params.id ] );
});

For simplicityâ€™s sake, and because the first path served JSON for an overlay while this provides a full page, Iâ€™ve used a different pathname, but kept the same pattern. This time, instead of the responseâ€™s send function, I use render(). Express provides some magic to make template rendering work out of the box, but since Iâ€™m using doT instead of Jade (the default template engine of Express), I have to do some additional setup.

First I have to go back to the terminal or command line, stop my Node server, and install my template engine using npm install doT and the consolidate module (which provides Express compatibility for a number of popular template engines) using npm install consolidate. Now Iâ€™ve got both of those in my node_modules directory and can use them in server.js.

Since doT (and probably your template engine of choice, as well) is accessed through consolidate, consolidate is the only additional module I need to require at the top of server.js:

var express = require( "express" ),
	app = express(),
	cons = require( "consolidate" );

I want to continue serving some of my other pages statically, so I add my template configuration stuff below the existing app.use line in my code:

app.use( express.static( _dirname + "/public" ) );
app.engine( "dot", cons.dot );
app.set( "view engine", "dot" );
app.set( "views", _dirname + "/public/tmpl" );

Those three new lines set doT (as exposed by consolidate) as the view engine, register files ending in .dot as templates, and tell Express to look in /public/tmpl for templates to use. So when Node sees res.render( "detail", { ... } ), it knows to expand "detail" to /public/tmpl/detail.dot and render it as a doT template. Now I can restart my server, go to http://localhost:3000/product/102, and see my template rendered statically, without creating a separate server-side file.

Fetching dynamic data

Our template now works as a static page, but thereâ€™s still one more step to get our mockup populated with the data from the server. Remember the showDetail function from our main client-side script? Itâ€™s time to flesh that out.

In my simple example, the overlay my template will populate already exists as a hidden div on the main page, and it appears when the user clicks a div containing a summary of the content. This div has a data attribute storing the ID of the product that corresponds to the key and id property in my server-side data object. Once that click event happens and showDetail() is called, I just need to do this:

function showDetail( e ) {
	var id = $( this ).data( "id" );
	$.get( "detail/" + id, function( info ) {
		$( "div.detail" ).html( detailTmpl( info ) );
		$( "div.detail" ).show();
	}
}

The path above is the same one I defined in server.js. If you chose a different name for yours, use that name here on the client. When I receive the data object from the server, I pass it to detailTmpl(), the compiled version of my template. The result of the detailTmpl function is the HTML to populate my overlay.

Onward

So there you have it! A mockup that mimics the interactions it will have with its production server precisely on the client, without the need for hard-coded data or temporary workarounds. Despite the simple exercise, the process Iâ€™ve outlined accomplishes a good deal of the setup necessary to create other workflows that require server interactions. For instance, I can fill my fake data store with more products and use that to render the initial page that triggers my overlay without having to revisit my mockup data, and my application will show the correct values in any view I add to it.

If youâ€™d like to explore beyond just serving HTML and JSON, consider adding in Socket.io to allow real-time interaction for multiple clients or Require.js to manage your assets on the client. You could also move your CSS into templates and serve different builds of your site for different browsers or devices. Your mockup can be as sophisticated and reflect as many of its production requirements as you choose. At the end, the lionâ€™s share of your client-side code is done and ready to use.

close article | permalink

Even Better In-Browser Mockups with Node.js

A List Apart: The Full Feed Apr 30, 2013 | 12:00 pm UTC

Designing in the browser has all sorts of benefits, like producing more accurate, comprehensive results and removing the extra step of converting from image file to markup and CSS. But even sites designed in a browser still require pasting in content, faking interactions with the server, and creating placeholder JavaScript that isnâ€™t usable on the live site.

Wouldnâ€™t it be nice if we could go from just designing layouts and interactions to designing the whole client side of the application during the same process?

This is where Node comes in.

Node.js is a server-side JavaScript platform. It isnâ€™t a web server, but it allows you to easily create one. It also lets you create utilities that run on web servers, like setup and minification utilities and general-purpose command line tools.

Node started in 2009 and generated considerable interest, probably because it gave JavaScript developers an opportunity to write server-side code even if they lacked a server-side background. It didnâ€™t hurt that Chrome had established a reputation for being solid and fast, and Node used its V8 engine.

Today, itâ€™s possible to run production servers on Node, and many people are doing so successfully. Taking it that far, however, is an investment. The Node project, and all the community-created modules that make it so awesome, is still a moving target. But even if youâ€™re not ready to write and launch entire sites with Node, itâ€™s plenty stable enough to use as a development tool.

Itâ€™s JavaScript, so if you can wire up a jQuery event handler, you can write a web server. Itâ€™s lightweight, so you can run it on your laptop and keep streaming music in the background. Itâ€™s dead simple to download, set up, and build in, so you donâ€™t need the esoteric knowledge of an IT support person to get going with it. And the payoff is that instead of mockups and hard-coded data, you can design a set of client-side assets, page templates, and data schemas that are ready to launch to production.

Getting started

Installing Node locally for the most common environments is a piece of cake. You can download installers that include Node as well as npm, its package manager, from the projectâ€™s site. Installing it on a remote server is not quite that easy, but good documentation is available to help you out. After running through the installation process, you should be able to go to your terminal or command line and test it out.

If you donâ€™t tell Node to run a specific file, you get a Read-Eval-Print Loop, or REPL. If you type node in your terminal or command prompt, you can begin to execute arbitrary JavaScript. For example, after starting the REPL, type var a = 9;. The REPL will respond with undefined. Now type a * 3 (or any other number) and it will respond with the correct result. You can make things more interesting by defining a function and then calling it:

> function sayHello( name ) { return â€œHello, â€œ + name; }
undefined
> sayHello( â€œA List Apartâ€ );
â€˜Hello, A List Apartâ€™

To break out of the REPL, or end any other Node execution (like a running web server), press Ctrl+C. In the case of the REPL, youâ€™ll need to press it twice to confirm.

While itâ€™s nice to know Node can perform basic arithmetic and string concatenation, its value to us as developers is in running programs. You can see an example of one such program, a basic web server, on the projectâ€™s homepage. They suggest creating a file called example.js with this code:

var http = require(â€™httpâ€™);
http.createServer(function (req, res) {
  res.writeHead(200, {â€™Content-Typeâ€™: â€˜text/plainâ€™});
  res.end(â€™Hello World\nâ€™);
}).listen(1337, â€˜127.0.0.1â€™);
console.log(â€™Server running at http://127.0.0.1:1337/â€™);

This makes use of only one module, the core module http. As you can probably guess, the http module contains all the basic stuff you need to serve a site over HTTP. Node contains a tightly edited collection of core modules that provide things like event handlers, file system access, and abstractions for various network protocols. But just as you probably use a JavaScript library or framework to speed up and bulletproof development on the client side, for Node development beyond a simple "Hello World" you generally add other non-core modules using npm.

The http module does contain a createServer function, though, which is all you need to create a bare-bones web server. In the code above, once the server has been created, it listens to port 1337 on your local machine. When it receives a request, it sends back a text response.

One thing to note is that the work here is done in event handlers, as are most things in Node. The callback in createServer() handles a connection event, which occurs every time a new client contacts the server. To start this server, type node example.js in your terminal, and then open a browser to http://127.0.0.1:1337. This triggers the connection event, and you should see the message in the callback.

To obtain any serious value from a Node serverâ€”even one not intended to ever go to productionâ€”itâ€™s best to get familiar with the modules in npm. There are thousands available, but those youâ€™d need to create a basic web application are some of the oldest and most stable, so donâ€™t feel obligated to research them all before getting started. One that definitely comes in handy for designing an application is Express, an uncomplicated web application framework.

If youâ€™re accustomed to installing open source projects by cloning a GitHub repository or downloading a zip file, youâ€™ll probably enjoy npm. To install Express with npm, for example, go to your terminal or command line and type npm install express. As long as youâ€™re online and have permission to write to your machine, this fetches all the code and assets Express needs to run, as well as any modules it has as dependencies. The first time you run npm from your working directory, all these elements will end up in a new node_modules subdirectory. Now the module is ready to be used in Node programs the same way we used http, via the require function.

Designing applications

The ideal use case for designing your application with Node is a single-page application in which the server mostly provides data, but Node is still useful for a more traditional site. Of course, you want to begin development with requirements defined as precisely as possible, but implementation tends to expose requirements you hadnâ€™t considered, and some of those can have a considerable impact on your timeline. Even in a server-driven application where it may not be possible to reuse data structures and templates as-is, creating client-only versions helps test your assumptions about the data you need and how youâ€™ll use it.

If youâ€™re developing a single-page app, the justification is much easier. Youâ€™ll need to think about optimizing your communication with the server to require as few requests as possible, which means knowing how data should be packaged up by each server endpoint and how youâ€™ll cache the data on receipt (if at all).

An advantage of having JavaScript on the server is that templates can be rendered by the same template engine on either the client or server side. This allows you to experiment on both sides and optimize for your situation. Itâ€™s also a timesaver to render the templates with JavaScript objects and consider only the way data must eventually be grouped (not how it’s stored in a database). Designing these groupings of data is the bulk of the work we can do with Node toward the end of what we traditionally consider application design.

Piecing together each page from disparate parts from all over the server is messy for an application in any language. Instead, whatever renders a page should have clear dependencies, and the result of each page or data request should combine those dependencies into a cohesive and sensibly organized unit.

If youâ€™ve worked in a server-side framework in which a page or view is tied to a single object or model, and where additional data is imported and exposed in a different way, you probably understand how the alternative gets to be a nuisance. Youâ€™re probably also aware that the solution is a good view-model whose data is defined by each view, not the models that feed it. With this exercise, we aim to map out what goes in those view-models.

Using templates

Thereâ€™s a strong likelihood that your production server does not run JavaScript, so you may end up converting templates you produce in this design phase. You could attempt to mitigate this by choosing a template engine like Mustache with existing parsers for a huge list of languages. Or you might choose one with minimal logic available (I find that the only things I want for a truly flexible template are conditionals, loops, and partials) and the option of changing the delimiters around the template tags to agree with your server template language. Iâ€™d argue that the process of getting all the data correctly placed in your HTML is a lot more difficult than doing a find and replace on the end result, so creating a template in JavaScript that you can use easily is time well spent even if it canâ€™t be parsed by your production server.

You could choose to design the UI of your pages using hard-coded mockup data first and add the template tags afterward, or you could start with a template and some mockup data ready to go in your Node server. Even though itâ€™s an extra step, I find the former easier, because the latter tends to require extra shifting of the mockup data. Starting with hard-coded data lets me examine the finished mockup and see what kinds of "objects" are present (e.g., a user, an item for sale, or a status update). That helps me create a flexible object hierarchy in my data more easily. But you may be naturally amazing at creating object hierarchies, so, by all means, do what you feel.

Wherever you begin, hammering out your templates should give you an indication of which parts of each page are dynamic and which data each requires. If subsections of your pages are rendered separately because theyâ€™re reused on different parent pages or because theyâ€™re also rendered by the client, converting your markup to templates also allows you to find the right balance between never repeating code and having absurdly tiny templates.

Real fake server interactions

If youâ€™ve created high-fidelity wireframes that run in a browser, you know the annoyance of having only parts of a page be interactive, since every click means having to create a new view (even if you have a series of items that share the same behavior when clicked). You also know about copying and pasting the same data into multiple places, and updating each of them separately if the manner of presenting data should change. Designing your app with a server behind it removes those frustrations.

With the support of a server, itâ€™s not a problem if the same data shows up in different displays all over the workflow youâ€™re designing. Since the data lives on your Node server, you can write it once and reuse it as many ways as you like. You still have to consider how youâ€™ll move it from server to client, though. When a user clicks on one of many items in a list, will she be taken to a new page, or will more data appear inline? Is the former the non-JavaScript fallback for the latter? Working that out for your app will tell you which endpoints the server needs, and which parameters need to be sent to it in query strings, form posts, or URLs. Itâ€™ll also help define the API for those requests, telling anyone who might work on your production server which keys you expect to correspond to which pieces of data.

Having a server to work with is especially nice if youâ€™re in the business of making asynchronous requests. Obviously, you can get your mockup data, which is excellent, but you can also lazy-load assets like templates or stylesheets to consume that data. Testing the process of getting data and assets to the client validates your assumptions about not only the way youâ€™re packaging them, but how youâ€™re storing and structuring them. And, of course, it means a lot less wasted client-side JavaScript.

A mockup you can use

The end result of all this should be that youâ€™ve moved all the mockup pieces out of your client-side JavaScript and HTML. You have a Node server that might not match your production framework, but does have clear definitions of everything the client side expects to existâ€”possibly even all viewable in a single file. You have templates and client-side requests that may require substitutions, but also separate your data from everything else and are at minimum easily convertible to whatever format is needed for production.

Could you do the same with any other server under the sun? Absolutely. But if you already know JavaScript and arenâ€™t aiming to become a server-side developer, it makes sense to use the skills you already have. Node makes that pretty easy, while also letting you dig as deeply as you want into more complex servers, should your ambitions change. Itâ€™s simple to get going and flexible to extend, making Node an awesome tool for designing applications.

Ready to take your new Node skills for a spin? In “Node at Work: A Walkthrough,” Iâ€™ll take you through a live demo, and get specific about how to refine your own mockups.

close article | permalink

Principles of Writing Consistent, Idiomatic JavaScript

A List Apart: The Full Feed Apr 29, 2013 | 3:47 pm UTC

Â» Principles of Writing Consistent, Idiomatic JavaScript If youâ€™re looking for a thorough JavaScript style guide for your team, Rick Waldronâ€™s Principles of Writing Consistent, Idiomat...

Chrome Extension Opens MS Office Docs in the Browser

Webmonkey Apr 26, 2013 | 5:01 pm UTC

Viewing MS Office docs in Chrome. Image: Screenshot/Webmonkey Google Chrome OS users have long enjoyed the ability to open Microsoft Office documents right in the web browser. Now Google i...