Responsive Web Design Makes It Hard To Be Fast
The Web Behind
I like Responsive Design. Heck, I LOVE Responsive Design. I think it’s a brilliant methodology, which address true challenges in a very good way. But no matter how fond you are of RWD, I think you have to face the music – RWD makes it very hard to write a fast website.
I’m not saying you can’t write a high performance responsive website. I’m not saying you shouldn’t use RWD (Responsive Web Design) – I would actually recommend it to most organizations. However, RWD makes pages inherently more complicated, and all in all would make the mobile web slower.
John Allsopp joins Eric Meyer and Jen Simmons for the first episode in The Web Behind series. The idea is to take a look back at where the web came from and the people who created it.
I think this is a really great idea for thinking forward. It’s a strange way to look at it, but if we don’t document the history there is no way we can learn from our mistakes. History is as important as the future.
Get behind The Web Behind. It’s good for the web.
Backstage: Basecamp for mobile
Today we’re announcing mobile web because it’s the right thing to do. Devices and platforms will come and go, but the web browser is here to stay. Does this mean there will never be native apps? Of course not, this isn’t our final word on mobile.
Once again, 37 Signals continue to deliver the goods.
Yeoman is now available. It’s an opinionated set of tools aimed at improving your workflow and productivity in building web apps.
CSS-Tricks – v10
Huge congratulations to Chirs Coyier with the redesign and the roll out of ‘The Lodge’. If you didn’t get behind his Kick Starter project, head over and signup now!
There is no such thing as CSS4
The Flowing Standard
The term “CSS3″ refers to everything published after CSS 2.1.
CSS is on its last version as a language as a whole, so it would be appropriate to just drop the number entirely and refer to everything from now on as just “CSS”.
Robin Berjon joins the WC3 staff to work on HTML full time and the HTML Working Group has also moved development of its various specifications to a GitHub repository.
For all that the HTML adventure may be fun to watch with some popcorn though, one of my hopes is that heading forward all parties in the HTML community can move towards more effective debates about focused technical issues while resolving sources of dissent. In other words: less drama, more work.
Over the coming weeks we will be detailing the way in which this repository is organised and used. The current plan revolves around adapting the well-known git flow model to specification development. Git’s flexible and powerful branching model allows us to maintain multiple branches, some headed for stabilisation in view of a tested and reviewed release, others carrying more future-fetching features; this while remaining able to apply bug fixes across the board.
I’m not a big fan of reading and keeping up to date with the ugly mailing lists that the W3C use. Thankfully, the GitHub news feed is more appealing. A big win in my eyes.
HTML5 Boilerplate v4.0.0
The web’s most popular front-end template just hit version v4.0.0.
The site has had a major refresh. The latest version of jQuery is included. Same goes with the inclusion of the latest Modernizr and lots, lots more. Huge congrats to all involved.
Apparently the display guideline requirements do apply to me. If I want to quote a tweet on my website, I’m supposed to use the embed code to make sure that people can favourite / retweet / follow, etc.
Fuck. That. Shit.
The faith that the web development community has in Twitter seems to be flying away rather quickly.
Chris Coyier is starting a new weekly roundup on his blog about all the relevant happenings around his main site CSS-Tricks site and the stuff he’s been doing.
Bring on Vol. II.
Twitter Bootstrap 2.1.0 released
Twitter Bootstrap Blog:
Understanding technical debt
New docs, affix plugin, submenus on dropdowns, block buttons, image styles, fluid grid offsets, new navbar, increased font-size and line-height, 120+ closed bugs, and more. Go get it.
Nicholas C. Zakas:
In the worst case, tech debt can accumulate to the point where the web application is destined to fail. A classic tech debt issue is scalability. Initially, the goal is to get the web application up and running so that anyone can use it. Decisions are made to allow that to happen. But an app that can handle 100 users isn’t built the same way as an app to handle 1,000,000 users. In the back of the developers’ minds are a list of things that need to happen in order to scale out: hit the database less, implementing several layers of caching, reduce the size of responses, figure out a faster way to process orders, and so on.
Just like monetary debt, tech debt is best dealt with before it gets too large and overwhelming. Regularly tending to tech debt is a process I like to call code hygiene. If you don’t go to the dentist for ten years and then finally go, chances are you’ll be in for a nasty surprise by not practicing proper dental hygiene. Code hygiene is the same. Keeping on top of your tech debt means regularly going in and addressing what you can with the time available.
Great article to pass onto your manager.
Lea Verou joins W3C
Working at W3C had been a dream of mine ever since I learned what a web standard is. As you probably know if you’ve been following my work, I’m a strong believer in open web standards. Even though proprietary technology might offer some short term benefits, in the long run only open standards can allow the Web to reach its full potential.
The web is in good hands!
Mass-unprefixing in Firefox 16
In Firefox 16, we are unprefixing:
- CSS3 Animations
- CSS3 Transitions
- CSS3 Transforms
- CSS3 Gradients
Also calc() might be unprefixed as well if time permits.
The Firefox team have been working hard!
iOS has a :hover problem
Nicholas C. Zakas:
So don’t believe people when they tell you that hover doesn’t exist on touch devices. At least on iOS, hover does exist and needs to be planned for accordingly. If you are using a :hover rule to show something in your interface, you may want to hide that rule when serving your page to a touch device. It might be a good idea to just completely remove all :hover rules for any experience that’s going to be served to a touch device. The touch-based world doesn’t need hover, so be careful not to inject it accidentally.
Principles of writing consistent, idiomatic CSS. The days of a simple web page seem to be long gone for me so reading documents and adopting the best practices are a must to improve as a developer. This document is in its early days and will no-doubt evolve and become a “go-to” source.
The document is broken down into 8 sections:
- General principles
- Practical example
- Build and deployment
Each section is explained very clearly and the practical example ties all the explained styles/patterns into one very simple example.
If you are a passionate developer and don’t have a consistent styles/patterns when writing your code then head over to the Idiomatic CSS document on GitHub and maybe try to adopt some of the principles into your current or future projects.
“Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.”
- Idan Gazit
Viljami Salminen, a UI/Web Designer and Developer from Finland explains his responsive workflow. He offers some great thoughtful descriptions on each individual step. His responsive workflow is broken down into the following steps:
Discover, Plan, Text Design, Sketch, Prototype, Visual Design, Test, Discuss and Iterate.
Some highlights included the free ‘Device Breakpoint Diagram’, the Text Design step (which was a new concept to me) and the Visual Design step which included some great typography tips.
‘Text design’ here means that we write (design) all the contents of the website down in textual form. This is one of the most important stages in the whole process, and yet it’s probably also the most underrated step.
Sass vs. Less
Visual design. This step happens in iterations before and after prototyping. I still use Photoshop to do most of the design, but I’m moving more and more towards design in a browser. Especially typography seems to be something which is really hard to get working anywhere else than inside the browser (Although at the same time I have noticed that if I do the jump too early, everything will end up looking flat, uninspiring and somehow cluttered).
Chris Coyier covers the hot topic of “Which CSS preprocessor language should I choose?”. He does a great side-by-side comparison. It is a great read if you are already using CSS preprocessors or not. Also be sure to check out the 160+ comments!