[First published on my personal blog]
0x00 is written first
As I was writing this blog post, I suddenly realized that another year has passed, I’m one year older, and I’m going to have to postpone some of the goals I set last year.
Every year there are small goals that are forgotten, but there are many that are achieved.
0x01 Past Year
2016 is the first year that I officially joined the job. In this year, I grew from a “pseudo-front-end engineer” who only knew Bootstrap + jQuery to a “barely qualified front-end engineer” who basically mastered the mainstream MVC/MVVM framework and was able to develop Web applications in a less primitive way.
2017 was a year of continued growth, as I expanded my skill tree further and tried to establish myself as a “decent front-end engineer.”
This year:
Angular/React/Vue I learned all three ecology classes
Last year I learned angular. js and Angular are two different things, and had a little exposure to React and Vue. In 2017, I carefully studied the three ecological buckets, and finally chose React and Vue as the main force. It’s not that Angular really sucks. On the one hand, a component with at least 3 files is unacceptable to me, who is used to Vue’s single-file components and CSS Modules, and the editor is flooded with tags every second. While this is nothing new, we did it all the time when htML-CSS-JS separation was emphasized in the early days, but times are different now. Angular, on the other hand, deals with concepts that are far less intuitive than React and Vue. It’s lazy and doesn’t want to touch hard stuff when better alternatives are available. With the developer community standing almost overwhelmingly in the React/Vue camp, Angular is in a very similar position to Windows Phone. Whether a thing can survive or not is largely affected by its surrounding ecology. Ecology does not allow you to develop naturally, so it is expected that it will be eliminated.
Of course, each of the three ecology is not a fuel-saving lamp, literally a carry out along a set of family barrels. Once you’ve learned about rendering templates/functions, you’ve also learned about routing, state management, and each ecosystem has its own test tools, scaffolding configurations, static type detection schemes, HTTP schemes, and so on. To go further, you need to understand the implementation principle and some internal functions. I put a lot of effort into it, but the rewards are worth it:
- Now I have the freedom to choose which technology stack to use to complete the project
- Learning a new skill doesn’t stop you because you don’t have the prior knowledge
- Talk to your peers about any of these frameworks/libraries
- When interviewing people, don’t be afraid to say “Which of these do you know best” without feeling guilty
- In the face of a variety of new people from the way to raise questions are also able to cope with
In the process of learning a new framework/library, I often rethink what I have learned before. For example, when I first got to know Vue, I thought V-Model was really convenient. After learning React, I couldn’t see v-Model any more. Another example is that when I first learned Redux, I felt that this program was really good. Until I met Vuex, I felt that Redux was very complicated, which probably means that there is no harm without comparison.
In fact, as far as I know, not many people can use these three frameworks/libraries. Most of them can only use one of them (mostly Vue), while some can only use two (more than one React). Maybe I have a strange focus and like to do some things of horizontal comparison. I also went to learn SASS, Stylus, in fact, are almost the same thing. A lot of people will say, will be so many why, will not be used in the work, just choose one in-depth, the other are similar. In my opinion, learning more frameworks/libraries actually gives us more perspectives on problems, and enables us to better analyze problems and seek optimal solutions. Even from a practical point of view, only if you know enough, can you choose how to do it, and not be forced to do it because you don’t know anything else.
Someone asked me you through what way to learn these things, my answer is the preferred website, according to the chapters in order to read, all three ecological’s website provides a very good documentation and tutorials, quality also is very good, better than any on the market a “definitive guide” more authoritative, and continuously updated, and free, but also has a corresponding translation (Vue is officer, Angular and React are community-provided Chinese sites. In practice, you will encounter all kinds of problems. Search for these problems in official documents. If you can’t find them, go to StackOverflow, Github Issue or Google to find them.
I was exposed to more style management schemes
In the past year, I’ve been exposed to two major CSS preprocessors, LESS and SASS. Since then, I can no longer tolerate the redundant code of handwritten CSS, which feels like a waste of life. This year I focused on exploring alternatives, such as PostCSS, which I used to think was just a post-processor, a little plug-in for adding a browser identity prefix or something. But I was wrong. PostCSS is an ecosystem, a technology that uses JS to program CSS. If you dig deeper, you can actually form a system like Gulp, Webpack, etc., using plug-ins to achieve a variety of functions.
This year, I also came into contact with the most popular style naming scheme — BEM, as well as the related OOCSS and SMACSS. Before, MY CSS class names were completely arbitrary, with no rules. After contacting these schemes and reading the source code of Bootstrap, I gained a new understanding of how to manage styles. CSS can also be modularized in this way. My predecessors were right. CSS is easy, but it’s very hard to use.
This year, I also came into contact with two of the most popular CSS-in-JS schemes — CSS Modules and Styled Components. The former retains more of the SCHEME of CSS itself, and developers can use the processor to generate CSS freely. Then import styles via styles.className; The latter, while syntactically retaining native CSS, is actually implemented entirely with JS. In practice, CSS Modules seem to work better, mainly because the class names it generates are more readable. Styled-Components, perhaps because I have not yet found the appropriate method, the generated class name is a random line of characters, and there is no way to identify what an element represents from the class name. Styled Components, however, are more controllable and can be controlled through JS programming, which is more flexible than CSS Modules. Also, CSS Modules are more generic because they are independent of the library/framework, while Styled Components, as far as I know, are only used for React.
I started with TypeScript
Today’s front ends want to abandon JavaScript and write everything in TypeScript. By learning about Angular, I also got into TypeScript. Static type of good need NOT I say more, experienced all understand, not experienced advice to experience, will find the door to the new world.
TypeScript has a few major flaws that make it hard for me to use. One is that TypeScript is a little bit more strict with typing, and some things that are normally written in TypeScript will report type mismatches, which makes sense in TypeScript design. But it’s a little awkward to use. Vue also has limited support for TypeScript. Although Vue 2.5 has enhanced TypeScript support, it has not. The whole front-end ecosystem is still adapting to TypeScript. Many modules need to add type declarations to work with TypeScript, and migrating to TypeScript is still a process.
I have accumulated a lot of experience in front-end engineering
I’ve been using standard. Js and Stylelint to check my code style for a year now, and I’ve gotten into the habit of writing code without them. A combination of Webpack and Gulp became standard; The former is used for packaging builds, with webpack-dev-server as a hot replacement, used in development to fly, never go back; The latter is used for one-click deployment, where a single command directly completes the entire process from build to deployment. Earlier this month, a new packaging tool called Parcel popped up in the community. It has zero configuration and is fast enough that for small projects, you can use Parcel without having to configure Webpack. Of course, Parcel has only been available for less than a month, so there’s still a lot of work to be done, and a lot of support needs to be improved. Prepack is a webpack-like tree-shaking tool that removes unused code before packaging, or simplifies the result to reduce the size of the packaged code.
I learned the basics of front-end automation testing
Karma, Mocha, Jasmine, Jest, Enzyme, Chai, NightWatch, Protractor, Phantom… You’ve done everything, and you’re ready for decent unit testing, end-to-end testing.
While the front end itself is a dynamic industry, requirements and technology change quickly, and many times we don’t have time to do full testing. But little is better than none, and late is better than none, even if the test coverage is low, then at least I can be relatively confident that the part of the code covered is correct and valid.
I took an in-depth look at some of the build systems
In fact, it was an accident. I just wanted to have an in-depth understanding of the configuration of Gulp and Webpack. The configuration of the latter seems simple, but it is still quite complicated in depth. Gulp is better, but it’s a whole bunch of concepts underneath. As a result, due to some reasons, faced with some existing plug-ins could not solve the situation, or the solution effect is very different from our expectations, we were forced to study Gulp plug-ins and Node scripts, and write some plug-ins and scripts to perform the tasks we need. Since then, new skills have been unlocked, and scripts that once felt unattainable are not so deep and unfathomable when dissected, they can still be held.
But this road is toxic, and once you start, you want to do something else. It’s like looking for nails with a hammer in your hand.
I started to move into management positions
Maybe I was lucky, the past experience as a student leader came in handy. Now there are a few people under my management. Although there are not many people in the small Team, it is still a Team. I am promoted to Team leader, and I get rid of the front-line business development and start to move towards technical management. According to my personality, I will not lead products in general, but will be more technical management, lead technical team, to the direction of the architect development.
Now it takes time to think about the norms of teamwork, how to train new people, how to allocate work to bring out the best in everyone under me, and how to continuously improve my skills. Things are not less than before, but more. Once the development is complete, just hand it over to the test, and the brain can be completely empty until the Bug is detected. Not now. After finishing a thing, we repeatedly consider whether it is good enough, whether there will be any problems, and how the audience will feel and how to make it better. My mind was full of points to consider, and I was afraid that I might fail to live up to the expectations of my team because I was not professional enough.
0 x02 next year
In the whole year of 2017, I basically carried out in-depth research on the issue of “engineering”, from which I accumulated a lot of practical experience in engineering.
In 2018, I will focus on native applications and server-side development, where JavaScript is not or rarely encountered in traditional application scenarios, but where the evolution of JavaScript and its surrounding ecosystem makes these things possible. The latter is not a rookie in server development, mainly want to do SSR, as well as practice GraphQL and MongoDB, so node.js server development this part can not go around.
Next year, I plan to focus on the following:
React Native / Weex / NativeScript
The best ways to develop native mobile apps in JavaScript are backed by React, Vue and Angular. But the iOS restrictions are still a big hole, so let’s start with Android and hope Apple gives in.
It is to be expected that learning these technologies will be accompanied by an understanding of iOS/Android native development, which should include getting started with Swift/Kotlin.
Electron / React Desktop
At present, the best solution for developing desktop applications in JavaScript. The practical results of several star projects show that Electron is a very mature solution and can be used safely in production environments. However, the complexity of signing, configuration, and so on should also be annoying by then.
React Desktop is a library of Windows/Mac native style components developed based on React, which can be used directly by projects that want to simulate the native experience.
PWA
The community seems to be more optimistic about PWA than wechat’s miniprogram, and now it’s waiting for Edge and Safari to catch up. I’m going to spend some time on it, too, and it feels like it’s worth it. At present, the most basic transformation that has been practiced is probably the use of manifest. The real power has not been released, and Service workers must learn it.
KOA
In the past, Express was the most brilliant, but now it should be given to KOA.
GraphQL
This is not strictly limited to the front end, but since it has a lot to do with JavaScript, let’s put it in the front end category. I plan to promote alternatives to REST in the next wave if I can.
0x03 Except front end
Of course the front end will continue to be my area of expertise, and that’s not going to change any time soon, but the world is moving on, and we can’t just cling to JavaScript and think we’re invincible. We need to keep up with The Times and reach out to other technologies.
Python
High school students are starting to take Python as a mandatory course, so if you don’t want to be eliminated too soon, you need to learn Python. Facing the coming era of artificial intelligence, even if not directly engaged in the development of artificial intelligence, also need to understand some basic content, so as not to be played by the machine in the era of artificial intelligence. Of course, the major AI libraries (such as TensorFlow) provide javasjavascript apis, so developing AI applications using JavaScript is on the agenda.
Block chain
In addition to artificial intelligence, the application of blockchain is also a big focus of attention. The amazing thing is that JavaScript can be used in all the hot fields, and Node.js has become the best alternative to Python in blockchain development.
management
As I said before, I am now in a management position, and I am doing my job in this position. Although I am not interested in politics, management and politics are two different things. Tube and tube code is often the same, can manage the code, tube people should not be too bad.
0 x04 summary
In general, this year’s learning process is still in accordance with the plan set last year, focusing on the “engineering” aspect, for some big front-end field of new technology, involving relatively little. In the next year, I will focus on the skills in this area and further open branches and leaves.
Now the development of the big front end has also formed a huge skill tree with roots and branches. Before learning new technologies, some pre-knowledge will be needed to pave the way. React and Vue, for example, take the throne of jQuery and become the new foundation of front-end knowledge. You may not even know how to use jQuery, but React and Vue have to be at least the same. For example, if you want to learn Styled-Compoents, you must first be able to React, and learning React will inevitably involve contact with ES6+ syntax. If you don’t learn Vue, you probably won’t know what Axios is; In order to use them in a production environment, it is natural to reach out to tools like Babel, Webpack, Gulp, etc. The past year is basically in this lack of what to fill what process spent, to now the basic business things have not too much pressure, even if it is not specific practice of the content, also roughly have ideas how to do, or where there is a similar source can be used for reference.
At present, the development mode of the whole Internet circle has been basically stable to the mode of “cloud + end”, with the big front end being the end (including Web and wireless). Each additional access terminal may give birth to a new position. Considering the future, Breadth of coverage (i.e. exposure to VR, IOT, AI-related content) is essential. At the same time, some of the infrastructure aspects (ECMAScript standard, Node.js, GraphQL, Python, etc.) still need to be pushed further.
The combination of breadth and depth forms a “T” shaped skill stack, which will probably be one of my future goals. Now we have a horizontal, a vertical also have some, the next thing to do, is to make that horizontal wider, let that vertical deeper, at the same time make the “T” as fat as possible, forming an inverted triangle.
0x05 Keep trying
It is said that the first three years of work are the stage of skill accumulation. According to this, I have completed two years of work, and in one year, I will enter the stage of 3-5 years of experience. When the market demands will be higher, I must make preparations in advance.
The process of learning is painful, more painful than this, is continuous learning, and in this line of work, you have to lifelong learning, when to stop learning, when you will begin to be on the verge of obsolescent. Fortunately, I love the front end and am interested in driving it, so all this is not difficult. I am afraid that I have to do it even if I don’t like it, which is very embarrassing.
Finally, happy New Year! We will continue to make progress together in the coming year!