How to keep up to date on front-end technologies →
Pretty brilliant set of links and advice from Guille Paz, Her Mammana and Lean Linares.
Pretty brilliant set of links and advice from Guille Paz, Her Mammana and Lean Linares.
Lead Paravel developer Dave Rupert:
If the web cannot keep pace with a native experience in speed (rendering in under 1000ms), we’re all going to be out of the job. An uptick in native app usage means budget dollars would follow the trend and be poured into native apps. Meanwhile public facing websites will be left to rot because no one cared and we littered the web with bullshit. Native wins, the web dies, Zeldman hangs up his beanie, and Sir Tim Berners-Lee cries a single tear.
Somewhat scary yet very relevant advice. Bottom line, web sites are perceived as “slow”, and it’s our job as developers to counter that notion. Dave emphasizes here that yes, a responsive or pared down approach to images is difficult. Yet it’s critical work.
Developer Will Vaughn:
Yeoman isn’t about taking plays from someone else’s playbook, its about designing your own offensive scheme, and executing it.
I really enjoyed reading Will’s experience sitting down with Yeoman for the first time and feeling…completely overwhelved. Been there, done that. But there’s some great advice here on how to start with Yeoman in small but effective steps. He leads with Grunt, something I’m already a huge fan of. It’s enough for me to get back on the Yeoman bandwagon and give it a try.
A great animated gif Tumblr blog that almost any front end developer can identify with. I especially love that The Wire reference used for “when asked to do an HTML email”.
The legendary Jeremy Keith, talking about best practices for responsive web design:
And here’s the key: try to come up with as few major breakpoints as possible. That might sound crazy, since we’re talking about responsive design. After all, we have media queries, so let’s use about 12 of them, right? No! If a linear layout works for every screen and is appropriate for your particular concept, then there’s no need for different layouts.
I’ve learned this the hard way in my early responsive work; you find writing more and more media queries easy, and next thing you know your responsive code gets out of control. Follow Keith’s advice here; simpler is generally better.
The always reliable Harry Roberts on CSS optimization writes a lot of solid points here. But it ultimately comes down to this:
Make sure any classes you write aren’t loose; make sure they’re always well named, and scoped if they need to be.
To put it another way, as I’ve always told classes I’ve taught and colleagues I’ve mentored, good CSS class names are underrated. Choose wisely.
Especially on the eve of iOS 7 fairly radical visual redesign in a more colorful, minimal, and “flat” direction, it’s worth looking at Yahoo’s latest web framework for inspiration. I dig the framework’s simplicity, it’s heavy use of prefix classes and normalize.css.
Given the stellar quality of Zurb’s web framework Foundation, I’m going to try this “responsive image solution” out on some side project, just to see how the internals come together. But the syntax is a bit worrisome, a bit like the srcset attribute, but not all close to the picture element, which I’m currently favoring. I’ll still keep an eye on this one.
Developer Philip Walton:
A Rails developer isn’t considered good just because his code works to spec. This is considered baseline. Of course it must work to spec; its merit is based on other things: Is the code readable? Is it easy to change or extend? Is it decoupled from other parts of the application? Will it scale?
These questions are natural when assessing other parts of the code base, and CSS shouldn’t be any different.
I think Philip goes a bit into the deep end with his class naming conventions. Nevertheless, especially with his points about code reuse and modularity, this is essential CSS reading, one of the best articles I’ve read on the subject in weeks.
A no-nonsense checklist by developers Sayed Hashimi and Mads Kristensen. Yes, you can technically use it as an actual web task manager, but the real benefit here are all the links provided, from the W3C mobile checker to JSHint and tips on making proper favicons.