开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《实时教程 javascript-in-14-minutes》
今日推荐英文原文:《Learning How to Learn JavaScript》
开源日报第432期:《实时教程 javascript-in-14-minutes》
今日推荐开源项目:《实时教程 javascript-in-14-minutes》传送门:GitHub链接
推荐理由:古老但是有意思的 JS 教程。它采用了一个令人意外的模式运行——你需要在浏览器上跟着它一步步的操作,从而进入下一阶段。虽然说在浏览器上的操作比起在编辑器上有些许手感上的不同,但是把浏览器提供的可以实时输入命令的功能用起来是一个非常好的想法,和经常使用 JS 的浏览器页面相性相当不错。
今日推荐英文原文:《Learning How to Learn JavaScript》作者:Jim Rottinger
原文链接:https://medium.com/better-programming/learning-how-to-learn-javascript-1989eeae2122
推荐理由:比起上面那个来说这篇文章讲的是相对更普通的 JS 学习方法——你应该在哪些地方花更大的功夫

Learning How to Learn JavaScript

Navigating the vast ecosystem of modern JavaScript is a daunting task. There is a wide array of front-end frameworks, a handful of module bundlers, and 1000s of utility libraries — not to mention all of the Node.js modules that can run on your machine or server. How do you know where to start? On which topics should you be spending your time?

The are innumerable things I learned that I never ended up using, and other things I wish I had spent more time on. With the lessons learned over the course my 7 year career in mind, these are my recommendations on how you should learn JavaScript.

1. Get comfortable with asynchronous JavaScript.

If you look at the history of JavaScript (or web development in general), you will find that asynchronous JavaScript completely changed the game. It allowed websites to go from static pages with only client-side actions to full-blown applications in your browser. The ability to make an HTTP request and wait for the response without reloading the page, quite literally, changed the world wide web.

It is safe to say that asynchronous programming is a core tenet of web development. That is where you should invest a lot of your time early on learning JavaScript, since it encapsulates other core tenets such as callbacks, promises, async/await, and fetch.

Take some time to read the resources I am listing below, in order. They should give you a good idea of where to start with asynchronous programming.

Recommended Resources:
  • The History (and Future) of Asynchronous JavaScript from the Okta developer blog https://developer.okta.com/blog/2019/01/16/history-and-future-of-async-javascript
  • Chapter 2: Callbacks from Kyle Simpson’s Async & Performance Book https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch2.md
  • Chapter 3: Promises from Kyle Simpson’s Async & Performance Book https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md
  • Using Fetch from the Mozilla Development Network (MDN) https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
  • Async/Await Tutorial from scotch.io https://scotch.io/tutorials/asynchronous-javascript-using-async-await

2. Learn the basics of TypeScript.

I debated with myself for probably an hour on whether or not to include this, since this is a post about learning JavaScript and TypeScript is not JavaScript; it is a super-set of it and requires a build step to use. However, I believe in TypeScript so strongly that I had to include it.

This recommendation has less to do with JavaScript than it does with best coding practices. JavaScript is a loosely typed, dynamic programming language. It is all too easy to write side-effect-vulnerable code when you are passing around variables and data objects that have no type contracts and no immutability. TypeScript alleviates these issues through adding strong typing and the ability to create readonly properties (among many other wonderful things).

With that in mind, I recommend that you learn the basics of TypeScript as soon as possible. By “the basics” I mean: how to add type annotations to your variables, class properties, function arguments, and function return values. TypeScript is incredibly powerful and there is much more to learn than simple type annotations, but this first step will prevent you from regularly shooting yourself in the foot. It still amazes me how often the TypeScript compiler catches a bug that I did not see at first.

Yes, the compiler is going to yell at you…a lot. That’s okay! It is your friend and it wants you to be a better programmer. Take the time to consider the error messages TypeScript gives you and I guarantee your code will improve significantly.

Recommended Resources
  • TypeScript in 5 minutes from the official TypeScript documentation https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html
  • Play around in the online TypeScript REPL https://repl.it/languages/typescript
  • [Paywalled] TypeScript 4 hour workshop by Mike North https://frontendmasters.com/courses/typescript-v2/

3. Understand why JavaScript frameworks exist.

JavaScript frameworks have been around since I first got into web development back in late 2012. Back then, AngularJS reigned supreme, Backbone.js had a decent market share, and Ember was the hot up-and-comer (pun intended). Interestingly, even though they are now a thing of the past (replaced mostly by React and Vue), the issues that these frontend frameworks address have not changed much. For example:
  • Data Binding a View to a Controller. This is the most important one. Keeping the UI view synced up with the state of your frontend application is the primary reason for all front-end frameworks. Whether the framework is fully MVC, MVVM, or just a view layer, they all have a way to bind some state to a view and keep them in sync.
  • Reusable Components. This is the biggest thing that AngularJS got right. Component-based composition of your frontend views, with JS compiling your templates to HTML, is at the heart of modern frameworks like React and Vue, but has been around since AngularJS. Creating dynamic, reusable components is simply not possible, without using an existing framework or creating your own, because the web component’s API is very limited and doesn’t handle the data binding.
These are just to name a couple off the top of my head. The point is that if you look behind the fancy wrenches, screwdrivers, and other tools, the nuts and bolts are the same. Tools change and technology evolves, but if you understand the core pain points of web development (the reasons why the tools exist in the first place), you will be in a much better position to understand and correctly use any present, future, or legacy framework.

Recommended Resources
  • The Deepest Reason Why Modern JavaScript Frameworks Exist https://medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445

4. Learn two similar frameworks simultaneously.

Piggybacking off my point on how the underlying issues that frameworks solve have not changed, I am now going to recommend that you learn two frontend frameworks at once. For instance, Vue and React.

When using one framework heavily, it can be easy to start feeling like the syntax and patterns of that framework are part of the underlying language (JavaScript in our case). As the saying goes, if all you have is a hammer, everything starts to look like a nail. That saying, translated to programming talk, means that if you only ever use one framework, you will inherently start thinking about your solutions in terms of that framework and it will become your crutch instead of your power.

Learning or knowing two frameworks at once can invert this thinking and give you more perspective into what the framework is actually doing for you. It is exactly like how learning a foreign language can actually make you better at your primary language. You see similarities and differences between the two and it has you thinking about what linguistic constructs led to those similarities and differences. Knowing two JavaScript frameworks can provide a similar perspective. By knowing two paths to the same solution you better understand the root problems they are addressing.

5. Demystify the build process.

It is not lost on me that I have made 4 recommendations now and only one of them has involved learning vanilla JS. Whether you like it or not, writing modern JavaScript involves a lot of tooling and frameworks, and the thing that ties them all together is the build process.

Build tooling is the area that has changed the most throughout my career as this is where the biggest gains in performance and asset sizes can be found. Web-based companies and the open-source community are constantly trying to squeeze every small improvement that they can out of the build process, which leads to an ever-changing set of tools and processes.

I have to admit, it took me a while to understand how tools like Webpack work. You set up a simple config, run a command, and suddenly you have a single file with optimized, minimized, and browser-compatible code. Build tools can seem like black magic because all of them strive to be zero-config or very-little-config. This is great for getting started with them but makes them daunting to approach when you actually have to do some custom configuration.

It is incredibly important that you understand what these tools are doing for you. Try to understand what transformations your code is going through and in what order. Try to understand how your modules are being bundled, so you can optimize them better. Try to learn every configuration option because this has the biggest impact on performance and file size.

Recommended Resources
  • Webpack from Nothing. Highly recommended! A great deep dive into the problems that webpack solves https://what-problem-does-it-solve.com/webpack/intro.html
  • Grunt and Gulp.js: Task Runner Tools to Streamline Your Front-End Development https://www.upwork.com/hiring/development/grunt-and-gulp-js-task-runner-tools-to-streamline-your-front-end-development/

下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/