Findings and experiences during frontend development

 

Introduction

I’m the kind of guy who cares about specific principles. What I mean by that is: I want things to be done in a certain way. Sometimes because their methodically correct, other times because I know for a fact that a given approach is rock-solid and clears me of any impending cross-browser problems or other bugs.

I’m also the guy who likes to reinvent the wheel on several occasions. Not because I think I’m smarter than the rest of the world but because I like to be in control of what I do to some degree.
There might be countless jQuery plugins out there that do form validation. Yet I wrote my own, for the simple reason that I don’t need the 500 features that most jQuery plugins provide.

That clears me from any bugs caused by features (which I might not even use) but most importantly: I know at all times what is going on inside the entire validation system.

And last but not least: I’m also the guy who holds back 3rd party library updates when I feel nothing in the current version is broken. Why would I replace software that works in its current state and within its current implementation? That only opens the portal for potential bugs / collateral damage to make its way into my code.

The above should give you some sense as to how I operate when working on a project and why I think about some things the way I do.

Learn from errors

Something that I find really worrisome is when people run into an error/bug and all they care about is the fix. They go on this massive Google spree, trying to find other people who had the same issue. I have seen this on several occasions: The bug shows up and people just start Googling to find a solution. It almost makes me wonder if these people are panicking in their heads. Because panic usually takes the sense out of people and makes them go towards the wrong decisions.

I’m very systematic about these things. I always try to understand why something is happening. Because let’s be honest: Whatever we do; whatever you want to call it. It really isn’t a bug. It’s just your approach being wrong at some point. The computer is (almost) never wrong. Your Javascript/CSS probably is.

That means we need to understand everything that goes wrong. Because we told it to be wrong. We wrote the code that made the app break. For me, researching the bug and understanding why our train of thoughts was wrong, is more important than the eventual fix.

So, next time something is rendering incorrectly in some browser, don’t go in a testing spree to find a fix but figure out what you did to cause the error in the first place. Figuring that out might save you tons of time/code… Sometimes the cause of the issue is right in front of you, you’re just overlooking it.

UI Kits

I have been building some pretty cool apps/dashboards/sites in the past. What I’ve learnt most from these are the need for the developer to identify the re-usable blocks. And with that, I don’t mean the same kind of reusable code that Java developers deem correct. Not the re-usable class you only use once.

I’m talking about writing code / building components that will be used throughout the entire project. I’m not talking about web-components either. I’m talking about HTML structures that can be altered on a per-use basis and allow for very flexible use.

The most difficult thing about this is about developing a solid base to build on. For that matter, a good UI design makes all the difference. Spend time on researching UI elements in the approved designs and try isolating them and break them up into pieces.

All of these examples are based one basic component (project: AppNinjas for Metropoly) All of these examples are based one basic component (project: AppNinjas for Metropoly)

Screen Shot 2015-02-15 at 13.51.43As you can see, each block has been built on the basic foundations that there’s a header, a content and a footer to a block. Not ever will there be more than these 3 on that level of the HTML structure.

This was the basic definition for all of the above blocks. Some of them have footers, most don’t. The different parts of each block have their own component like approach. The interesting thing here is that you build the basic block once. Then for each new use-case, you just an additional class. For example there’s ‘block track gmail’, ‘block track gmail mini’ and ‘block course’.

I extended the block class with additional classes that would each be able to alter/add new features. In the end that gave me great flexibility when features had to be added and perfect control when sitewide changes had to be made to all the blocks. Since all of it is only defined once across the entire site, consistency and efficiency really excelled in this project.

For me this has become a very important part of my process as this will be the base for the entire project. It will make or break your entire project and deadline. Make sure you invest enough time figuring out how something should be built.

Element ID’s vs Classes

This is not entirely related to the UI Kit approach but it ties in real close with it. I have come to a point where I hardly ever use ID’s anymore. I consider them dangerous.

  1. They may only appear once on a page
  2. They relate to 1 specific element only
  3. They limit re-usable code
  4. They have great implications on CSS overrides
  5. Because of it’s nature to target only 1 item, it limits the options to expand your features in the future
  6. You (almost) don’t need them if your code is solid

The last reason is basically a fix for the other 5 so I won’t elaborate on those. Even if you disagree with them, #6 will help you with any other problems you might have.

I tend to add a page-slug to the body classes for starters. During the development of the rest of the page I set my mind to creating re-usable expandable elements (cfr: UI Kit). To build such re-usable components, I add classes to almost every level of the HTML structure. I also try to add as many containers as I need. This enables me to have hooks and containers for almost any change request that might (and probably will) come later on.

This enables me to build structures that are independent of its different use cases like adding a list menu icon, breaking a line, adding 2 words or removing a button. Since everything has been built for ‘dynamics of change’, I can easily adapt any changes the client wants without spending a lot of extra time on the change.

Using classes instead of ID’s enables me to be flexible in these conditions. This also gives you easy control over overriding CSS rules from within different files (.scss includes) without worrying about the rule-level (class VS id VS !important) too much.

About !important

The !important statement in CSS is a very powerful tool. However, with great power comes great responsibility. I’ve seen !important being used on many occasions where normal overruling would have been perfectly possible and reliable. The use of !important in those cases is a clear sign of laziness. If you find yourself during the development of a project and consider using !important, you should always ask yourself: “Why am I doing this? Isn’t there a better way?

Don’t get me wrong: !important isn’t a bad thing. But it should be used as a tool. Not as a fix. A great use-case where !important is a great tool is responsive dropdown menu’s.

During the AppNinja’s project, I ran into this screen where there is a bar with menu icons that needs to turn into a full-page dropdown on phone-screens. To create the full-page height, I needed to calculate the height of the body of the menu using Javascript. Some basic jQuery would then apply .css(‘height’, 587px’) but once the screen would be resized to a larger screen-type, the height on the element would still apply. Instead of removing this on window.resize event, I just had a rule in place that applied height: auto !important; on the larger screens. That way, the height could always be there without breaking the layout.

Less Javascript to code, less bugs to appear.

SASS selector nesting

I’ve only been using SASS/SCSS/Compass since I joined Metropoly, so it took me a while to see the effective power of this thing. Again, this really ties in with UI Kits, as it enables you to bundle code that belongs together. That gives you a much better understanding of what you are doing. It also helps you to point out when you’re about to make a stupid decision when splitting up your code. More often than not you’ll notice inconsistencies in your code faster because of the structure that you put in place earlier.

The one thing that really became clear to me is what happened when we were working on a project for a larger client who came back regularly for changes. It became apparent that nesting CSS in SASS is a bit of a double-edged sword. It helps you to write a lot of code at the same time. But it also makes your code very inefficient for later use.

The starting code of the project was a massively deeply nested CSS spaghetti. Quickly it turned out that we were not so much using SASS/CSS anymore to write re-usable rules. We were almost copying the HTML structure in the CSS nesting. This is very bad as it takes away all the flexibility of CSS.

We realized we weren’t so much styling components/elements on the site. We were styling each page and component on that page individually. This caused a lot of time loss and even more frustration and inconsistency in general looks of the various items.

Again, we turn back to the UI Kit approach for this: The best way that I’ve found to approach designing things right now, is to consider everything a resusable, customizable component which might be used again at some point. Even if it very well might not.

The only place where I deliberately write page-specific code is for page-templates. For example: positioning of blocks on the dashboard page VS positioning of blocks on the profile page. Page-specific code dictates how components and parts of the page interact with each other.

It’s very much like being a CEO of a company and the managers telling their personnel what to do. The CEO tells its managers what needs to be done, the managers tell their team how to deal with their own project.

In this case the CEO is the page-specific layout code. The reusable UI components are the managers who take care of their own responsibilities.

Conslusion

I started writing this blogpost in August 2014, during my time at Metropoly. I have since discovered SMACSS where I learned that my approach was pretty similar. If you think there’s some sense to what I wrote here, do check out SMACSS and try to apply it in your next project. It will be a whole new experience 😉

Ronny

view all posts

Ronny is a freelance frontend developer with a wild passion for creativity and a relentless hate against flat design. Ronny spent years as a Flash developer before moving to HTML5 and rediscovering fun and happiness.

1 Comment Join the Conversation →


  1. linus h.

    Very interesting read!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *