Category: Coding
Store libraries locally
I have one example in mind that really annoyed me.
One of our clients needed some features really quick and I wasn’t around at that time to help with it. They got someone from UpWork to do the job and they did it, it worked as expected.
All good until the client mentioned that the loading time is quite high now. We started to look at the code and how it was created to find out that all the libraries were embedded from 3rd party CDNs/servers. Not even the minified versions, the full ones.
We ended up with OwlCarousel twice on the site (and now loaded everywhere), we ended up with Bootstrap twice and some other JS library being delivered from 3rd parties.
Keep libraries locally
My main focus here is the CDN libraries.
This is something that I noticed a lot in WordPress development projects. Mostly when it comes to someone working on an existing project.
Clients will come in and ask for improvement, or some feature to be added on their existing website. This means you need to deal with the code that someone else created, the folder/file structure, re-use some functions/scripts, etc.
This is tedious and it takes time, you just want to have that thing done and ship it. It’s totally understandable, but you also need to make your adjustment robust.
Linking the libraries in the <head> directly from a CDN or server is not a good practice.
It’s perfect for the development environment where you want to quickly test and see if it does the job and you don’t have to worry about adding the library into the compile process or enqueue it on a specific component.
But for the real-world, when you ship that solution, you should store that library locally in the folder of your project. If the project will use a CDN and that asset will be delivered from there, then perfect.
Do not rely on a 3rd party CDN or server to deliver your library.
Reasons
- It might get an update and break your production site (in most cases they are version controlled, but it can happen)
- It can get deleted at some point
- The CDN/server link my go down
- Multiple requests on page load
- Slowing the loading time
- Offers details on what libraries you’re using. Might be easy to target some exploits.
Build things that are durable, robust, and don’t need any external help to run.
Should you go mobile first?
The full question sounds like this:
Should you build your website/web-app mobile first and scale to desktop?
Why do we need another article about this, it has been covered a lot of times already?
To make things clearer, I’m only interested in the site structure, building the CSS around it and how it changes from one device to another. Not the PWA or other things that will take the mobile first approach and make it more like a mobile app.
It might be an obvious answer for a lot of you, but to my shame, it wasn’t for me. I didn’t see a reason to go mobile first in my approach. I’ve created lots of sites with the approach of desktop first and scaling down on mobile as I went along. We even had a full workflow where we have the desktop site ready, test it and after that, we move to mobile.
This workflow might’ve been influenced by the designers I worked with or the clients that focused on the desktop version first.
It all changed after I read Responsive Design: Patterns & Principles by Ethan Marcotte. I recommend this book if you are a web developer, especially front-end.
I was amazed by how much more can be accomplished if you have a different perspective when creating the site. And it so happened that I read it during a complex project where we had a lot of parts and elements that were structured to be re-used throughout the site.
Understand the design/project
It starts by getting a better understanding of the design or the project as a whole. You need to get as many details from the client and designer. They might think the site as page by page, but this is not true anymore. The site has pages but those pages are created by elements, and those elements are the ones that need your attention.
What is relevant for the user on a small device?
- On your newspaper site, you want to show the featured story on mobile and have it display as the first thing, not obstructed by anything else.
- If you have an e-commerce site you want to show the featured product(s) that are available on sale.
- Your book author might want to have a clear way to display the next event or book signing that she’ll attend.
This means understanding your project, getting to know exactly what matters, the core of the project. On mobile, you need to be able to deliver what’s important and not just fill the screen with everything. Providing the right content will keep the user engaged with your site, and it will also help you fix performance issues.
Working with elements
As you look over you will find elements that repeat themselves on different pages.
Once you identified the elements, you can start building the components. Get those components to live in their own space and create a structure just for them.
Then get them styled not in a relationship with the page or other elements, but as a standalone unit that will be placed on a page.
Why are elements important?
First of all, it’s like working with data: you want the actual data, not for it to be wrapped into something that needs to be adjusted when you want to display it.
You want the actual value from a field. Same with elements.
You want an element that does the Featured Story for the newspaper, Product on Sale for your e-commerce, Next Event for the author, that you can re-use wherever you like.
Having elements or components that will come together on a page will help you better manage the outcome.
Mobile Content
On a mobile first approach, the content on mobile devices is specially catered for mobile. You don’t just use what it’s on desktop but on a smaller screen.
There is an important difference here because you will need to take into account the fact that people might browse on 3G connections that are not that fast. This will make every extra resource that is loaded to take some extra seconds for the end-user.
We’re getting a better understanding of how the images are delivered and if you have to just hide content or eliminate it on mobile devices.
As you’re set on creating elements/components, you have to make sure that the media files you use are correctly optimized for screen size and enable/disable certain elements on mobile altogether. Don’t load them just to hide them on mobile.
Today this is even more powerful and easy to achieve with JS frameworks like Vue.
Isn’t mobile first the same as a responsive website?
Yes and no, mostly no. It’s kind of the same thing when you talk about the methods used (you’re still using a CSS framework for example), but it has very different outcomes.
I see the responsive way of creating sites as going from big to small and with this approach comes the idea of hiding elements on certain smaller screens or just move them around to fit. Nothing wrong with this, mobile has less space to display content.
But what do you hide on mobile?
You’re now faced with a problem that you didn’t have in mind at the beginning. You’re not aware of what is vital/relevant for your user on mobile.
The mobile first approach aims to solve this issue. You’re starting the site scaling from small to big, not downgrading the content. When you start with the small screen idea in mind, you realize what is important and what must be shown on the page. It’s not just about moving the content around so it will fit.
I’m aware that responsive is the easy way to do it. When you have a site that is already in use for some while and it has traffic on it, it’s the safe step to make it responsive, move things around to fit and just remove some elements on mobile.
I would love to cover more on this subject and break each idea into an article on its own, but for now I just wanted to offer a glimpse of what I took from that amazing book.
I really recommend reading the book. it’s around 100 pages with a lot of relevant examples and solutions from the real world. It might change the way you think about your current projects.
Should you use !important in CSS?
I feel like this was a popular subject back in the day (2010-2012), but it’s not that important now. Get it?
Anyway, here are some articles that talked about this issue in the past: here, here and here.
What it’s !important?
You can call !important a directive, a keyword, declaration, and it’s placed at the end of a CSS propriety to prioritize it, to add more weight to it over other proprieties that might be in the way.
CSS (Cascading Style Sheets) passes along some of the proprieties from the parent to child and so on. Similar to a cascade, if it wasn’t obvious enough.
In some cases, you need to overpower those proprieties and for different reasons, you end up using the !important solution.
.container h2 {
font-weight: 600;
}
h2 {
font-weight: 300 !important;
}
In the example above your h2 will take the font-weight of 300, even inside the .container element, because it has the use of !important.
This should give you a good idea of how it works.
When will you use !important?
You might end up using !important for different reasons.
A few that I might think of:
- Old code where you don’t know what else will be affected and you prefer to add an !important to fix your style and move on with your day
- Dealing with inline CSS added by some 3rd party JS
- Classes that are overlapping with another plugin or theme
- You are using a framework (Bootstrap)
It’s not always justified, but most of the times it will be an easy way to fix something.
I try to go out of my way and get it fixed correctly without using !important. Try using an extra class when you identify the element, let !important be the last resort.
Bootstrap, frameworks and visual builders
When you use frameworks on your project, you might be forced on using the !important propriety more that you want.
One way to avoid this is to learn more about CSS Specificity. This will allow you to style your files better without abusing !important just to get the things done as you want.
Apart from Bootstrap, you will stumble upon different visual builders for WordPress that will do you the immense ‘favor’ of adding inline CSS with !important in it.
This will be a recurring problem and you will have to decide if you want to edit the elements from the builder proprieties (adding background image, padding, margins) and deal with all the mess that comes with inline CSS (with important) or just assign a class to an element and do the whole work from CSS files.
Dark/Night Mode and !important
I can think of one example that will make the use of !important justified: Night Mode or Dark Mode.
Let’s say you want your site to have a Night Mode option, a simple switch that will change all the content into a dark background and white text.
You can have a simple switch that will add an .dark-mode-on class to the body and after that use a code similar to this:
body {
background: #fafafa;
}
h2 {
color: #dea62f;
}
p {
color: #333;
}
.dark-mode-on {
background: #000!important;
color: #fff!important;
}
.dark-mode-on h2 {
color: #fff!important;
}
Conclusion
Yes, you should use !important, just be sure not to end-up with proprieties cancelling eachother because that will be a nightmare to debug.