Do you know these front-end development guides?

Javascript

Memory back in 2009, if you read in the article a prophecy similar to "HTML5 will be finalized in 2014", does it seem that the day is still far away? If you had thought so, you would be ready for a slow update but a steady forward ES6 (now known as ES2015, the name is already ubiquitous), the next version of JavaScript. prepare and es6--Ah no, es2015--, no doubt, this is the next most important thing in the field of JavaScript. ES6 classes, real privacy, better functions and parameters, modules that can introduce (import), and many other features, will definitely change the rules of the game. The new grammar, which is capable and highly productive, will undoubtedly be fully bred from the JS community. To do this, you need to read:

• Understand ES6, a Nicholas Zakas is writing books, is now open source (The new pit has opened, welcome together pits).

• Babeljs, a tool that allows you to write ES6 code and compile it into a ES5 that can be run in a commercially available browser. They also have a great learning section (please refer to the Chinese version here).

• ES6 Rocks, there are many articles that explore ES6 features, semantics, and pits. Do you need to be a es6/es2015 expert? You may not need it now, but you should at least know enough or more about ES6 to not lag behind your peers. When you're developing the next new project, try ES6, the future is near, and you'll just have to go through the veil.

The new language features aside, you should be able to speak the JavaScript Asynchronous Pattern fluently, and use callbacks and promise to manage it. You should have sufficient insight about the policies that load apps in the browser and communicate between each app . (It's a hot job) you might want to have an application development framework that you like very much, and you should have an overview of how other frameworks work, and you need to weigh the one that you like a little.

Modules and build tools

There is no doubt that the module should be the building element of the client Web application. Back in the 2012, discussions about what types of modules to use for building browser applications were going on, but it was basically around AMD and COMMONJS. There is also a slightly vulgar UMD wrapper that tries to fuse both to make it easier for everyone to reuse the code--they think that since it's about the same length, it's better to write more code to support both.

I don't think there is a single conclusion to this debate, but I feel that this is the biggest change in the field since I wrote my article in 2012, which is probably just my personal journey. I'm not completely done with AMD, but I'm overwhelmed by its practicality, you can use COMMONJS to develop and deploy Web applications, and use NPM to introduce modules.

Requirejs has made a great contribution to the module communication, and out of love for it, I am a bit infatuated with W Ebpack now. Webpack features-such as easy-to-understand build parameters (Translator Note: Build flag, command-line parameters like-p)-are easier to understand than Requirejs. Build a fast and enjoyable development saga with its built-in development server-based heat exchange architecture. It does not force you to use AMD or COMMONJS because it supports both. There are also a lot of loaders that make it a little mean to do many of the same things. You can also get to know the browserify, but in my opinion, must be familiar with Webpack after to engage in it, I trust the wise son told me, Systemjs in this field is also a serious competitor, but I still useless it, its documentation makes me want to read. Its package Manager JSPM is fascinating, allowing you to pull the required modules from different sources, including NPM, but I'm a little concerned about the combination of these two goods. I have to repeat, I never thought I would be separated from AMD, but it seems that I have to give it up and we will see it happen.

I'm still longing for one day I can stop chattering about the topic of modules and build tools, when the world has only a single module system, so that you can share the use of code across all projects, while also eliminating the overhead of using UMD. Ideally, that day will become a reality because of the ES6 module-you can use the translator (Transpiler) to fill the vacancy before the day comes-but I find it very likely that we will continue to find ways to make it more complex.

At the same time, front-end developers need to understand at least one pair of build tools and related module systems, which requires a constant accumulation of experience in practice. Anyway, for the current development of JavaScript, you still need to choose a modular system that will support your every project.

Test

Some new test frameworks, such as Karma and Intern, have made it easy to test client-side code. I found that intern's approach to asynchronous testing based on promise was special (the author misspelled particulary), and I had to admit that most of the time I still used mocha to write tests-sometimes I was just a habit creature.

The main obstacle in the testing process was the code that the front-end developers tended to write, and in the end of 2012 I talked openly about writing testable JavaScript, and a few months later wrote an article on the topic.

The second big obstacle in testing is the tool, and the Web drive is still the big pain you need to deal with. Continuous automated testing of a complex UI on all supported platforms is still not feasible, even if the cost of the work is huge enough to make it seem impossible-not to mention the mobile side. To a large extent, we are still limited to doing some lightweight automated functional testing on a small subset of browsers, devices, and operating system-supported platforms, and it is becoming increasingly difficult to rely on bottom-level testing that can run quickly and cheaply. Sometimes when you think about the problem, you feel weak.

If you are interested in improving untested (non-testable) code issues, there is a book that is well worth reading: working effectively with Legacy code, the author Michael Feathers defines "legacy code" as any code that is not tested, On the topic of testing, the only bottom line is to accept the truth of this statement, even if other constraints prevent you from solving it.

Process automation

You probably think that Grunt is the perfect choice for task automation tools, and gulp and broccoli provide a different way to build automatically. I have not used broccoli, and I have only tasted the gulp, even if grunt has certain limitations, but I absolutely want to thank it for relying on other services to help me automate complex tasks-especially when running thousands of tasks every day.

Yeoman was released 45 days after I wrote the article in 2012. I admit that I didn't use it when it first came out, but I recently (using unfamiliar technology to start a project from a paper draft) try to figure out how to standardize the way we develop third-party JS applications on the Bazaarvoice platform, and yeoman really shines in these cases. Enter a simple yo react-webpack on the command line to create a whole new project for you, everything you want in the project-test, development server, a Hello World app, and more. If react and webpack are not your dishes, maybe a generator will meet your needs, and you can easily build your own generator.

Consider that yeoman is a tool that you usually use only when the project starts. And considering that you don't always start a new project, it's just a tool worth knowing. Of course, if you're trying to standardize practices across projects, then it might have some value.

Broccoli as the core of EMBER-CLI is entrusted with the task, I trust people say that this pair will have a big future, will change a new name, in the future will gradually replace the grunt/yeoman combination. Developing with grunt and yeoman combinations is really going to fade away from people's horizons, so let's take a look at what's interesting about the future.

Code Quality

If you're like me, tools like Jscs and Eslint are a godsend when you just see that the code violates the project's Good document style guide and starts twitching. They didn't show up in the 2012, they all provide a way to format your style guidelines, and then automatically validate your code against the rules before you create a pull request, so we have to talk about Git.

Git

I think there hasn't been much change in git workflows around the world since 2012, and, on the Github pull request page, there's still no link to the branch name, who knows why.

Obviously, you should feel comfortable working under the feature branch, rebase your work with others, rewriting (squash) submissions with an interactive rebase tool, and working in a small unit is unlikely to cause any conflicts that may arise at any time. Another essential Git tool is hooks (hooks)-you need to pre-push and pre-submit hooks in particular to run your test cases and perform quality checks on all your code. You can write these hooks yourself, but tools like ghooks can help you with these complicated processes, and you have no reason not to integrate them into your workflow.

Client templates

The definition of some "error" may be the biggest mistake I've made in previous articles. The client template is still valuable, no doubt-its value is high enough that it will be built into the ES2015-but excessive abuse still has bad consequences. Many teams have shifted all of the rendering effort to the browser, and the great performance overhead has made this "client-generated HTML" approach out of favour, a hard-won lesson . Mature projects are now generated on the server side html--even pre-generated it, storing it as a static file can respond quickly to the service-and then incrementally replenish the HTML at the client, updating it with the client template when the event is triggered. Java

I hope that both for you and myself, considering the impact of your decisions on performance, is not confined to the browser domain, which is what I'm going to talk about ...

Node

You say you know JavaScript very well, so the next time I expect you to delve deeper into node, if you know little about it, you need at least a little bit of effort to understand it. Indeed, node world has some knowledge about file systems, streams, servers, and even a paradigm that is completely different from front-end development, but as a front-end developer, if you keep these precious riches out of the way, you will greatly limit your potential.

Do you know these front-end development guides?