For the last nine months, I’ve been working with Ben and our team of fantastic contributors to modularize the Grunt codebase. Today, we’re happy to announce that Grunt v0.4 has been published to npm. Hold on to your hats, a lot has changed!
Lot of changes in Grunt.js. If you do JavaScript development, you should be using Grunt to make your life easier. If you’re already using Grunt, this is a must read, as there are a lot of changes in how it works, and how it’s installed.
Explore the changing worlds of JavaScript, HTML5, and more
Seems like a stellar conference on frontend technologies, focusing mainly on JavaScript, put on by the reputable O’Reilly Media company. Check out the videos on their official Youtube channel of previous talks at the conference.
Today I’m proud to announce the official opening of the jQuery Learning Center, a community-driven site dedicated to helping people learn about jQuery, JavaScript and front-end development.
This looks like a great resource so far JavaScript, jQuery, and frontend development, and further validates the need for this blog I think.
The Yeoman team are very excited to announce our 1.0 beta, fresh on npm and now available at http://yeoman.io.
I’ve extensively used Yeoman in my frontend workflow. And even given a presentation about using Yeoman to other developers. I recommend giving Yeoman a try in your frontend web projects. It is a great open source tool that encapsulates many other tools under one commandline interface that allows you to quickly do a lot of common tasks.
Again from their homepage:
MODERN WORKFLOWS FOR MODERN WEBAPPS
Yeoman is a robust and opinionated client-side stack, comprising tools and frameworks that can help developers quickly build beautiful web applications. We take care of providing everything needed to get started without any of the normal headaches associated with a manual setup.
I’ve mentioned the Susy framework before, but thought it was useful to bring up the concept of Responsive Web Design Layout Patterns. In this case we’re talking about “off canvas”, where elements are shoved out of the viewport (canvas), when a small screen is being used, and shoved back into the viewport, when the screen is large enough to accommodate the element. All of this can be decided by setting variables in the SASS in the Susy Framework. Makes rolling your own off canvas layouts much easier.
And I would be remiss if I didn’t mention Luke Wroblewski, whom I’ve seen at AEA conference, and attended his mobile workshop, and does fantastic work in the mobile space when it comes to Frontend Engineering. Check out his article on Multi-Device Layout Patterns.
Shortly after that, led by these first few web developers, Yahoo decided that all of those talented individuals were actually software engineers. Every single “web developer” became a “front-end engineer” overnight. They were now officially part of engineering, where they should have been all along. What followed was, in my opinion, the development of the greatest front-end community in the world. This was before Google became the place to work and long before Facebook and Twitter entered into the minds of engineers. A lot of the best practices we have today, especially in the realms of performance, progressive enhancement, open APIs, and accessibility, come directly from the work that was done at Yahoo during this period. By the time I arrived at Yahoo in 2006, the front-end community was vibrant and thriving, transforming Yahoo into a company that took incredible pride in crafting Web experiences. I was honored and privileged to be able to contribute to that community and work with all those people.
I probably owe it to Yahoo for formalizing the term “Frontend Engineer”, it seems. So many great things came out of Yahoo for Frontend Engineering, and so many great engineers I admire. I’ve always been a fan of Yahoo’s from a engineering standpoint. I tried, and used YUI, in the early days. Particularly the CSS reset, and the font normalizing CSS bits.
I started this blog in the hops of collecting all the amazing work being done in the engineering niche, known as Frontend Engineering. Places I’ve worked at did not have this position, or realize it’s a real needed position for someone to focus on.
Nicholas explains:
If your company isn’t setup this way, it’s time to make the case. Web developers are software engineers and should be treated as such. The overwhelming success of the front-end community at Yahoo serves as a lesson to all companies: when done right, you can attract a phenomenal amount of talent and do amazing things. Yahoo’s recent struggles aren’t a reflection of the front-end community, and as mentioned earlier, there are a lot of former Yahoos who are now trying to build proper front-end organizations in other companies.
Almost all of the “top companies” you can think of right now are thriving because of the contribution of front-end engineers. There’s still an arms race going on among Google, Facebook, and Twitter, trying to find and hire more and more front-end engineers. Make no mistake, this is our time. So the next time someone asks you what you do, simply answer, “I’m a software engineer.” Then you can explain that your focus is on making web applications.
I wholeheartedly agree. Some fantastic projects are coming out of Twitter, like Twitter Bootstrap, and Flight, recently. I hope more of these top companies continue the solidification of Frontend Engineering as a specialization.
I also agree with Nicholas on this point:
(Note: I’m intentionally skipping over the typically arbitrary distinction some make between “developer” and “engineer”. As far as I’m concerned, they mean the same thing.)
Exactly. I’ve worked at places where your title is simply “developer”, and I think it carries a stigma with non-technical folk. “Developer” (often referred to as “web developer”) is an odd word, whereas I think the older, “Engineer” term carries more meaning – to build, or to design. “Develop” sounds less cool, honestly.
Flight is a lightweight, component-based JavaScript framework that maps behavior to DOM nodes. Twitter uses it for their web applications.
Ever since Twitter Bootstrap was released, I wondered if Twitter was going to also open-source more of the JavaScript things they actually use on the public site. This web framework looks interesting.
Sleek, intuitive, and powerful front-end framework for faster and easier web development.
Twitter Bootstrap is my first choice, if I want an easy-to-implement frontend framework starting point in a new project. I’ve used the framework for simple things like documentation, to small business websites. It is very popular, and as of this post has over 44,000 github followers on it’s github project page!
Even if you don’t plan on using it, at least go code-spelunking, it’s the best way to learn something new. I like the direction of the upcoming Bootstrap version 3, as well.
We announced that Opera will switch its rendering engine to WebKit and JavaScript engine to V8 by building on top of Chromium (the open-source browser that powers Google Chrome).
The short answer is that it shouldn’t affect your day-to-day work. Keep coding to the standards, not to individual rendering engines; test across browsers - Opera, Firefox, Chrome, Safari and > Internet Explorer; use all vendor prefixes and an unprefixed form in your CSS and JavaScript. However, it remains important to keep the following in mind:
Chromium, and therefore future versions of Opera, has built-in support for the WebM, Ogg Theora and Ogg Vorbis media codecs but does not natively support H.264 or MP3 media codecs (although if these are installed in a device’s operating system it will allow that to render media). The correct way to check support is with HTML5 canPlayType. The simplest method to ensure all modern browsers receive the correct codecs is to encode in both WebM and H.264 and provide two elements or use canPlayType to check support (see Introduction to HTML5 video for more information).
The window.opera object will not exist in future versions of Opera. We continue to recommend that developers SHOULD NOT use browser-sniffing; feature-detection - either using a 3rd party solution such as Modernizr or hand-rolling your own - is better.
I use Modernizr extensively in my last few projects. Highly recommended.
Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser.
Why use Modernizr?
Taking advantage of cool new web technologies is great fun, until you have to support browsers that lag behind. Modernizr makes it easy for you to write conditional JavaScript and CSS to handle each situation, whether a browser supports a feature or not. It’s perfect for doing progressive enhancement easily.
I can’t recommend this JavaScript library enough. It makes progressive enhancement a whole lot easier.