Native mobile apps are a temporary solution. We’re just over 4 years into the Appstore era and this has already become apparent. Open web technologies are catching up to the point that the vast majority of web apps no longer need a native counterpart.
Don’t try to tell me native apps are faster or allude to them having a “better experience.” That simply is no longer true.
Jim’s argument might be a tad simplistic, but I agree with his points. We’re getting glutted with so many unnecessary native apps that should just be well thought out, responsive web apps.
I’ve been a big fan of Safari for a while; generally it’s my browser of choice in my free time. But for work, I never found it came close to the quality of Chrome, almost entirely due to its poor web inspector.
With Safari 7 out the door as part of OS X 10.9, things are very different. Safari took a huge step forward with their inspector; it’s the first that I’ve used for more than a few minutes without immediately closing the page in question and switching to Chrome Dev Tools. This post details all the changes, the most notable being CodeMirror, an all in one solution for making permanent CSS and JS edits right in Safari. Cool.
I’m already a huge fan of Scott Jehl’s picturefill responsive images technique. It’s a simple javascript based polyfill that adds the proposed picture element to your site. I’ve used it repeatedly on my professional work and side projects.
But I noticed one important limitation of the base work; because it’s JS powered, there’s a brief moment where the pseudo picture element “pops into” the layout after the initial load. For some pages that effect is acceptable, but for my latest work, I needed more control on when the picturefill effect is activated.
That’s where this fork by developer Tyson Matanich was very helpful. It’s a simple but powerful idea: add an extra method to activate the picture element early before a full DOM load. However I found the rest of the extra options and functionality too much for what my project needed; instead I took the basic gist and forked my own copy of Jehl’s original for actual usage. Works great.
Web developer Louis Lazaris takes a novel approach to extended CSS instruction: spend $7 in the form of an e-book and get 83 solid CSS articles from Impressive Webs. No extra promos, no extra advertising. Smart.
I’ve read my share of CSS Flexbox tutorials and feature sites, but none that had the finesse and clarity that developer Philip Walton pulls off here.
I mostly have confined my Flexbox work to just smaller side projects or Chrome packaged apps, given the specifications limited compatibility among all modern browsers (Safari has a bit of catching up to do with Chrome but we’re almost there.) But damn do the showcase examples here make it tempting for future implementation. Even with fallbacks, the code here is just so clean and semantic.
Last week at my day job our team released a newly refreshed Pocket for web. (If you’re at all curious why my blog posts stopped dead midweek, it’s because my life has been fixated on launch and support issues. Thankfully there we few.) It’s been my main development and design focus for months. There’s a simplified navigation, recut reader view, keyboard shortcuts, and everything is noticeably faster. If you’re already a fan of save for later services, or you’re curious but never jumped in before, I’d encourage you to check it out.
With my current job I’m on a very small web team, with little delineation between developer, designer and QA. When you’re banging out code for an impending web release, it’s an environment that can be ripe for regression errors if you’re not careful.
Traditionally one of the best ways to combat regressions are with unit tests (ask any Rails developer.) But for front end developers and designers, there’s often limitations. Sure, you might get valid data from the back end, but how does it actually look and feel? That’s why so many of us rely on lots of repetitive, by hand testing.
Enter CasperJS, a framework perfect for front end unit testing. With a single Unix command running in the background a “headless” Webkit browser that runs through several core actions on my web app, taking screenshots along the way. As long as it stays updated, it’s a great way to check the basics before making any big commit. Great syntax and documentation too. If you’re a front end developer or QA, take a look.
It’s time for us to treat performance as an essential design feature, not just as a technical best practice.
Some may interpret Brad’s post as a shot against a traditional web design workflow. It is, and rightfully so. Too often, both in my own career and in talking with other developers, designers run off the Photoshop deep end without a lot of developer collaboration. They create something that is gorgeous, groundbreaking but in the end really slow. Or a team’s focus is just on shipping new web functionality without considering the performance impact.
Successful teams consider and optimize for performance. As Brad emphasizes, get into prototype form earl and if it’s too slow revise immediately.
Emmet LiveStyle is a Chrome extension paired with a Sublime Text plugin that transforms your CSS workflow. Install both tools and you get no BS live bi-directional CSS editing. To put it another way, either tweak in Chrome DevTools, your Sublime Text CSS file or both, and the changes immediately take effect on your page.
Admittedly LiveStyle isn’t perfect. First you have to be committed to Sublime Text as a text editor (which I’d highly recommend, but it isn’t for everyone). Setup can be sometimes annoying; when you switch to the tool in DevTools you’re often forced to assign CSS files you’re editing manually. Also it’s in beta, so expect occasional stability problems. But for the most part when you start getting in a CSS editing groove it’s pretty awesome.