Since I started Distilled Hype in early 2012 I have received a lot of positive feedback from people I respect throughout the industry. But it turns out that to maintain two websites that are very similar in nature and purpose doesn't make a lot of sense, it creates extra work, splits up the audience unnecessarily and as a consequence of these to brands competing, both suffer in quality.
A merge has been made. This site has now become my personal website. You will still find interesting stuff here but the web dev stuff will be over on TNG and we will be posting there more frequently.
Jeremy Ashkenas has just announced that Backbone.js 1.0 has been released, after a whole year on the 0.9 branch. This release adds support for HTTP PATCH requests, where partial updates are sent to the server. It also provides some sugar for data filtering methods like where and omit (from Underscore.js). Jeremy also notes that the annotated source has been improved.
Creating, testing and maintaining a large JavaScript code base is not easy — especially since great resources on how to do this are hard to find. This page is a collection of the best articles, videos and presentations we've found on the topic.
An amazing resource for professional JavaScript developers.
Thanks so much to superhero.js for linking up Distilled Hype!
This episode has some great insights. My favorite was this story by Eric Lippert:
When Eric started working at Microsoft his manager told him:
I want you to be a recognized industry expert on something. And since we work on the Javascript team at Microsoft that would probably be a good thing. But don't pick something that's too big. Right, don't try to be the recognized industry expert on the whole thing. Pick some aspect like the semantics of the language.
So he asked him:
Well, how do I do that?
And the manager answered:
Find a source of questions, answer every question that you know the answer to, that is in that domain and if there is a question that you not know the answer to, make it your business to find out.
Steve(W)’s article concludes by saying that loading jQuery from Google Hosted Libraries is probably NOT a good idea because of the low percentage of sites that use a single version. Instead, developers should bundle jQuery with their own scripts and host it from their own web server. Steve got his data from the HTTP Archive – a project that I run. His article was written in November 2011 so I wanted to update the numbers in this post to help the folks on that Github thread. I also raise some issues that arise from creating combined scripts, especially ones that result in sizes greater than jQuery.
What I’d like to do is help get you up to speed with Ember.js, via a multi-part article series which will gradually introduce you to the concepts of the framework.
An amazing collection of screencasts that cover Backbone.js, Marionette.js and JavaScript app development top to bottom including a Rails backend. They are 20% off right now so snatch them up! They are worth the money.
Thanks to Brian for letting me take a peek on them!
So I propose that we build a list of JSON documents describing as many REST APIs as possible. We can then import these specs as needed into a simple client like the one I wrote above, and start making HTTP requests without wasting time implementing yet another REST API client.
I’ve known fabulous programmers flame out in the quizzing cage and terrible ones excel. So unless you’re specifically hiring someone to design you the next sorting algorithm, making them do so on the white board is a poor gauge of future success.
Although this guide is primarily centered around front-end JavaScript, most of the practices here are equally applicable to back-end JavaScript in node.js.
But Lo-Dash isn’t just a consistent, fast utility belt. It offers a fully configurable build process, with a plethora of options and goodies. You can target legacy or modern browsers, or mix and match individual methods to taste. We’ve also introduced new methods for deep cloning, deep merging, and object iteration. And now we’ve added source maps, intuitive chaining, right-associative partial application, and a shorter iterator syntax.
A fantastic intro to Lo-Dash with some interesting insights about it's superiority towards Underscore.
Sync FileSystem API is a storage API that appears as yet another local offline HTML5 FileSystem storage which gives app-private sandboxed file storage, except that the storage content is automatically synchronized across clients via a cloud backing service like Google Drive.
Bigups to the Grunt team for shipping v0.4.0! I also really like some of the stuff coming up in the Grunt Roadmap for v0.5.0:
Grunt v0.5 will ship with support for a new plugin format called node-task. It defines a stateless, promise-based, event emitting API that doesn’t depend on Grunt. It has a real-live spec, and the Grunt team is working with the front-end developer community in the hopes that compliant modules will be compatible with every task runner under the sun. When it’s done, it will ship with a test suite that anyone can use to build their own tasks.
This application is designed to help beginners grasp the powerful concepts behind branching when working with git. We hope you enjoy this application and maybe even learn something!
A good interactive tutorial on how to use Git branching.
The Vertical Rhythm tools in Compass make it easy. However, despite Compass' amazing documentation, I did find a bit of a learning curve with Vertical Rhythm. Hopefully after reading this, you'll be able to dive right in and harness the delicious power of these tools right away.
A decent guide on how to use Compass' vertical rhythm features.
So, once you start getting into more advanced applications, it’s no longer so simple. Backbone.Marionette was created to alleviate a lot of the growing pains of Backbone development. Backbone.Marionette “make[s] your Backbone.js apps dance with a composite application architecture!,” according to its author.
Sacha on what is skeumorphism, what is realism and what is flat design. This is a nice counterpoint to the very inflationary use of the word skeumorphic for everything that has a little glossy texture on it.
Tekpub's Rob Conery and Marionette's Derick Bailey joined up to record a screencast on migrating an existing Backbone.js application to Marionette. The result has been released as a free episode to help you better understand how you can begin using Marionette today, without having to re-write your app from scratch.
One question people keep asking me is “Why did you choose Ember.js?”. It’s a good one, and one that I think can be considered in two ways: “Why use a a client side MVC Framework?” and “Why Ember out of all the frameworks?” Here’s my answer to both of those questions.
I get the reasons why face time is important. This is why even companies that are advocates of remote work, like Github and 37signals, have company-wide meetups at least once a year. Even an arrangement where a dev can come in once a week, or when needed during crunch time for a project or a special planning meeting, seems reasonable. But I don't see a reason why, in 2013, given the tools we have, a developer has to be on-site at a desk every day, as the normal operating procedure. Think of how many times companies miss out on really good developers just because they're not open to remote workers.
On the Flight landingpage Twitter offers up the reasoning behind their framework:
Flight is distinct from existing frameworks in that it doesn't prescribe or provide any particular approach to rendering or providing data to a web application. It's agnostic to how requests are routed, which templating language you use or even if you render your HTML on the client or the server. While some web frameworks encourage developers to arrange their code around a prescribed model layer, Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes.
Not only does this obviate the need for additional data structures that will inevitably influence the broader architecture, but by mapping our functionality directly onto the native web we get to take advantage of native features. For example, we get custom event propagation for free by piggy-backing off DOM event bubbling, and our event handling infrastructure works equally well with both native and custom events.
Given the JavaScript chops at Twitter I think it's worth checking out.
More interesting quotes:
Strict separation of concerns:
Flight enforces strict separation of concerns. When you create a component you don't get a handle to it. Consequently, components cannot be referenced by other components and cannot become properties of the global object tree.
Usage of native events:
By making DOM node events proxies for component events, we let the web work for us:
we get event propagation for free
a component can subscribe to a given event type at the document level or it can choose to listen only those events originating from within a specified DOM Node
subscribing components do not distinguish between custom events from other components (e.g. dataMailItemsServed) and native DOM node events (e.g. click), and process both types of event in an identical fashion
Easy testing:
Each component is a module, which aside from a minimal set of standard dependencies (relevant Flight utilities and mixins), has no reference to the outside world. Thus a given component will respond to a given event in the same way, regardless of environment.> This makes testing both simple and reliable — events are essentially the only variable and a production event is easy to replicate in testing. You can even debug a component by triggering events in the console.
Mixins:
A mixin defines a set of functionality that is useful to more than one object. Flight comes with built-in support for functional mixins, including protection against unintentional overrides and duplicate mixins.
I joined TalentSoup as a technical co-founder, and worked for a year and a half with my partner before we met face to face. All communication was done on the phone, through email, Basecamp, Github, iChat, whatever. We built (and continue to build) a profitable company, completely remotely. So I just don't get the reluctance from other companies to embrace remote workers. Are the problems you're working on that difficult, is your product that special, that everyone needs to be in the same room every working day?
