Links Archives: 2016

All 44 links
  1. Homebrew Website Club DC

    Are you building your own website? Indie reader? Personal publishing web app? Some other digital magic-cloud proxy? If so, come by and join a gathering of people with like-minded interests. Bring your friends that want to start a personal web site. Exchange information, swap ideas, talk shop, or help work on a project.

    I’m organizing the first of what I hope to be many Homebrew Website Club meetups here in DC. I want to encourage anyone interested in building their own website to attend, regardless of skill level.

    Hope to see you out at Busboys and Poets next Wednesday night!

  2. Chunked transfer encoding in Rails (streaming)

    Using the Transfer-Encoding: chunked header, the server will send chunks of the rendered page back to the browser so in the case of Rails, it starts with the layout and sends out the <head> part including assets like js and css.

    Chunked transfer encoding is a great way to improve page performance for the parts of your application that require time-consuming database queries. The Rails-level changes are straightforward, but unfortunately not all Ruby web servers support the feature (looking at you, Puma).

  3. The future of loading CSS -

    Chrome’s about to change how it handles <link rel="stylesheet">. This is big news and Jake’s got the rundown:

    The plan is for each <link rel="stylesheet"> to block rendering of subsequent content while the stylesheet loads, but allow the rendering of content before it. The stylesheets load in parallel, but they apply in series. This makes <link rel="stylesheet"> behave similar to <script src="…"></script>.

    It’ll take some getting used to sprinkling <link rel="stylesheet"> throughout a page’s <body>, but the performance benefits (coupled with HTTP/2) will be worth it.

  4. Visions of the Future

    Imagination is our window into the future. At NASA/JPL we strive to be bold in advancing the edge of possibility so that someday, with the help of new generations of innovators and explorers, these visions of the future can become a reality. As you look through these images of imaginative travel destinations, remember that you can be an architect of the future.

    This collection of WPA-style travel posters from NASA/JPL appeals to my interests.

  5. Issue and Pull Request templates

    GitHub added the ability for project maintainers to add issue and pull request templates to projects.

    To add an Issue template to a repository create a file called ISSUE_TEMPLATE in the root directory. A file extension is optional, but Markdown files (.md) are supported. Markdown support makes it easy to add things like headings, links, @-mentions, and task lists to your templates.

    Thinking this will prove quite useful on some of my projects.

  6. Homebrew Website Club DC 2/24/16

    Are you building your own website? Indie reader? Personal publishing web app? Some other digital magic-cloud proxy? If so, come by and join a gathering of people with like-minded interests. Bring your friends that want to start a personal web site. Exchange information, swap ideas, talk shop, or help work on a project.

    Next week’s Homebrew Website Club will be downtown at LivingSocial’s offices near the White House! Come by, share what you’re working on, and hack away at your personal website.

  7. Maintenance, Operational Concerns, and Cost — Chronic Build Failure — Medium

    Jon Daniel on software maintenance:

    I’ve realized that successful applications in an “Enterprise” environment spend far more time in maintenance mode then they do being actively developed. Consumers of your application don’t care that you used some cutting edge framework or state-of-the-art architectural patterns. They just care that it works and continues to work well.

    Jon goes deep on operational concerns and posits:

    Software is not done until it is decommissioned.

    I couldn’t agree more.

  8. Imagining the Web of Things with Stephanie Rieger and Jonas Sicking | The Web Ahead

    I find myself with IoT talking about progressive enhancement all the time, even though it’s a Web thing, but it makes even more sense. Really, it should be the thing it was designed to be first and then the smarts layered on top.

    Stephanie Rieger on a recent episode of The Web Ahead podcast, speaking with Jen Simmons about designing network-connected physical devices—ahem the Internet of Things—with the philosophy of progressive enhancement baked in. Sure, you could build a Web-connected light switch, but if it isn’t first a well-designed light switch, you’ve missed the mark.

  9. Notes on Using ARIA in HTML

    This document is a practical guide for developers on how to add accessibility information to HTML elements using the Accessible Rich Internet Applications specification [WAI-ARIA-1.1], which defines a way to make Web content and Web applications more accessible to people with disabilities. This document demonstrates how to use WAI-ARIA in [HTML51], which especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

  10. Yellow Lab Tools

    A cool new front-end performance analysis tool from Gaël Métais that offers code improvements.

    This is done by loading the webpage via PhantomJS and collecting various metrics and statistics with the help of Phantomas. These metrics are categorized and transformed into scores. It also gives in-depth details so developpers can correct the detected issues.

    Yellow Lab Tools dovetails nicely with more popular performance tools like WebPageTest.

  11. Collaborate and listen. - LivingSocial's Technology Blog

    Champion good ideas.

    It’s one of LivingSocial’s company values and it’s what I’m here to do today. The idea? Creating the kind of environment where your team is comfortable asking questions & thinking out loud.

    My brilliant co-worker Sara on the importance of asking questions and thinking aloud. Few things are more devastating to a company’s culture—and detrimental to the organization’s success—than making team members feel they can’t speak up or ask questions.

  12. Mobile Web Stress: Understanding the neurological impact of poor performance

    Slides from Tammy Everts’ 2013 presentation on the neurological effects of poor performance on our websites’ visitors reveal some startling facts. Right out of the gates, Tammy cites a 2010 EEG study of users navigating a site on a connection throttled from 5MB to 2MB. The study found that participants had to concentrate up to 50% harder and reported a negative brand association afterward.

  13. Homebrew Website Club DC 3/9/16

    Are you building your own website? Indie reader? Personal publishing web app? Some other digital magic-cloud proxy? If so, come by and join a gathering of people with like-minded interests. Bring your friends that want to start a personal web site. Exchange information, swap ideas, talk shop, or help work on a project.

    We’ll be back at LivingSocial this week for another edition of Homebrew Website Club. Come on by, share what you’re doing with your personal website, and learn about what others are doing with theirs.

  14. How Changing WebFonts Made 10x Faster

    Nate Berkopec’s article is chock full of useful information, but I was particularly taken by his framing of a developer’s job (emphasis his):

    As developers, our job isn’t to tell the designers “Hey, you’re dumb for including over 500KB of WebFonts in your design!”. That’s not their job. As performance-minded web developers, our job is to deliver the designer’s vision in the most performant way possible.

    Equally interesting, but more technically-focused, is the rundown of how Google Fonts takes advantage of the unicode-range property to deliver smaller fonts.

    The unicode-range property describes what characters the font supports. […] By telling the browser what characters the font supports, the browser can look at the page, note what characters the page uses, and then only download the fonts it needs to display the characters actually on the page.

    Brilliant. I switched to serving fonts from Google and trimmed 45–70 kilobytes from my homepage. Your mileage may vary, but… not bad.

  15. Ignacio Villanueva interviews Jeremy Keith

    I’ve come to realise that the real power of the web lies in its ubiquity. Just as Tim Berners-Lee first intended, a website can be accessed on any device with any browser as long as there’s some kind of internet connection. That still amazes me. And it continues to break my heart when I see people choose to deliberately ignore that superpower and build sites that only work for a subset of people.

  16. Bookmarklets are Dead…

    I posted yesterday on Twitter about an issue I ran into when trying to use a bookmarklet on a website—GitHub, in this case—with a Content Security Policy. Instapaper developer Brian Donohue pointed me to a post he’d written on just this issue in 2014.

    The ultimate catch-22 of the new Content Security Policy wording is that it’s intended to benefit the users, by providing additional security from hypothetical malicious add-ons on websites that enforce a Content Security Policy. In the end the bookmarklet has been relegated obsolete by the change, a casualty of one clause in one section of one web specification, and end-users and developers are the ones who will mourn its demise. The path to hell is paved with good intentions.

    I’ve implemented a CSP on my own site and have now switched from using Instapaper’s bookmarklet to their Safari extension.

  17. Adactio: Journal—Bookmarklets

    Jeremy throws cold water on Brian’s bookmarklet article I linked to yesterday.

    Bookmarklets are not dead. They may, however, be pining for the fjords.

    Like Jeremy, I have a simple bookmarklet for saving links to my own site. My bookmarklet opens a new window/tab, passing via URL parameters the URL and title of the current window/tab to a page on my site. If I’ve highlighted some text in the page, the bookmarklet will grab that and insert it into the body field on my link form, prepended with a > (the Markdown syntax for a <blockquote>).

    Easy peasy.

    Not-so-humorously, that last piece doesn’t work on overly-clever sites like Medium that monkey about with browser-native user interface. Neutral face emoji.

  18. Web Development is a Balancing Act — Medium

    Google Chrome Developer Advocate Matt Gaunt publicly answers some Web performance-related questions he received. Many of the questions have to do with frameworks, a topic of great interest to me.

    A slow website, no matter how it’s built, means someone didn’t notice, didn’t care or couldn’t fix the problem. That doesn’t mean the framework or tools used to build it is the problem, it could be the way those tools have been used.

    It could also be that the chosen tool isn’t the best solution to the problem at hand.

  19. Answers to Questions About Performance — Google Developers — Medium

    Google’s Paul Lewis answers the same questions that Matt Gaunt received (and that I previously linked to). Paul’s focus on the user and their experience of our work resonates strongly with me and is something I harp on quite frequently.

    I think performance, accessibility, and security share some traits: they can’t be retro-fitted to a project, they’re often thankless tasks, and they’re only notable by their absence. They’re all, however, the bedrock of a good user experience, onto which you can layer high quality designs and interactions.

    Paul also cites one of my favorite documents, the W3C’s HTML Design Principles:

    In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.


  20. Removing Headaches from Focus Management | Google Developers

    An exciting accessibility change is coming to Chrome 50. Google calls it “focus starting point” and it’s a small—but incredibly helpful—change to how their Web browser manages focused elements and tab order.

    If something has focus, it’s also the focus navigation start point, just like before. Also, just like before, if nothing else has set the focus navigation start point, then it will be the current document or, if available and supported, the currently active dialog. If we navigate to a page fragment like in the example above, that will now set the focus start point. Also, if we click any element on the page, regardless of whether it is focusable, that will now set the focus navigation start point. Finally, if the element which was the focus start point is removed from the DOM, its parent becomes the focus start point. No more focus whack-a-mole!

    As the article explains, prior to this change, focus management can be difficult when tabbing around and moving within a document (or into and out of modal dialog boxes). Take heed of the note in the article’s caveats section:

    Sequential focus navigation starting point is currently only supported in Chrome 50, Firefox, and Opera. Until it is supported in all browsers you’ll still need to add tabindex="-1" (and remove the focus outline) to your named anchor targets.

  21. Homebrew Website Club DC 4/20/16

    Are you building your own website? Indie reader? Personal publishing web app? Some other digital magic-cloud proxy? If so, come by and join a gathering of people with like-minded interests. Bring your friends that want to start a personal web site. Exchange information, swap ideas, talk shop, or help work on a project.

    After a brief hiatus, Homebrew Website Club returns to LivingSocial next week. Come on by, share what you’re doing with your personal website, and learn about what others are doing with theirs.

  22. How did Hitler rise to power?

    Decades after the fall of the Third Reich, it feels impossible to understand how Adolf Hitler, the tyrant who orchestrated one of the largest genocides in human history, could ever have risen to power in a democratic country. So how did it happen, and could it happen again? Alex Gendler and Anthony Hazard dive into the history and circumstances that allowed Hitler to become Führer of Germany.

    Jason Kottke shared this excellent video which gives a high-level overview of Hitler’s rise through the ranks of German government in the run up to World War II. As chance would have it, I’ve recently been reading up on the very same subject (thanks, Wikipedia).

    The video is part of a TED-Ed lesson that includes additional links and resources.

  23. Adactio: Journal—The imitation game

    Jeremy, on how he thinks about building progressive web apps:

    In my opinion, the term “progressive web app” can be read in order of priority:

    1. Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.
    2. Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
    3. App—sure, borrow what works from native apps if it makes sense for your situation.

    He also links to Jason Grigsby’s Designing Responsive Progressive Web Apps which is another great read.

  24. [Insert Clickbait Headline About Progressive Enhancement Here], From the Notebook of Aaron Gustafson

    In a lengthy response to a hyperbolic, ill-informed opinion piece, Aaron Gustafson describes progressive enhancement:

    It’s a philosophy that recognizes the nature of the Web as a medium and asks us to think about how to build products that are robust and capable of reaching as many potential customers as possible. It isn’t concerned with any particular technology, it simply asks that we look at each tool we use with a critical eye and consider both its benefits and drawbacks. And it’s certainly not anti-JavaScript.

    I spent a good deal of time in 2015 writing and speaking on the benefits of this approach to designing and building for the Web:

    The observant reader would note that Aaron and I address the same tenuous arguments made—coincidentally—by the same people.