A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
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.
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.
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.
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 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 ...
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
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:
2015 front end [JS] engineers must know
Start building with 50+ products and up to 12 months usage for Elastic Compute Service