One problem is that many people associate front-end development mainly with HTML and CSS. HTML and CSS are not programming languages.
I say this a front-end developer who has to write HTML, CSS and JavaScript on a daily basis. Yes, strictly speaking, HTML and CSS may be considered programming languages, but they lack control structures, design patterns and other interesting tenants of computer science. Like the author, I'm much more drawn toward the CS-related tasks of the job such as writing JavaScript.
To be clear, I have an enormous amount of respect for people who enjoy the design aspects. Writing CSS, using Photoshop, etc., requires a lot of skill. My point is simply that there is a divide among those front-end developers who are drawn toward programming and those who are drawn toward layout and design.
As more sites gravitate toward complex JavaScript-driven web apps, it may be useful to ditch the general term "front-end," differentiating C.S.-oriented front-end developers from those who prefer visual design.
This might make the expectations of a front-end development position much clearer, allowing for a simpler interview process.
Post author here. I agree 100% that HTML and CSS are not programming languages. However, any application that you build on the front-end is going to require your JavaScript code to interact with the HTML and CSS, so a solid understanding of how all the pieces fit together is crucial.
I can't tell you how many times I've seen back-end engineers hack together a 100+ line JavaScript solution to a problem when one line of CSS would have fixed it.
If you don't know CSS, HTML and DOM very well, then you're probably going to be over-engineering your front-end apps.
Any book recommendation? I can say I know JS as a language sufficiently well (I can write basically anything on Node), but I almost completely lack a systematic understanding how the HTML+CSS and DOM work together (layout engine, rendering, etc). I have some basic knowledge here and there, but reading "We need to make outside div relative to be able to use absolute on the inner one" leaves me staring out of the window.
The problem is, it's even more subtle than that. Sometimes, the right way to do something is by setting classes (or even, god forbid, inline styles) on the DOM using JavaScript, and sometimes it's better to use CSS. Sometimes it's debatable which way is better.
It's definitely a tricky area of development, that's for sure; pitfalls and subtleties abound.
> strictly speaking, HTML and CSS may be considered programming languages, but they lack control structures, design patterns and other interesting tenants of computer science.
They are non-Turing-Complete programming languages, and part of that is having limited control structures. "Design patterns" aren't a language feature, have nothing to do with being a programming language (architecture has design patterns -- in fact, that's where the term comes from), and CSS and HTML both have design patterns (and piles of books describing them.)
> As more sites gravitate toward complex JavaScript-driven web apps, it may be useful to ditch the general term "front-end," differentiating C.S.-oriented front-end developers from those who prefer visual design.
There's already a distinction commonly made between "front-end developers" vs "designers". What more do you think is needed?
> Wrong! CSS is in fact a turing-complete language. :) I know it sounds weird, but it's true. Turing-completeness can be formally proved for CSS.
Where's the proof?
I am aware of a supposed proof that CSS3+HTML5 is Turing complete (but it relies on specified user interactions that aren't part of the defined execution of semantics of either language), but I've never heard of one CSS itself.
I didn't mean that it can be proof to CSS independently of HTML of course. And I suppose this requirement is obvious at least because CSS is not executable without HTML at all.
Anyway it seems you are quite familiar with the topic, and I believe you heard all the recent buzz around rule110 etc. But a lot of people don't know about this interesting fact yet.
I always assumed that the term "engineer" in "front-end engineer" implied software engineering capability. Although, like usual, it's dangerous to make assumptions.
In the context of software "engineering"/programming, the term engineer has been bastardized to the point of losing all meaning. To call someone who programs at all an engineer is, in my opiinion, embarrassing, especially when juxtaposed with actual engineers (e.g. mechanical, acoustical, aerospace etc.) who went through a hell of a lot more to be able to be called an engineer than a 4 year CS program. People like John Resig, Jeremy Ashkenas can lay claim to being software engineers. Your average moron just out of college? Don't think so.
How about your average moron with an engineering degree like me?
In Canada, there's a very strict definition for engineer. If you don't have an engineering degree from an accredited university, and a professional designation, you cannot call yourself an engineer. They take it very seriously since it's a regulated profession.
Obviously everyone is free to draw their own lines (outside of Canada at least).
I always thought an engineer was someone who puts scientific or mathematical theory into practice and to solve technical problems. I'm ok with someone giving themselves the title of engineer if they do that for a living. On the other hand, they should not call themselves a "Professional Engineer" without the proper accreditation.
>I always thought an engineer was someone who puts scientific or mathematical theory into practice and to solve technical problems.
100% agree. In the US I don't think it's as strict as Canada (may be wrong) but I know one has to take an FE to be called one. People in the software field, however, running around themselves engineers are more often than not, not putting any theories into practice but instead using the tools that actual software engineers (those that create software packages/tools/languages/compilers etc) make, essentially making them a journeyman of sorts.
The FE exam is to become a licensed professional engineer. It is certainly not required to be considered an engineer, and is considered a waste of time if you are doing work that does not require it. The license is most effective for civil engineers, because building/bridge/etc designs need to be approved by a licensed engineer for regulatory purposes. It was pretty common for mechanicals to take the exam too. I assume it would be beneficial to get it if you are doing any sort of government related work.
I studied computer engineering and have no desire to take the FE exam, as being licensed is almost entirely useless in my field. As far as the difference between "engineers" and CS majors, at my school basically the only difference is math requirements, and how math is used in the higher level classes. In ECPE (computer/electrical) we differentiate ourselves from CS by studying circuits, systems, physics which are very calculus-intensive. The area where it crosses over into CS is when you get into computer architecture, digital design, assembly, which is like programming, but due to being so close to the hardware level (working with raw digital logic) it ends up being more math intensive than most high level programming.
That is actually kind of happening. People are becoming their own front-end doctors by Googling their medical problems. In fact, this is how I've handled health issues myself. I haven't been to the doctor basically since high school (just optometrist). I assume this is similar to the way a lot of people become "software engineers".
I agree completely. At the company I work for, we develop a complex client-side js app. We've got "backenders" who write Ruby, "frontenders" who write CSS + HTML, and "middlenders" who write really fucking awesome javascript.
There are only two hard things in Computer Science: cache invalidation and naming things.
CSS and HTML have to be given architectures, where we have to name these "files". What can you do with jQuery if your CSS and HTML are named and mixed up with no clear architecture? Or with an architecture that fails to harmoniously follow the JS architecture? It must be clear that one direction the future could take is that CSS classes are given interfaces to be used in JS.
CSS (as JSSS) originally did have control structures, and they're coming back as SASS/LESS. CSS is being "modernized" as it were, and so questions about the language are very important to ensure developers are maturing in light of current trends. We're now talking about CSS variables in Standards.
HTML and CSS fall dead center between "the two hardest things in computer science": How do we name these files for inclusion via AJAX? How do we develop CSS abstractions and class-based architectures? What about LESS/SASS (since no one should really be writing raw CSS anyway)?
I say this a front-end developer who has to write HTML, CSS and JavaScript on a daily basis. Yes, strictly speaking, HTML and CSS may be considered programming languages, but they lack control structures, design patterns and other interesting tenants of computer science. Like the author, I'm much more drawn toward the CS-related tasks of the job such as writing JavaScript.
To be clear, I have an enormous amount of respect for people who enjoy the design aspects. Writing CSS, using Photoshop, etc., requires a lot of skill. My point is simply that there is a divide among those front-end developers who are drawn toward programming and those who are drawn toward layout and design.
As more sites gravitate toward complex JavaScript-driven web apps, it may be useful to ditch the general term "front-end," differentiating C.S.-oriented front-end developers from those who prefer visual design.
This might make the expectations of a front-end development position much clearer, allowing for a simpler interview process.