2015 front end [JS] engineers must know

2015 front end [JS] engineers must know

This digest from: http://zhuanlan.zhihu.com/FrontendMagazine/20002850, because good east things temporarily did not understand, so temporarily retained, for later reference!

Mrsunny• 12 days ago

The last time I wrote "The front-end engineer must know" is three years ago, it is the most popular article I wrote. For three years, I will still receive news about this article on Twitter.

From 2012 until now, an article has not been sent to make me feel a little ashamed. Three years is a long time, a lot of things have changed. In 2012, I encouraged my classmates to learn about browser developer tools and modularity; Although many students would think that CSS precompilation and client-side template engines are not reliable, I still want to say them, and jshint, although there are #getoffmylawn (out of my turf) warning, But it still doesn't stop Jshint from becoming a popular idea (to be exact, jslint really (just) exists).

It's been 2015 years and I want to write a new one, but when I sit down and start writing, I think of two things. One, these things are called "must know" some people may find it unfair-if you already feel that 2012 years of that article, then this article is the same. Perhaps some students say that we should "be sufficient to meet the needs of business skills" as "the front-end must grasp the knowledge", but considering the front-end industry also has a variety of work to choose from, so you can only get a not suitable for everyone's "front-end basic knowledge." For me, what I need is not a job, I want to be invited to do a job. What I want is not just to go to work, but to do something awesome with a bunch of awesome people. I do not want to be satisfied with the existing knowledge to complete the present work, but want to acquire more knowledge to solve the problems that will face in the future.

Second, I am now completely using JavaScript as my core: CSS knowledge is only used when there is a need to focus on performance issues, and other scenarios have become less used. I know there are a lot of good front-end students are not like this, but I also realize that the attention of JS students and the focus of CSS students distance between the more and more distant. This may need to be discussed in a separate article, but I would like to say that this article will not introduce the CSS skills standard content, because I am far from being able to do that level.

Anyway, even if this list of skills doesn't work for your front end, it's okay, don't stress, the earth won't explode.

Javascript

Back in the 2009, when you knew that HTML5 was 2014 years old to use, did you feel like you could barely use it in your life? If so, then you need to be prepared to accept the slow-moving but stable ES6, which is the next generation of JavaScript (now called ES2015, well, the name at least means it will be available this year). As far as I am concerned, ES6, ES2015 is undoubtedly the Javascript content that I am most concerned about now. There will be some big changes in ES6: classes, real-private, improved and easier-to-use functions and parameter settings, modules that can be imported, and so on. Those students who master and understand the new grammar will be in the JS community. Related reading:

• Understanding Es6,nicholas Zakas is writing a book.
• Babeljs, a tool that compiles ES6 code you write into ES5 and runs in a modern browser. They also have a nice introduction to the ES6 documentation.
• ES6 Rocks, there are a lot of articles exploring ES6 's features, semantics and flaws.

You might ask, "Do I need to be a ES6 expert?" Maybe not now, but at least you need to know as much as your colleagues do? Or a little bit more than them? Of course, it would be nice to be able to try it as an entertaining technique in your next new project, and be prepared for it, because we never know what's going to happen the next moment.

Not to mention the new language features, use callbacks and promises to manage asynchronous Javascript at least the memorized of the back. Browser-side application loading, and inter-application communication strategy to form a set of their own views. And you should know what kind of framework is best for you, rather than now spend time understanding the implementation principles of various frameworks and which frameworks to choose.

Modularity and build tools

There is no doubt that modularity is the cornerstone of building WEB client applications. Back in 2012, there was a lot of debate about what kind of modular (AMD/COMMONJS) scenario to use to build browser-side applications. UMD, who has been slowly burning lately, is trying to avoid the problem by ensuring that the code is reusable. In fact, there is no good to win, after all, these two things are also a few characters between it?

I think that there is not always an answer to such an argument, which is the biggest change that I have ever seen from 2012 to the present, and of course, perhaps it is just my own opinion. Because I think it's more valuable to discuss "the challenges of using CommonJS and NPM in the development and packaging process" rather than saying, "I don't need AMD anymore."

Although I appreciate Requirejs's contribution to modularity, I'm starting to have a crush on Webpack. Webpack's build configuration is easier to understand and more accessible than Requirejs. Its hot-swappable features and built-in local static servers make publishing easier. It does not mandate the use of AMD or commonjs– two it is supported. It also implements a large stack of loaders to perform common tedious tasks. Browserify is worth knowing, but I personally think it is a lot behind Webpack. Some friends told me that Systemjs is also a competitor in this field, but I have not used it, and its documentation is rotten I don't even want to see. But I think it's good. JSPM (Package Manager) is more interesting, JSPM allows you to load the various components you need from various package Management Servers (components must be compliant with ES6, AMD, CommonJS and Globals specifications), including NPM, GitHub, etc., but I The combination of these two things is still a little too understanding. Ah, and even though I've said so much about modularity, I've never wanted to give up AMD, so let's go and watch.

I think that if we want to stop arguing about modularity and build tools, form a unified modular system, and in this system, any project code can be shared, and there is no need to UMD such an additional patch tool, we still have a long way to go. Ideally, the arrival of ES6 modules will solve these problems, but before this day comes, converters like UMD will fill these gaps, but it seems like we're making things more complicated, as if we're always getting things complicated.

At the same time, front-end developers also need to build tools, a variety of modular systems have their own insights and knowledge reserves. Whether it's good or bad, depending on the current progress of Javascript, your modular strategy will have a big impact on your project.

Test

Client-side code testing is becoming more prevalent, and a number of new test frameworks have recently been created: Karma,intern. I found that the asynchronous test method based on promise Intern is quite elegant. But probably because of the habit, I use Mocha to write test cases in most cases.

The main obstacle to testing is actually the way the front-end developers write their code. In 2012, I published a lecture on "Writing testable JavaScript," and then a few months later published a related article.

The second major obstacle to testing is the tool. Webdriver is a hard and huge job. UI automation tests that are currently being integrated on each browser are largely impossible, let alone mobile. We are still stuck on a small subset of browsers and devices to do lightweight automated functional testing, as much as we can to study how fast, low-cost stages of conducting such testing.

If you are interested in how to improve the testability of your code, then the only book that is most worth reading is working effectively with Legacy code (the "Art of Modifying the Codes"). The author Michael Feathers defines the concept of "legacy code": Any untested code is a legacy code. In the field of testing, the most basic element is the above sentence, although you may not think so.

Process automation

You will first think of Grunt, which is also a matter of course. The automation of Gulp and broccoli is also designed with ingenuity in the way. I've never used broccoli, I've only played gulp, and I'm beginning to realize that grunt has limitations on automating complex tasks that depend on other services, especially when the task needs to run thousands of times a day.

Yeoman was released just 45 days after I finished writing 2012 years ago, and I admit I didn't try it in time. But recently I started to start some new projects with two features
A) These projects are all starting from scratch
b) Try to use a number of different technical solutions to try to find a way to standardize the development of third-party JS applications on Bazaarvoice (providing third-party reviews).
Yeoman is doing well in both of these areas. A simple yo react-webpack command can initialize your project for you, and then all the toys you want: Generate test cases, local static servers, Hello World starter programs, and more. If React and webpack are not what you want, maybe you'll find one in Yeoman's generators (Project builder), and of course, it's easier to customize such a build package yourself.

Since Yeoman is just a build tool that will only be used at the start of a project, and given that we are not always doing new projects, it is enough to know about it in most cases. Unless you also want to standardize the entire project development process, it might be a bit more valuable.

Broccoli has been accepted by EMBER-CLI, and I think their pairing may have a new name that will be more convenient and grunt/yeoman confrontational in the future. and the development of Grunt and Yeoman slowed down, so what happens in the future, we still have to wait and watch it change.

Code Quality

If you're like me, you start to freak out when you see code that violates code specifications, then Jscs and
ESLint is the gift that God gave you, and 2012 doesn't have it at all. They all provide a way to customize code specifications, and you can automate the validation of your code before the code is submitted. It reminds me of ...

Git

From 2012 to now, the use of GitHub has not changed much, such as the pull request page with a branch name is not (just a spoof).

You should be very clear and fluent in using feature branches (feature branches), work with rebase to merge others ' code, use interactive rebase commands and squash to merge commit records, or divide the project content as finely as possible to avoid causing code conflicts. Another Git tool available is a hook, specifically, you can perform your various test cases before the push, commit, and check the code quality. You can write your own hooks, or you can use Ghooks, because ghooks makes the hooks easy to work with, so there's no reason you don't need it.

Client templates

This could be the worst thing I've written in the 2012 article, a sense of "rotten." The client template is still valuable, and it has been built into the ES2015, which is not just a good thing. These years also have some heavy lessons, many teams put all the rendering work to the browser to do, resulting in a serious performance problem, so "render the browser-generated all HTML" is taken for granted is abandoned. The smarter way to do this is to put HTML generation on the server side, or pre-compile the template as a static resource to store it, when needed to quickly compile into HTML, need to update the template can also be updated directly on the client.

There will be some new outlooks, not only for myself, but also for everyone, and when you're thinking about performance issues, you might not need to fully limit yourself to the browser. So, it reminds me of ...

Node

I heard that you know Javascript, then I think you should also understand node, at least in the encounter node problem is able to help, if hurriedly can not help, it also at least in-depth study of it: Node file system, stream, server, completely different from the front-end of some development patterns and so on. The back end will only limit the development potential of our front end.

Even if your backend doesn't use node in your real production environment, node is a very useful tool when your work is constrained or blocked by the backend. At the very least, you should be familiar with how to initialize a Node project, how to set up a router with Express server, and how to use Request module proxy requests.

At last

Thanks to Paul, Alex, Adam, and Ralph for the Review of this article, thank them for not being stingy with my shortcomings and giving me very good advice.

That's it, good luck. Maybe we'll see you in three years.

Original link: A Baseline for front-end ' JS ' developers:2015

Foreign periodicals Recommended reading:

• Understanding ES6
• You Don ' t Know JS
• 2015 The path of the front-end component framework

2015 front end [JS] engineers must know