本文僅用於學習和交流目的,不得用於商業目的。非商業轉載請註明做譯者、出處,並保留本文的原始連接:http://www.ituring.com.cn/art...前端
Nicolas Bevacqua,阿根廷人,是一位富有激情的JavaScript工程師,熱衷於打造健壯的構建流程和清晰的應用架構。喜歡談論關於JavaScript、性能、可維護代碼和開放互聯網的全部內容,曾屢次在技術大會上發表web性能、ES6方面的知識分享。web
2017年6月24日,Nicolas做爲重量級嘉賓參加了「騰訊web前端大會」,分享《JavaScript的將來編寫方式》並參加圖書籤售活動。編程
大概10歲的時候,我上過一些學習Flash的課,也作些網站但純屬是爲了樂趣。到了高中的時候,我開始作一些更有趣的項目,好比玩一款多人在線的角色扮演遊戲——網絡創世紀。運行本身開發的服務器,實現遊戲的特徵。這段時間裏,我學會了C#。大概作了兩年的時候,一個朋友告訴我「嘿,人們是願意花錢讓你作這些事情的。」這對於我來講太酷啦!是的,我想,這就是我如何開始編程的。安全
不,偏偏相反。我歷來沒有以爲它是某種工做。我也不會由於把愛好變成了工做,就再也不享受這份愛好。作本身喜歡的工做,這一點很重要。只有這樣,你工做的時候纔不會感到痛苦。服務器
五年前的技術社羣要小得多。不過,如今咱們有了Node.js大會、有了JS大會等,確實在慢慢變大。我所聯合創辦的Node.js大會是去年開始的。今年,咱們依然會組織。咱們但願把它變成一個按期舉辦的大會,人們才能夠更多地參與到技術社區,而不只僅是每一年來那麼一次,而後就徹底忘了。微信
咱們談話的這個時候,可能就有一個框架出現。重要的是,咱們的主要任務不是跟隨那些耀眼的事物,而是更多地瞭解趨勢,什麼是對我有用的、有幫助的。網絡
若是兩年前開始的一個項目還在使用Angular,我就不須要認爲Angular比React落後,Angular確定會糟糕一些。是否使用某個框架取決於你的要求,老是去追求最新的技術是件很危險的事情。在一段時間內堅持使用同一種工具,講究工具的一致性是頗有價值的。架構
此外,不被新技術落下也是很重要的。你能夠,可是不建議你還在使用jQuery和HTML作網站。app
關鍵是找到合適的平衡點。不斷豐富本身的知識,若是有時間就去嘗試一下。千萬不要由於是新技術就盲目嘗試。框架
首先,要弄清楚你適合哪一種學習方式。有些人喜歡看知識截屏或者視頻演講。對於我來講,我在視覺學習方面的能力不好勁。我須要本身研讀。若是讓我看一段視頻,我會想要了解任何一種細節性的知識,反反覆覆看四遍。換作一本書或是一篇文章,我就能夠很快掌握。我想說的是,你應該弄清楚本身是一個視覺型學習者,仍是喜歡文本型內容的學習者。
而後,你就能夠開始真正地學習JavaScript的基礎知識:句法、語法,等等。有了堅實的基礎,你就應該進入ES6的學習,掌握些特徵。與此同時,你可能專一於某個單一的框架,Angular或者React或者其餘任何一個框架,但必定要作到精通。你能夠閱讀全部的文檔並瀏覽文件直到徹底瞭解它的工做原理。
我用本身編寫的框架來學習事物是如何工做的。這是一個至關有效的方法,能夠驗證些東西、編寫些技術工具。若是非要推薦一種學習資源,它應該是https://12factor.net。這是一個網站,它列出了從安全性、可擴展性等方面出發的12種不一樣的應用程序設計原則。我認爲,人們應該瞭解它。
早期的時候,JavaScript基本上就是複製粘貼「如何作」。人們在網上找到一些代碼片斷,複製粘貼到他們的網站,而後結束一天的工做。隨着語言的發展,這種狀況將再也不適用。
人們變得更加專業,開始開發一些JavaScript應用程序。如今的JavaScript應用程序中有不少的模塊。起初,這些模塊都是至關大的。如今,編寫小模塊變得簡單得多。
在個人系列叢書中,我試着教你們如何編寫出簡潔的、單目的模塊。緣由是,人們但願編寫出專業的模塊,這樣就能夠重複使用、測試,甚至在須要的時候給它提供官方文檔。最重要的是保證架構方面的可擴展性。當你有5個不一樣的模塊,每一個模塊有5000行代碼的時候,事情會很難處理。若是你有5000個模塊,每個都是100行的代碼長度,那麼這就簡單多了。
本系列主要討論如何得到這些高度模塊化的應用程序。這一系列內的後續圖書會討論測試及部署等內容。
How did you get started in programming?
When I was around 10, I had some classes using Flash. Also, I made websites for fun. In high school, I did a couple of more interesting projects, like playing the game called Ultima Online. I used to run my own server and implement features for the game. That's how I learned C#.
After doing that for 2 years, a friend told me, 「Hey, people actually pay you to do this.」 It's too cool to get paid. Yeah, that's I guess how I begin.
Have you ever thought that turning love of role-playing games into a career will spoil your fun?
No, it's the other way around. I never felt it like work to me. I would also never fall out of love with hobbies because I'm doing it for work. But it's important to work on something you like. Then it won't feel like torture when you’re doing it for days.
What does the tech community of your living place look like?
It's much smaller 5 years ago. Nowadays, we have Node.js Conf, JS Conf and so on. It's definitely growing. Node.js Conf started last year. This year, we will still run it. We plan to make it a regular thing so that people could engage more with the community, not just coming to this event once a year and then completely forget it.
There are lots of frameworks in JavaScript. How to keep up with the state?
There's probably a framework coming out right now as we speak. The important thing is to know that the theme is not to follow those shiny stuffs. It’s more about figuring out the trends, what's useful and helpful for me.
If I started one project 2 years ago, it's still using Angular. I don’t really need to feel that Angular is a little bit lower than React and it must be worse. It depends always on your requirements. It's very dangerous to go after the newest thing. The consistency of using the same tool for a while is valuable.
Also, it's important to not be fallen behind. You can, but it’s not advisable to be still using jQuery or HTML for websites.
It's about finding the right balance. Stay informed but try them if you have time. Be sure not to jump into everything just because it is.
Could you give us some learning steps of JavaScript in chronological order?
It's really important to figure out how you learn things best. Some people love to read screen cuts or videos. I'm really bad at learning anything that I see. I need to read it. If I watched a video, I want to understand anything until I go over it like 4 times. When I read a book or article, I could get it. What I'm trying to say is that you should figure out whether you are a visual learner or if you prefer written contents.
Then you could start to really understand the basics of JavaScript: syntax, grammar, etc. Once you have a solid foundation, you should move into ES6 and learn features. At the same time, you might focus on a single framework, Angular or React, but be sure to be specialized on that. You could read all its documentations and browse files to figure out how it works.
I implemented my own frameworks to learn how things work. I think it's an effective way to experiment and build things for yourself. If there were one source I would recommend, it should be https://12factor.net , which is a website that lays out 12 different principles for robust application design in terms of anything from security, scalability, etc. I think people should know it.
Currently, you are writing the Modular JavaScript book series. Why do you focus on modularity?
In the early days, JavaScript was basically on copy paste of "HOW". People find snippets of code on the internet that would give them comments for websites. They go to copy paste them into their site and call it a day. As the language developed, the case will not match any more.
People become to be more professional and started developing JavaScript applications. Now, JavaScript applications have lots of modules. At first, those were pretty big modules. It's now much simpler to write small modules.
In my book series, I'm trying to teach people how to write concise and single-purpose modules. The reason is that people want modules to be specialized so that they can reuse them, test them, and even document them if needed. But the most important thing is scalability in terms of architecture. When you have 5 different modules, each one with 5,000 lines of code, it would be really hard to work with them. If you have 5,000 modules and each is 100 lines of code in length, it's much easier.
The series basically discuss how to obtain these highly modular applications. Then the later books in the series will talk about Test and Deployment.