Technology moves fast. Each year I try to take some time to evaluate my own skill set and prune skills that are no longer relevant to make way for the new and more promising. I write this article through the lens of a freelance, full-stack developer, which means that I need to know, and be proficient in, many different technologies, and be able to choose the best one for the situation. Certainly, there are many different types of web developers, and many different levels of specialization amongst those developers. This list applies to my specific situation. However, my situation is fairly common and I believe it applies to many others as well.
The most significant change for 2014 is pruning the native platforms in favor of front-end frameworks like Ember. This is a gamble, as native apps very well could win out. I believe it's more likely that ultimately there is room for both. I'm a web developer, and I root for "team web". In the past I spend a bit of time learning the Android platform. In retrospect, this was a mistake. Very few developers are excellent in both native and web technologies. In my case, that time spent on Android skills would have been better spent on my own technology stack.
Note: this goal is in direct response to Paul Irish's challenge to web developers.
JavaScript is clearly the hottest web development language around. Even if we ignore NodeJS, and focus only on client-side development, more and more computation is moving to the browser. JavaScript and JavaScript frameworks are extremely important in the ability of web developers to keep pace with the native platforms. My most important goal in 2014 is to learn EmberJS very well.
I believe Rails is the best server-side framework out there. Any time spent honing skills on Rails is time well-spent.
Last year I was still using WordPress by default, and Rails if it made sense. This year, I'll use Rails unless the site is simply content based, with little or no custom functionality. The reason for this change mostly comes down to hosting. It used to be that Rails hosting was expensive and hard. Heroku is great, but is expensive and can be complete overkill if all you need is a simple blog. With services like Digial Ocean, the game has changed a bit, and I can deploy a Rails site with WordPress-like costs.
I still think WordPress is a fantastic tool, I have just narrowed the scope for which I think it is appropriate. There is no question that it is the best tool for a content heavy site with or without blogging. I'm less of a fan of WordPress as an application platform. It has always felt like a bit of a hack in those situations - it's hard to test, the code tends to be very procedural without standard patterns such as MVC. I've never been a fan of the way PHP mixes presentation with business logic, especially without a framework to help separate these concerns. In addition, I find client-side performance to be much harder than it should be in WordPress, and tends to be ignored.
Basically, if I'm going to have to write custom code, other than in the theme, I'm just going to use Rails.
This year, I've moved to a preprocessor by default. My preferred preprocessor is SASS, with either Compass or Bourbon as the mix-in library. I have yet to decide between Compass or Bourbon, which is perhaps the topic of a future blog post. Last year I was using SASS only with Rails projects, as Rails makes it so easy. This year, due to help from tools like Grunt, I'm using SASS even with static sites and non-Rails applications.
Performance has always been important, I'm just making a concerted effort this year to improve my skills in this arena, and keep the performance of a site front a center in terms of importance.
Client side performance has become much easier to analyze with tools such as the Chrome Dev Tools. Learning to use this tool is well worth the time.
There are a ton of improvements that I could make on every single WordPress site that I work with, including this very site. I find concatenation and minification of CSS and JavaScript is hard in WordPress, especially when you have plugins that add their own .css and .js files. One of my goals this year is to evaluate static site generators such as Jekyll, simply for the purpose of performance.
I hope to write several articles around performance as I dig in further.