The first time front-end became real to me was in my freshman year. My roommate had joined a respected campus tech team and worked in its design group, doing visual design and simple page development. One night after the dorm lights went out, he came back from the team office, opened his laptop, and kept coding. I leaned over to look. He could turn an image into a webpage. That felt almost like magic. I did not have a clear idea of front-end yet, and he was rarely in the dorm because he spent so much time with the team, so the memory stayed with me as a vague sense of wonder until my sophomore year.
One afternoon after lunch I was walking near the campus crossroads and saw several tents set up. A crowd was gathered around something, and people looked excited. I went closer. They were playing Xbox. Something about the scene made the group seem friendly and interesting, so I wrote an application and joined the Network Application Development Center, known as NADC. I was a sophomore that year.
My first task for new members was where I really met front-end. I was very new. I did not even know what HTML and CSS were, and I was not sure whether I liked front-end. The team gave us an exercise: choose one of four PSD files and turn it into an HTML page. When I got the task, I was lost. I had no idea what steps to take. I remember spending that week mostly in the team office. A senior student told me to start with the HTML and CSS material on W3Schools. I read it for two days, sitting at the computer and lying in bed with my phone, going through page after page. It felt strange and fun. Around the third day I started writing code. I coded for about four days with very little rest and ran into plenty of odd problems. A week later I finished the first page of my life.
Understanding what front-end means
People often ask what I do. When I say front-end, many look confused. If they ask me what front-end actually is, I still find it hard to give a neat answer. There is too much to learn. In the first training session for new members, I put together a slide of the topics I thought front-end covered.
But front-end is far more than that slide. One thing I want to emphasize is the importance of reading books.
I read a lot. The books that Nie Weidong recommended in his writing about his own front-end path were books I read several times in my junior year. JavaScript: The Definitive Guide was especially important. I read the fourth edition four times, the fifth edition twice, and the sixth edition once; I was still reading it at the time. My reason for reading was not to memorize every API. I wanted to understand the whole front-end field and the technologies around it. That mattered.
There were two libraries at my school. I lived on the east side, so I often went to the east campus library. Each trip I would come back with seven or eight books. Over two years I went through more than a hundred front-end-related books on the fourth floor. I cannot claim I mastered everything I saw, but I did learn the history of front-end development and the basic skills of writing front-end code.
A book, however weak, is still a distillation of someone's thought. The author has to consult sources and organize material. There is almost always something worth taking from it. So start reading widely. I kept a partial book list on Douban; it was only part of what I read, and I later forgot many titles and never updated it.
Reading is not the only way to learn front-end. The web is full of information, but it is messy and hard to navigate. If you search without a target, you may not get good results. Books can help you find your interests, and then you can go online to learn more efficiently.
Community and problem solving
When I learned CSS, what I remember most is writing nonstop. I wrote countless demos and lost track of how many site pages I built: pages for the school, for classes, for small companies, clones of existing sites, and exercises for the team. I wrote until I felt sick of it. I would start after getting up and still be writing after lights-out, and many times I stayed up until seven or eight the next morning. Some people might say that was too much, but I believed growth came with pain.
Many of those tasks were assigned by the team lead. I was competitive and liked showing what I could do. Whether he gave me one page or a whole site, I would finish it within three days, hand it over, ask for comments and learning advice, refactor the code, and show him again until he was satisfied. During that period I barely distinguished day from night. Twenty-four hours felt too short. Looking back, I gained a great deal. Now when I see a page, I can glance at it and roughly understand its structure, know which tags and attributes it needs, and estimate how long the page should take. That was my CSS period.
JavaScript was different. It was not mainly about endless repetition. JS is too large and covers too much ground. For a beginner, a single bug can take days to debug. After reading many JS books, I had a fairly broad understanding of the basics, but there were not many situations where I could practice everything. JS touches too many areas.
At some point I started to enjoy helping people solve problems. I went to Baidu Tieba, Baidu Zhidao, forums, communities, and QQ groups. Every day I looked for questions in several places at once. Helping people is pleasant and useful. You see something you know, say it out loud, and explain it to others. Someone more skilled may point out mistakes in your answer. That is interactive learning.
More often, you cannot think of a solution to someone else's question. That is also a good learning opportunity. My usual approach was to search for related material and read other people's blog posts. The problem you have in mind has probably been thought about by someone else, and someone has probably written an answer. That is one benefit of knowledge sharing. If I hit an unfamiliar term or technology while reading, I searched again. I tried to understand the surrounding issues around a single question. Only then did I feel I had studied it properly.
While answering questions, I also made friends. Some were already very strong technically, such as Zhang Xinxu, Xue Duanyang, and Yubo. You can meet people like that, ask them questions, and exchange ideas.
Getting to the bottom of a topic
I mentioned how to solve a problem; getting to the bottom of a topic deserves separate attention. Some sites carry more authority, such as WHATWG, MDN, and W3C. If you are familiar with those sites and your English is good enough, go straight to them for answers. You can usually find what you need, though it may not be easy to locate.
You need to know which keywords a topic contains. Only then will search results be reliable. Many people really do not know how to search. There was a course at my university called Document Information Retrieval. Anyone interested could take it. I also had slides from that course.
Blogging
I wrote a blog for two years. In the beginning I mostly excerpted, bookmarked, and reposted things I found useful, treating the blog as notes. I started on Qzone, then realized it was not really a place for blogging. I moved to Diandian, then to a developer-oriented blogging platform, then to GitHub Pages. I might change again later. Why did I move so much? A common description of technical blogging describes three phases. In the first phase, blogging is new, so you pick a free space and start writing. In the second, free spaces feel too limited, so you buy a domain and space and build an independent blog. In the third, managing an independent blog feels like too much trouble; you want to keep control while letting someone else handle the infrastructure, and you focus on writing.
People who like sharing will find a way to share what they think is good. Blogging is one direct way. I have written on Qzone, Diandian, a developer blogging platform, and now GitHub Pages. Many people do the same. A lot of experienced developers have written about why and how to keep a technical blog, and those discussions are worth reading.
Aiming at companies
For students, learning technology is often just an interest. I used to tell new team members that they should turn their technology into a specialty. If it stays only at the level of interest, you may never reach the most interesting parts of the thing you care about. For people who want to work in this field, the goal is not only to turn interest into a specialty but to turn it into a professional specialty. You need a full picture of the industry.
Many seniors from my team joined good internet companies, so early on I set a goal: I wanted to go to those companies too. It was a bit like my mindset in my senior year of high school, when I told myself I had to get into a good university. After I had a certain level of understanding of front-end, I started looking at company hiring requirements online. One I copied from Baidu for a campus front-end engineer role looked roughly like this:
- Build front-end interfaces for Baidu products.
- Improve usability and optimize interface technology.
- Research new web technologies and investigate new directions.
The requirements were: - Strong JavaScript and Ajax skills. - Strong HTML/XHTML and CSS skills, with familiarity with page architecture and layout. - Familiarity with W3C standards and a deep understanding of separating presentation from data and semantic web markup. - Strong interest in internet products and web technology, good learning ability, and drive. - Good communication and teamwork skills, plus strong problem analysis and solving ability.
Preferred qualifications included: - Experience with mobile web or WAP, HTML5/CSS3, Node.js, or Flash. - Proficiency in a template language such as Smarty, Velocity, or Django. - Familiarity with Linux and a backend language such as PHP, Java, C, C++, or Python. - Front-end performance optimization experience. - Software engineering awareness and a solid understanding of data structures and algorithms.
If you look at those requirements with your eyes open and compare them with yourself, you quickly see what you lack and what you have not done enough. I learned by checking myself against points like these, which made it easier to be recognized by those companies. Later I also looked at a Facebook front-end engineer listing. It asked for passion for building user interfaces, experience building UI for infrastructure and data visualization, primarily PHP, JavaScript, and CSS, more than three years of PHP and JavaScript experience, experience with web technologies, more than two years building interactive web applications, a strong sense of elegant and intuitive UI, and a BS or MS in computer science or a related field.
These lists are not only directions for learning; they are also material. Compare yourself with them and you can see how far you are from the threshold of the companies you want to join.
Details and attitude
For a while I was restless. I felt I already knew a lot. After reading many books, I found that much of the content was similar and not very exciting, so I could not keep reading. I skimmed and threw books aside. I understand that state very well because I often fall into it.
Some things need to be tasted and thought about. In the past, learning was almost force-feeding knowledge into my head. After a while I would forget it, read it again, and after several repetitions it would stick. That method is painful and inefficient. Now I ask why something was designed that way, whether the design is weak, and whether there is a better solution. Try to question authority. These ideas were proposed by people. No one can guarantee that a person's logic is complete and comprehensive. We are people too, and it is entirely reasonable to question them. Do not feel uncomfortable about it.
Front-end news
I should mention the importance of following the internet industry. I read many books, but my understanding of front-end is still far from enough. A good book with substantial content takes at least one or two years to write. People in technology do not devote themselves entirely to books; they also have jobs. So even in a newly published book, the technology is not especially new. It may be two or three years behind.
When I read blogs by developers abroad, I often look at the date and sigh. Things I have never seen were already familiar to someone three years earlier. That is the gap between us and the people pushing technology forward. If you want to understand where the industry is going, follow front-end news.
Front-end architecture
Many companies are working on their own integrated front-end solutions, such as Baidu's FIS and Alibaba's SeaJS. Many strong developers are also building their own libraries and frameworks, such as Situ Zhengmei's Avalon, Lao Zhao's Wind.js, and cujojs's When.js. Reading their blogs can produce the same feeling: they started these projects two or three years ago, and the code is excellent.
I mention these things to show that front-end is deep. If you ever feel there is nothing left to do, these projects will stir something in you. They are the kind of thing you naturally seek out after you reach a certain level.
By the time I finished writing this, my hands hurt from typing. The list of things I still want to understand is longer than it was when I began.