In the early days of the web, almost all brick-and-mortar companies woefully under-invested in digital technology and product development. These days everyone has a website and even a mobile app or two. But the shift to mobile is so rapid that many companies are in danger of repeating the same mistake and under-investing in mobile.

At The New York Times, we are determined not to fall into that trap. Not only are we focusing more technology resources on mobile development, we are also rethinking how our newsroom and product development teams operate so that we can become a mobile-first company. And when we say mobile, we mean smartphone.

Defining ‘mobile’ as a smartphone is problematic for a few reasons. Does Frons mean a smartphone app or a smartphone website? Is it both? Do tablets with cell service or smartwatches count? Frons seems to be implying that mobile means mobile app (or multitude of apps in the case of The Times) when he advises:

If you’ve got 30 engineers on the web and three on mobile, you’ve got to even that balance out quite a bit. If you’re spending 80 percent of your money on desktop and 20 percent on mobile, it should probably be 50/50 at least, if not tilting the balance toward mobile just in terms of playing catchup.

I agree there needs to be a better balance if you have those kind of numbers, but personally I don’t think there should be such a strong distinction between desktop and mobile for news businesses. The news should be the same on whatever device you choose to consume it on web engineers should be working on building responsive and mobile-optimized sites. There doesn’t need to be a desktop web team and a mobile web team—but I get the impression from this article that this is what The Times has.

Frons adds another piece of advice without providing any evidence for his claims, offering it up as a “reminder”:

Remember that mobile is a push medium, that notifications have become crucial for driving traffic – reminding people that you’re there, stimulating awareness and encouraging usage.

I’d like to see numbers to back this up. I agree that notifications increase traffic, but that doesn’t imply that they’re crucial for a news company or that mobile is a push medium. Mobile is a multidirectional communication medium.

Source

We created a site that makes a new priority of visual presentation, that offers a cleaner reading experience across digital devices, and that gives us the flexibility we need, both in our articles and on our homepage, to join the speed and urgency of the web with the noise-cutting and impact that have always been central to The Atlantic’s ambitions.

And:

Oh, and the typefaces are new. Hawk-eyed readers will recognize the display and text fonts, both Lyon, as the same ones we use in print.

In addition to the typography, the attention to detail in the Atlantic’s redesign is top notch. Moreover, they did it all in house. My favorite feature is a subtly which no one seems to get right. Almost every site with a sticky header ignores the fact that some people use the keyboard to navigate the page. Pressing the spacebar generally scrolls the page up so you can continue reading from the bottom, but this behavior doesn’t work when you use a fixed header. The text the reader expects to see ends up below the header, which isn’t a great experience. When your on the Atlantic’s new site and you press the spacebar you’re taken to the correct location on the page with the fixed header offset. These are the kind of details that add up and make the difference between good and great.

Source

In viewing the time to first byte, we get some insight into the time the web server takes to process a request from a given location and connection speed, and perhaps how much network latency is factoring into the round trip to the server and back (which is, as Ilya Grigorik kindly points out, the web’s current performance bottleneck).

Lot’s of solid performance advice in here as well an interesting look at the recent Wired website redesign and how a few small changes can significantly improve perceived web performance.

Source

Jason Snell reviews the new MacBook:

The MacBook’s retina display is physically 2304 by 1440 pixels. In standard “2x” retina mode, that means the 12-inch display should look like a non-Retina display at 1152 by 720 pixels. While that’s an option in the Display preference pane, by default the MacBook displays at a scaled resolution that’s the size of a 1280 by 800 pixel display, more or less the same amount of real estate as an 11-inch MacBook Air. That’s also the resolution that the 13-inch Retina MacBook Pro displays at, but on that screen it’s the native 2x resolution—here, the MacBook is drawing a 2560 by 1600 pixel interface and then scaling it down to fit in 2304 by 1440 pixels.

I’m surprised that the new Macbook doesn’t ship with the native resolution set by default. My guess is that it might be related to LCD panel cost, but either way it seems like a smart move to scale it down — working with less than 800px vertical display pixels feels cramped.

High performance HTML

That’s click bait for me. There was only one performance tip in here — inlining CSS. Otherwise it’s mostly basic HTML authoring advice, or if there are performance benefits to some of the style suggestions, they’re not discussed.

I wasn’t aware that li tags don’t require being closed though.

The original source code for jQuery. Including annotations from Jon Resig:

I want to just take a moment to note how little has changed in how these functions work, at an API level. There’s a strong chance that you could take circa-2006 jQuery-using code and drop in a modern version and have it still work. Granted much more was added later on, as it increased in scope beyond my simple use cases, but almost all of the API that we see here was left intact. I’m definitely proud of the fact that the API was “good enough” to last over the next decade — and beyond.

It’s kind of amazing that the original version of jQuery wasn’t even 700 lines of code — a good reminder that even really big projects start out small. Via Jeremy Kieth.

Software development has a gender balance problem. Our internal stats suggest the imbalance isn’t quite as severe as the survey results would make it seem, but there’s no doubt everyone who codes needs to be more proactive welcoming women into the field.

From over 25,000 web developer survey respondents, 91% identified as male. I’m interested to see how much this differs from their internal stats because it seems in line with my own personal observations — which is a shame.

Source

Useful for getting your head around semver, or double checking your logic for more complicated version dependencies.

Source

Really cool visual SVG optimizer from Jake Archibald built on the Node.js SVGO module.

SVGOMG

Love the design. This kind of approach is definitely the future of info graphics.

Source

A good follow up to Rebecca Murphy’s 2012 recommendations for baseline skills for front-end web developers. It’s always tough to pin down what the essential skills of the field are or should be as it seems like acquiring new knowledge on a daily bases is a job requirement for front-end web developers.

The main point I took away from this is that on top of understanding JavaScript, we should all be using the tools we have available to us (build tools, versioning, dependency management, the shell, etc) and know how to use them well to in order to automate repetitive tasks, eliminate errors, and ultimately be more productive.

Source