John shares his concerns about the increasing complexity involved in developing for the web.
John addresses the price of increasing complexity in front-end development.
Yes, tooling can make our life easier. We type fewer keystrokes, and commit more code. But as software engineers learned a long time ago, most of the life of an applications is not in its initial development. It’s in maintaining it. This is something we on the web have had the luxury of being able to largely ignore up to now. After all, how many of the things you build will last years, decades?
Happy birthday, JS Bin!
Remy has some important news. No, it’s not the competition to recreate animated gifs with canvas; scroll down past that…
Remy will be working on JS Bin full time. To make this possible, JS Bin will have Pro accounts. But don’t worry; all the functionality available today will continue to be available in the future.
But Pro accounts will get a bunch of nifty extra features (and if you’re in education, you get Pro for free).
Sign me up!
I really like Dan’s take on using Photoshop (or Fireworks) as part of today’s web design process. The problem is not with the tool; the problem is with the expectations set by showing comps to clients.
By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.
It might seem like an obvious point, but what Tim is talking about here happens over and over again: a technique is dismissed based on bad implementation.
This post is ten years old, but I think it might still be the best attempt to demarcate a difference between web “sites” and web “apps”: think of them as stories and tools.
It’s also remarkably prescient about the need for an effort exactly like HTML5:
A widely-distributed, standards-compliant, browser and platform-independent library of functions that would perform the basic user interface functions for a web-based tool, relying on the server side only for the logic and data sourcing.
This is a very in-depth look at how to become a power user of the Web Inspector in Webkit browsers. I’m sitting down with a nice cup of tea to go through all of this.
This seems like an eminently sensible thing to do when building responsive sites: ditch mock-ups entirely. The reasons and the workflow outlined here make a lot of sense.
How designing in the browser works for rapid iteration.
Mark talks about the tools web designers use and the tools web designers want. The upshot: use whatever you’re most comfortable with.
Jonathan gives a thorough overview of the various tools and frameworks out there to help build native, hybrid and mobile web apps. He also shares his decision-making process on when to build what.
An excellent design technique from Samantha that allows you to nail down a visual vocabulary without using something as wishy-washy as a mood board or as rigid as a fully-blown comp. Brilliant!
The style tile is not a literal translation of what the website is going to be, but a starting point for the designer and the client to have a conversation and establish a common visual language.
A nice collection of design tools and methodologies.
Kevin Kelly on mankind's love/hate relationship with technology.
A detailed comparison of jQuery and MooTools.
Vint Cerf announces M-Lab: an excellent resource which will allow people to find out if and how their internet access is being throttled. Viva l'internet!
Crows is smart. And yes, I am using the "Bookmark this..." link at the end of the article.