[Translation] basic requirements of front-end developers and basic requirements of front-end developers

[Translation] basic requirements of front-end developers and basic requirements of front-end developers

Note: The title of the first translation technical article has been entangled for a long time and I don't know how to translate it. If I find that the translation is inappropriate, click the github link to submit a comment, thx ~

I wrote a README document for a project a few days ago. I hope other developers can see this project and learn something from it. Suddenly I realized that if I put it a few years ago, the Node, npm, Homebrew, git, testing, and product building that I mentioned casually during my writing would scare me away.

For a while, the basic workflow of a front-end engineer was: editing files, local testing (as best as we can), and uploading files to the server through FTP. We evaluate the level of a front-end engineer by checking whether the engineer is compatible with IE6 or cross-browser pixel-level consistency. Many community members, including me, lack traditional programming experience. HTML, CSS, and JavaScript-usually jQuery-are self-learning skills.

These things have changed over the past few years. It may be because you start to take the work of front-end developers seriously, or because browser developers start to make a difference (tend to be consistent? Getting their shit together), or the front-end developer himself-also, including me-began to see the dawn of software development.

In any case, we can see that the focus of front-end development has shifted from tedious to tool-oriented. To become a successful front-end developer, You need to master a new set of basic skills, and front-end developers who do not meet the requirements will feel increasingly lagging behind, those who are sharing their knowledge think these things are natural.

I hope people will be familiar with the content mentioned below. In addition, there are some related resources, if you think you need to accelerate your growth. (Thanks to Paul Irish, Mike Taylor, Angus Croll, and vglad Fillppov for their contributions)

JavaScript

This is not much to say, but it is no longer enough to know a javascript library. I am not saying that you need to know how to use native JavaScript to implement all the features of a JavaScript library, but you need to know when the library is required. At the same time, when you do not need a library, you can use simple and old JavaScript to complete your work.

This means that you have read the essence of JavaScript language-hopefully more than once. You understand data structures such as objects and arrays; functions, including how and why do you need ~ Call
And apply
They master prototype inheritance and javascript asynchronous operations.
If your native JS is weak, here are some resources that can help you:

• JavaScript programming: A book that can bring you back to the basics of JavaScript. It's quite good (with a paper version)
• Test-driven JS Evaluation: A series of failure tests cover different JavaScript topics. Can you write code that passes the test?
• 10 points I learned from jQuery source code: the gift Paul Irish gave us, although old, is indeed good, it lets us know what we can learn from reading others' code.

Git (there is also a Github account)

If you have never visited Github, you will never be able to participate in this resource-rich open-source community. It is already thriving in the front-end development technology field. Cloning a branch and then running it should become your habit, and you need to know how to use the branch in a multi-person Collaboration Project.

You need to upgrade your git
Skills?

• Help.github.com
• Github git cheat sheet
• More cheat sheet
• More git links

Modular, dependency management, product building

The days of dependency management by inserting several scripts or style labels on the page are gone forever. Even if you haven't been able to introduce RequireJS into your workflow, you should try it out in your personal project or project like Backbone Boilerplate, because it can bring us many benefits. RequireJS enables you to develop JavaScript and CSS files to be modular and fine-grained. Before the product goes online, you can compress and merge files through the related optimization tools.

AMD sounds scary? There is no excuse to quit. At least, you should know that there are tools such as UglifyJS and Closure Compiler that can intelligently compress and merge your code before your product goes online.

If you are still writing native CSS -- that is to say, there is no CSS Preprocessor like Sass or Stylus -- RereireJS can also help you maintain the modularization of your CSS files. Use @ import in a basic Style File
Declaration to load the relevant dependent files, and then run ReqireJS Optimizer on the basic file to build the files used in the actual production environment.

Built-in browser Developer Tools

In the past few years, browser-based development tools have been greatly improved. If you know how to make good use of them, they can greatly improve your development experience. (Note: If you are still using alert

Debugging code will waste a lot of time)
You may need to determine a browser. You mainly use its developer tools-recently I prefer Google Chrome Developer Tools-but do not immediately discard the developer tools of other browsers, because they often add useful features based on developers' feedback. It is particularly worth mentioning that some functions of Opera's Dragonfly make their Developer Tools stand out, such as CSS analyzer (in the experiment), which can be customized with keyboard shortcuts, you do not need to remotely debug the USB connection and can save and use a custom palette.

Command Line

When it comes to the command line, adapting to it (being comfortable with it) is no longer an option-if you are not prepared to sit in front of the terminal window and manually tap the command line, you will miss a lot of things along the way. I am not saying that you must complete everything on the terminal-I will not steal your git GUI (graphical user interface ), although I do think it would be better to leave it in the end-you 'd better keep running your command line terminal no matter what project you are working on. The following command line tasks must be completed without thinking about them:

• Log on to another machine or server by using ssh

• Scp Copies files to another machine or server

• Ack or grep find a file with a certain string or pattern in the file name

• Find locate a file whose file name matches a certain pattern

• Git can at least use it to do the following: add, commit, status
  And pull

• Brew uses Homebrew to install files

• Install Node package in npm

• Install Ruby package with gem

If you use more commands, You can edit. bashrc.

• Or. profile
• Or. zshrc
• Or others, and then create alias so that you do not need to type many characters as before. You can also add alias to your ~ /. Gitconfig
  File. The dofiles of Gianni Chiappetta is a good example.

Note: If you develop on Windows, I don't know how to help you, except Cygwin is recommended. It is troublesome to participate in the front-end open-source community activities on Windows. Of course, what I said is not necessarily correct. On the contrary, MacBook Air is cheap, powerful, incredibly portable, and always has Ubuntu or a variety of * nix.
(Web Front-end learning and communication group: 328058344 chat prohibited, not welcome !)

Front-end Template

Not long ago, for front-end XHR requests, a typical server response method was to return a piece of HTML text. However, in the past 12 to 18 months, the front-end development community has seen the dawn, requiring the server to return simple data. Converting data into HTML is troublesome. If the processing is poor, the maintainability will be quite poor. This is the purpose of the front-end Template Library: you only need to maintain a set of templates and provide data as needed to convert the templates into HTML. How can I select a template library? The template chooser of Garann Mean can give you directions.

CSS Preprocessor

Paul Irish noted a few days ago that the code written by front-end developers was significantly different from the final deployment in the production environment. The code written by the CSS Preprocessor is a good example. There are still many people who insist that native CSS is the only way out, but they are getting closer and closer to us (but they are starting to come around ). These tools provide some features that have long existed for CSS attributes, including variables, mathematical operations, logic, and mixin ), they can help you free up from a bunch of redundant feature prefixes.

Test

One of the fun of writing modular and loosely coupled code is that your code can be tested. If you use a tool like Grunt, creating a project that contains test cases is no longer easy. Although Grunt integrates QUnit, there are still many test frameworks for you to choose from-Jasmine and Mocha are my two favorite test frameworks-the Framework selection depends on your personal preferences, and the structure of your project (the mark up of the rest of your stack ).

Test is interesting if your code is modular and loosely coupled. However, for those poorly organized code, testing is not difficult, sometimes even impossible. In other words, forcing yourself to write test cases-or even before you officially code-helps you sort out your ideas and your code organization. Later, when you refactor your code, it also gives you confidence.

I recorded a short video about how to use Jasmine to test jQuery

An example of jquery-bbq plug-in unit test

Process Automation (rake/make/grunt/Others)

An example of Process Automation: Create a built-in unit test project through Grunt. The current status of front-end development is that we have a lot of repetitive work to do, but a friend once told me that a good developer is a "lazy" Developer: first, if you find that you have done the same event more than three times, it is time to automate it.
Tools like make have been around for a long time. They are mainly used to solve the above problems, but there are also tools like rake and grunt.
And other similar tools. If you want to automate tasks that require dealing with file systems, it is very helpful to learn languages other than JavaScript, because when you only want to process files, the asynchronous feature of Node makes things more troublesome. There are also many automated tools for specific tasks-deployment, construction, code quality assurance, and others.

Code Quality

If you have been troubled by the absence of semicolons or the addition of a comma, you will know how much time you can waste with such a small code defect. That's why you are running your code in a tool like JSHint, right? It is configurable and can be integrated into your editor or build process in many ways.

Good Reference Manual

Alas, there are no manuals for front-end development, but MDN is at your fingertips. A good front-end developer adds the mdn prefix to any search query, such as mdn javascript arrays.
To avoid searching for content of profitable organizations like w3schools.

End

Reading these things won't make you an expert, even if you are more experienced. The only way to do better in a thing is to do that thing. Good luck.