There are many articles out there that talk about the languages, frameworks, and tools needed to get a job in great company like Fireart (https://fireart.studio/front-end-development-services/). I wanted to take a different approach. In this article, I’m going to talk about the mindset of a front-end developer and hope that I can give the most complete and detailed answer to the question: “How to become a great developer?”
Don’t just solve problems – try to understand what’s really going on with your code
Too many people who work with CSS and JavaScript tinker with something until it “something” works and then move on.
You may think that trying to figure out why your way of solving a problem worked is a waste of time, but I promise it will save you time in the future. If you fully understand the system you are working with, then when solving problems, you will not guess, but you will understand why you need to do it this way and not otherwise.
Learn to anticipate future technology changes
One of the main differences between front-end and back-end code is that back-end code is most often executed in an environment that is under your control. The front end, on the other hand, is out of your control. The user’s platform or device can change completely at any moment, so your code should be able to handle it with ease.
In this case, the code handled all versions of IE older than IE 6, but as soon as IE10 came out, significant parts of our application completely stopped working.
In the real world, feature detection is not 100% guaranteed, and sometimes you have to take into account the misbehavior of browsers and reckon with those for which feature detection erroneously returns positive (or negative) values. But if you do this, you need to guarantee a future where these bugs don’t show up again.
The code we write today will be around for a long time to come – even after we leave our current job. Some of the code I wrote over 8 years ago still works on large sites – this thought is both pride and concern.
Read Specifications
There have been, are, and will be bugs in browsers, but when two browsers handle the same code differently, people often assume, without any verification, that the so-called “good browser” is right and the “bad” one is wrong. But this isn’t always the case, and if that assumption turns out to be wrong, any changes you make will almost certainly crash in the future.
If you were to experience this kind of cross-browser incompatibility and notice that your site looks the same in Chrome, IE, Opera, and Safari, but different in FireFox, you will probably assume that FireFox is wrong. In fact, I’ve come across this many times. I was often told that my Flexbugs project had a similar incompatibility problem, but if I tried to somehow get around this and implemented several solutions, then everything would have collapsed just two weeks ago with the release of Chrome 44. Possible solutions to the problem did not so much meet the requirements of the specifications but tried to compensate for (actually) the correct operation of the browser.
When two browsers render the same code differently, you need to take the time to figure out which one is working correctly so you can tweak your code accordingly. Then you don’t have to do anything in the future.
In addition, the so-called “great” front-end developers are the people at the forefront who adapt new technologies before they become popular, and even contribute to their development. If you develop the habit of looking at the specs and imagining how the technology will work before it is available in all browsers, you will become part of a select group and be able to understand and influence the development of the spec.
