JavaScript has progressed a ton in the recent years. If you're learning JavaScript in 2017 and you haven't touched ES6, you're missing out on an easier way to read and write JavaScript.
Don't worry if you're not a master at JavaScript yet. You don't need to be awesome at JavaScript to take advantage of the added bonuses ES6 gives you. In this article, I want to share with you eight ES6 features I use daily as a developer to help you ease into the new syntax.
Whenever we send or retrieve information with JavaScript, we initiate a thing known as an Ajax call. Ajax is a technique to send and retrieve information behind the scenes without needing to refresh the page. It allows browsers to send and retrieve information, then do things with what it gets back, like add or change HTML on the page.
If you're learning JavaScript, the first thing you should learn (after understanding the basics like variables, functions, etc.) is to alter the DOM. This is one of the things you do daily as a frontend developer.
Changing the DOM used to be difficult. We needed jQuery to make things easier. Luckily, there's no need for jQuery anymore.
In this article, I'll show you the things you need to be familiar with as a frontend developer.
If you read my past articles on CSS architecture, you would have noticed I took parts of techniques created by experts and mixed them into a set of rules that I follow. Some of my rules helped others understand how to use a technique, while others sparked public outrage (like my unconventional BEM usage. People exclaimed that I broke BEM rules).
I'd like to confess today that I broke more rules than that. Breaking rules is my way of finding out what to take in from techniques mentioned by experts. It's also my way of figuring what to change to adapt to my personal belief. Today, I'd like to dig into this rule-breaking process.
We've already talked about writing Modular CSS with BEM and namespaces in the past two articles. In this article, I want to veer away from the process of writing CSS selectors into the mystical art of file structure and organization.
If you've ever wondered what's the best practice for organizing files, how to find any CSS file easily and how big or small each file should be, this article is written for you.
With the advent of Node.js, JavaScript found its way into the server. In this article, I share 20 things you might want to consider when creating your first Node app.
Last week, I shared how I use BEM to create a sensible CSS architecture. Although BEM is awesome, it's only part of the solution. There's another part I've yet to mention — namespaces.
In this article today, I want to share with you why BEM isn't enough and how I use namespaces to bridge the gap.
Have you worked on large websites that spans more than a few pages? If you did, you probably realized the horrors of not conforming to a robust CSS architecture. You probably would also have researched on ways to write maintainable CSS.
Since our industry is awesome, we don't only have one recommended solution. Experts have jumped in and provided us with suggestions like BEM, OOCSS, SMACSS, Atomic Design and many others.
Now, instead of suffering from "I don't know what to do", the question becomes: "there's so many ways. Which should I try?" Should I use everything, only one approach or create a custom architecture from the possible picks out there?.
I started off with only one approach. Then, as I tried different approaches, I began to include what I thought made sense into my process. In this article, I want to share with you how I structure my CSS and why I do so. Hopefully, it'll help you find your preferred method.
Oh look! Everyone is talking about Webpack now! Should I upgrade my workflow to use Webpack?!
"Hmmmmm... Maaaybe I should use PostCSS since expert X highly recommends it. I can't decide..."
"OH WOW. FACEBOOK USES REACT! REACT MUST BE HAWT! I NEED TO LEARN THAT TOO!"
Are you familiar with any of these conversations? It's not surprising if you are! New tools pop up in the frontend world incredibly quickly. Whenever something new pops up, people scream about how cool it is. Even industry experts begin using them. Heck, the expert you love and follow may even recommend you to use them!
Do you feel pressured to try the new tool out? Do you feel like a shitty developer if you don't keep up with the latest tools?
If you do, you're not alone!
Today, I want to share with you a simple framework to determine if you should learn/switch to [insert shiny tool]. Read on if it sounds any interesting.
The act of choosing two typefaces is probably the first (and often most difficult) task you do when creating a new design. Many people get stuck here, myself included.
Recently, I discovered a simple method to pair typefaces effectively and I'd love to share them with you. (Hint: it's a 3×3 grid).
It's common for designers and web developers to suffer from decision paralysis. You know you've battled with it if you had problems like:
Spending hours choosing the right typefaces
Obsessing over choosing the right framework
Scratching your head over what to learn next
Facing writer's block
Does any of them sound familiar?
Decision paralysis has been the bane of my life so far. I battled against it again recently and I'm happy to say I finally got out of the rut (today!).
In this article, I'd love to share my experiences with you and how I handle decision paralysis.
Reading is a skill I wanted to improve for ages. I wanted to read faster, because reading faster means I'll learn faster. So, I tried to learn how to speed read many times in the past.
Speed reading wasn't too difficult. The sad thing is, I can't seem to remember anything I read, which makes the speed useless.
In 2017, since my theme for the year is experimentation, I wanted to see if I could improve my reading capabilities. This time, I found some success: I read 1.5 books and remembered most of what I read in three weeks.
I'm so elated by the discovery of this technique and I'm happy to share it with you!
2016 was a strange year. It was full of up and downs. On one hand, I had eye-opening experiences that taught me a lot about myself. On the other hand, I was horrified at the amount of time I wasted accomplishing nothing, so much that I ended the year loathing myself to the core.
But that's enough. The new year is here. It's time for me to recollect my experiences and regrets and move on. This article is a summary of my learnings in 2016 and my plans for 2017.
One of the best complement for a custom web design is a custom-made responsive grid system. You can customize everything you need, including the number of columns, the size of columns and gutters and even the breakpoints you change your layouts at.
Unfortunately, many people don't even try building custom grids for their web designs because they lack the knowledge and confidence to build one.
So, in this article, I want to help you gain the knowledge and confidence you need to build a custom-made grid. Hopefully you can break away from frameworks and try a custom grid for your next project by the end of this article.
I'd be telling you the obvious if I said that grids are important in web design. You already knew that. You probably have even coded a few grids with frameworks like Foundation or Bootstrap. You may even have created a custom grid manually, or using a grid layout tool like Susy.
But have you stopped to think about these questions for the grids you've made?
How many columns should you have?
Should the columns be evenly sized?
How big should columns and gutters be?
How does the grid respond to different viewports?
What are your answers?
I have searched high and low for answers to these questions in the past few months. Here's an article consolidating everything I know about designing grids right now. Hopefully, it'll help answer the questions you have as well.
It's an age-old wisdom that's been passed around between developers since the dawn of time (at least for programming anyway).
It's also the worst advice you'll hear from anyone. But we say it on a daily basis. To others, and even to ourselves. It's just that whenever we say this, we sugar-coat the words in different forms so we don't feel as hurt.
We say things like:
Just use [insert framework here]
Use [insert plugin here] instead of creating your own. It's not a priority.
Don't waste your time building something that has been done before.
Sounds familiar yet? Has anyone said these to you before? How did you feel? Don't kid anyone. You felt something. Did you feel:
Threatened?
Defensive?
Aggressive?
Angry?
Sad?
Stupid?
Worthless?
A combination of many of these?
Others...
These statements challenge the receiver. With any questions that challenge, it not only challenges the decisions on the surface (for most of us, it's a choice whether or not to do something for a project), it challenges the core beliefs of the receiver.
Like it or not, it happens unconsciously. And because these questions are directed towards the core beliefs, the repercussions can be severe.
"How do you learn and remember all that stuff so quickly?", I get one of these questions now and then from well-meaning individuals who seek more knowledge. It's a common thing for all of us. We want to learn fast, do things fast, get more things done.
However, I never managed to answer the question properly. I always winged it because It triggers a complex mix of emotions within me. Sometimes, I get arrogant. Others, I stay humbled and state the truth: I'm slow. And I want to be faster.
The poor person on the other side of the computer only has half answer, depending on which side I sway towards.
Today, I'd like to challenge this question seriously, both for my future benefit and for countless other ambitious individuals who feel like they need to conquer a never-ending mountain of knowledge.
Did your span or gallery mixin behave unexpectedly (like the image below) when you're using Susy?
<Image src="/assets/2016/susy-span-gallery/problems.png" alt="Span and Gallery Problem"/>
You're not alone. Many people have faced the same problems I outlined above. When they meet with these problems, the common question was how to "reset" the output from the span, or the gallery mixin, so the weird behavior goes away, but that's not the best way to fix the problem.
In this article, I'm going to show you why "resetting" is the wrong approach and what you can do instead.
Have you ever asked code-related questions and never got a response? Even if you got a response, did you go through multiple back-and-forth clarification questions before you finally get a useful answer?
It happens. A lot.
It happens because you didn't ask questions that were good enough for anyone to answer you immediately. In this article, I'll help you learn the art of asking good coding questions so you'll always get great answers.
Previously, I shared the theory about adjusting your Modular Scale scale to size your headers for different devices. I also covered how you can do it with the Modular Scale plugin for the 4th method.
Today, I want to share more about the Modular Scale library so you can learn to integrate it into your project easily. I'm also going to share with you how to use Modular Scale with Typi.