You know, we use ad-blockers as well. We gotta keep those servers running though.
Did you know that we publish useful books and run
friendly conferences — crafted for pros like
yourself? E.g. our upcoming SmashingConf Barcelona,
dedicated to smart front-end techniques and design patterns.
Nicholas C. Zakas is a principal architect at Box, as well as an author and speaker. He worked at Yahoo! for almost five years, where he was front-end tech lead for the Yahoo! homepage and a contributor to the YUI library. He is the author of Maintainable JavaScript (O’Reilly, 2012), Professional JavaScript for Web Developers (Wrox, 2012), High Performance JavaScript (O’Reilly, 2010), and Professional Ajax (Wrox, 2007). Nicholas is a strong advocate for development best practices including progressive enhancement, accessibility, performance, scalability, and maintainability. He blogs regularly at https://www.nczonline.net and can be found on Twitter via @slicknet.
It was the summer of 2013 and I was working on a project for my employer, Box. I had just finished wiring up JSDoc as a nightly build using a plugin to detect T3 patterns in our code and document them automatically. It occurred to me that these patterns might be easy to get wrong, and I started looking for a way to automatically detect incorrect patterns. I immediately turned to JSHint because we were already using it and I thought it could support plugins. Unfortunately, it could not.
Still, I couldn’t get the idea of a linter with pluggable runtime rules out of my head. I had just spent a bunch of time learning about Esprima and abstract syntax trees (ASTs), and I thought to myself, “It can’t be all that hard to create a pluggable JavaScript linter using an AST.” It was from those initial thoughts that ESLint was born.
A while back, I wrote a post about starting an open-source project. The focus of that article was on starting an open-source project as an individual. I received a lot of positive feedback and also some questions about how the process changes when you’re open-sourcing a project at work.
Many companies are starting to investigate and participate in the open-source community, and yet few guides for doing so exist. This article focuses primarily on the process of open-sourcing a project at work, which brings with it other concerns and decisions.
At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.
After some initial missteps, the project finally hit a groove, and it now regularly get compliments from people using and contributing to CSS Lint. It’s actually not that hard to create a successful open-source project when you stop to think about your goals.
When I was studying computer science in college, I had one extremely tough professor. His name was Dr. Maxey and he taught the more complicated courses like data structures and computer architecture. He was a wonderful teacher with a talent for articulating difficult concepts, but also an extremely tough grader. Not only would he look over your code to make sure that it worked, he would take off points for stylistic issues. [Links checked February/17/2017]
If you were missing appropriate comments, or even if you misspelled a word or two in your comments, he would deduct points. If your code was “messy” (by his standards), he would deduct points. The message was clear: the quality of your code is not just in its execution but also in its appearance. That was my first experience with coding style.
Earlier this week we published two articles by Louis Lazaris: one on why old browsers are holding back the Web and another encouraging Web users to upgrade their browsers and use modern browsers other than IE. This article presents another perspective on this issue. Nicholas C. Zakas, a well-respected member of the developer community, goes into specifics of why we should focus on the good parts of our job so we can tolerate the bad ones and why fixating on circumstances that you can’t change isn’t a recipe for success. Do you share Louis' or Nicholas' view? Leave a comment.—Ed.
A couple of days ago, Smashing Magazine published an article entitled, Old Browsers Are Holding Back The Web. The author of this article, Louis Lazaris, suggests that “old browsers” are holding Web developers back from creating beautiful experiences. Old browsers, in this case, apparently referred to Internet Explorer version 6-9. That’s right, the author groups Internet Explorer 9 into the same group as Internet Explorer 6. He goes on to list some of the things that you can’t use in Internet Explorer 8 and 9.
