scriptNode

Call it what you will. There's been much debate about the job title for a frontend engineer, or a web developer, or whatever name you prefer. What I'm referring to, however, are the folks who code for the browser. If you spend all day waste-deep in markup, CSS and JavaScript, then you do what I do and I'm talking about you.

And let's just skip right past Internet Explorer and its plethora of headaches, shall we? We all know it sucks. Here's why else it sucks to be one of us:

1. Everyone Thinks It's Your Fault

   So you're QA. You're testing a website and something is broken. It looks to you like the frontend, because that's what you see. What may separate good QA from excellent QA is the ability to determine where the error lies, but sometimes that's out of QA's scope.

   Regardless of who the owner is, chances are the issue will go to you first. You must then determine if it's even your issue, and either fix it, or pass it on. Bringing us to …

2. You Are Also a Project Manager

   The frontend is the very last thing to get done. That's because the design needs to be finished way in advance so that assets can be delivered, and the backend has to be complete before you have access to data to use in your implementation.

   This means that you must act as Project Manager to keep everyone else on track, because otherwise you can't ever get to work! And that's why …

3. You Always Seem Late

   Since you're the last one that gets to begin implementing, chances are you've got less time than everyone else. And sometimes you can't even get started until after your deadline! And even when you do finally get your assets and can get to it, sometimes …

4. You Must Know Photoshop

   To be fair, I actually use The Gimp, which works fine. What I mean by this point is that you must learn to use a competent image manipulation program. Why? Because although you may have an excellent design person/team, chances are they're not going to cater to you and your crazy CSS hacks.

   You know what I mean. Sometimes you're wanting to sprite your images to get better page performance, or sometimes you need to pull off some crazy rounded corners hack to get the positioning cohesive across browsers. You could go back-and-forth with design all day, or you could say "screw it" and alter the image yourself. It sucks but that's how it gets done. And that's part of …

5. You Must be a Jack-of-All-Trades

   In addition to competency with a decent image manipulation application, you're going to need at least a familiarity in many other areas. It's very rare to find a frontend engineer who doesn't ever need to modify at least some server-side code.

   For example, although I am official a frontend engineer, I probably spend 30-50% of my time in PHP. That's because, before I can even render the markup I need to tweak, I've got to setup the data I receive from the backend.

   Not to mention the various other tasks that randomly pop up in the webdev stack, such as Apache rewrite rules or cronjobs. I'm sure the same could be said for most jobs, but it seems like frontend engineers' skillsets must be broader than most.

But it's not all bad. Especially right now in Silicon Valley, frontend engineers are quite valuable, so it's a great time to know how to code for the browser. Either way, did I miss something? Let me know!

Haven't had a Script Sunday for a while, so here's a quick, simple script for you. Ever see those Loading … overlay images and wonder if JavaScript can handle it? Turns out it's extremely simple:

You can view this by itself in the lab.

About JSQL

When I started my new job, I had to make the transition from YUI to jQuery. I'd seen some jQuery code before (in fact, its terseness and use of $ as both an object and a function were easy to spot), but I wasn't familiar with it. I actually thought that the query part of jQuery meant there was some kind of Standard Query Language interface. There isn't, but there is a really cool CSS3 selector instead.

Turns out, I was a little disappointed; I wanted to use something query-based. So, I started to throw this script together. I call it JSQL. Below are some quick examples of what it looks like in action:

JSQL always returns an object with an error property that's either Boolean false or a String stating what error occurred (for example, "Unknown command UPDAT3"). If it successfully retrieves or operates on elements, it returns a count:Number property with the number of elements and an elements:Array property with those elements.

Here are some interactive examples:

Example 1: Checkboxes

Set Checked

Uncheck

Example 2: Form Validation

Highlight empty fields

Reset

Example 3: Removing Elements

Remove strong tags

In the spirit of jQuery, I also stuck in a quick each method which you can use to iterate through the returned elements immediately instead of setting up your own loop. The context is the current element (like jQuery) and the return value is still the same:

Example 4: Selecting Elements

Select & Operate

Undo

I started coding this several months ago, and just recently decided to revisit it. I found the code hard to read myself when making some modifications before publishing it here. That typically means it's poorly written. And I'm admittedly lousy at writing parsing code... so there's that. I also doubt it's realistic for any real-world websites (other libraries handle those jobs quite well), but I thought it would be fun to play with.

Some noticeable features lacking are equivalents to ALTER and INSERT INTO. I've also got it up on GitHub, so feel free to fork it, and maybe add those methods yourself!

• [Download jsql.js] (11k)
• [Download jsql-min.js] (3,661 bytes)