Actually influencing the course of a project is pretty difficult for a front-ender. It's not that our work is seen as invaluable, but people usually expect us to just fix things. Jumble some css and javascript together so the wanted design emerges, while doing it in such a way that it can be easily incorporated into the cms. Making requests as a front-ender is difficult, often because we lack quantifiable data to illustrate the problems and risks of certain unfavourable decisions. Luckily there are other means to defend ourselves from harm.

1. the classic: seo

When the internet finally reached the big masses, getting your site noticed became increasingly difficult on an ever expanding web. Around the same time semantics came into play after years of abusing html for whatever designers asked us to make. Seemingly unrelated at first, those two concepts would find each other in a rather unlikely marriage.

Semantics made things a lot more difficult though. Writing html became a skill that actually required knowledge of the language. Then again, it benefited css, accessibility and machines alike, but sadly those three arguments were hardly convincing. Especially when implementing these new html structures lead to back-end development issues (which it always did, as all of sudden the default cms code wasn't good enough any more).

But then seo came along and thanks to Google seo became the perfect wave for us html guys to latch onto. Correct use of headings, paragraphs and tables ... they were all taken into account when determining the position of a site in the search results. This opened up a path that forced people to take notice of our html. It was a lever we used to force our own html in a project so that not just css and accessibility would benefit, but that we were finally able to deliver some properly structured html code.

2. updating the classic: responsive

Nowadays cmses churn out pretty acceptable html, at least from an seo perspective. Most of them are still pretty html5-agnostic, but the seo-argument has definitely lost some of its weight. That doesn't mean we just have to comply with the default html of popular cms systems though. Our new lever: responsive web design.

While many cmses got a good grasp of the most important semantic rules by now, most of them still lack structural sanity. That's a real problem when having to deal with responsive needs, because that very structural sanity allows us to easily jumble elements around. Without it, we have to revert to nasty javascript hacks and insane css constructions.

Position:absolute; and box:flex; are our life savers here. They require specific structures that are often lacking in default cms code, meaning custom html code is actually required to make everything work in a way that doesn't break a page whenever it appears in a different viewport.

3. the new kid on the block: performance

But what about css and javascript you ask? Well, since a year or two "performance" is all the rage. Providing a decent mobile experience nowadays is key for a well-functioning website, sadly (hah!) the current state of smartphones doesn't allow for too many fancy bells and whistles.

Techniques for responsive images and reworking responsive layouts alone require too much of our time already, with functional demands often reaching for the sky. This is where performance comes into play, because all those fancy solutions are often highly dependent on complex javascript and css. A dependence that doesn't really comply with most smartphone specs, resulting in hot, lagging phones and draining batteries.

Performance is our lever when we want to scale down the functional complexities. Recently a lot of tools have appeared to help us determine the exact impact of certain techniques on the overall performance of a web page, which is a great help when trying to block those exact functional demands from being implemented.

a word of warning

Just remember though: while the three arguments above are all valid, they are not holy. If you go around yelling at everyone they can't have X or Y because of performance and they need to implement Z because of responsive needs without solid arguments to back up your claims, you're not going to be working on the project for very long.

Use the above arguments in valid cases, but when such a case present itself you can try to use it as a lever, sneaking in some extra bits and pieces that will improve the overall quality of the front-end code. Trust me, everyone else is doing this already (designers, information architects, back-end developers), so don't feel too bad about it. Just don't be too obvious when you're doing it.