I spent this weekend rushing between two different gatherings that were both labeled as front-end events. One focused on front-end MVC and Node.js; the other was an HTML5 Code Jam. By the end of it, I was no longer sure that calling both of them “front-end” gatherings was even accurate.
At the MVC session, someone who had attended several of these meetups raised a thought that clearly had been on his mind for a while: maybe this stuff is no longer front-end at all. Then he corrected himself—maybe it is not front-end, but JavaScript.
That single remark opened the floodgates. People jumped into discussion right away, though the conversation did not stay there for long. Soon everyone had moved on to more familiar questions: what MVC is good for, whether dividing work along MVC lines helps or hurts, whether separation of responsibilities is better than not separating them, and so on. But that earlier question stayed with me.
I understood exactly where that feeling came from. Isn’t front-end supposed to be about presenting pages? For a long time, the focus was on interface, visual effects, and browser compatibility. So where did all this data communication, logic handling, and object modeling come from? Is that still really “front-end”?
MVC was one thing. Then came Node.js.
The speaker walked through, in a calm and enthusiastic way, how to build the backend for a blog using Node.js and JavaScript—the language front-end engineers know best. That pushed me even deeper into this line of thought. If MVC still carries some trace of front-end work, calling Node.js front-end starts to feel like a stretch. As front-end engineers, what are we actually supposed to do? What value are we meant to create?
Before I had sorted that out, I went to the HTML5 event and found myself staring at a dazzling landscape: Canvas, WebGL, Audio, Notifications, LBS, WebSocket. Some of these seemed even farther removed from what used to count as front-end. LBS and WebSocket, in particular, felt completely outside that traditional boundary. Canvas and WebGL do belong to the presentation layer in some sense, but they are built through pure programming: collision calculations, matrix transforms, coordinate math. At that point, how different is it from Win32 drawing or OpenGL rendering?
What HTML5 opened up was not just a larger front-end world. It was a path into application development as a whole.
That made me realize I had been living with this blurred identity for a long time. As someone with a computer science background working in front-end, I had probably absorbed the same hierarchy many others had: compared with traditional Win32 development, backend engineering, or newer Objective-C development, front-end was often treated as the least prestigious of the lot. Under that kind of long-term pressure, it is not surprising that a certain urge appears when JavaScript APIs suddenly explode in number and power. You start wanting balance. You start wanting recognition.
In that sense, HTML5 did more than lead a technical shift. It also happened to satisfy a particular emotional need among front-end developers—especially those who were used to being looked down on by “serious” developers, lately including the newly prosperous crowd around iOS development. HTML5 offered a chance to raise one’s status, stand shoulder to shoulder with native developers, and at the same time separate oneself from other front-end practitioners.
But if the goal is truly to stand on equal footing with native development, then mastering JavaScript is not enough. What matters more is having the perspective and way of thinking that come from traditional software development. At that point, sensitivity to views and styles becomes less central. It is entirely possible for someone to be comfortable with Node.js, WebSocket, and LBS, yet still struggle with something as basic as a three-column layout from classic front-end work.
So should a front-end engineer still learn HTML5?
I think the answer depends on what kind of work you believe you are doing.
If you want to stay focused on front-end in the truest sense, then it absolutely makes sense to pay attention to new HTML elements and attributes, and to CSS3. Beyond that, a general understanding of the rest is enough. Instead of spending all your time going deep into data structures and algorithms, network communication and distributed computing, or database management, it may be more worthwhile to invest in user experience, interface design, practical image-slicing skills, and the kind of observation of everyday life that leads to good front-end instincts.
If, on the other hand, you see yourself first and foremost as a programmer, then it makes sense to seriously build up experience in traditional application development, to study software engineering and mathematics more deeply, and to learn the domain knowledge related to the products you work on. In that case, the job should be treated as programming in the purest sense.
Of course, one person can pursue both directions. The important thing is to recognize that they are not the same thing.
When we talk about HTML5, it would be a mistake to let the excitement around it erase front-end itself. It is worth looking at front-end’s actual responsibilities clearly, and being equally clear about our own role. Not long ago, at the WebRebuild.ORG annual conference, seeing the old phrase “web page reconstruction” again—already a little unfamiliar by then—felt strangely interesting when set against all the changes of the past year.
At the very least, today I feel that front-end and HTML5 are two different things.