[JavaScript] 全栈怎么学，学什么

本博客web目录的重点学习内容。

  1. JavaScript 教程
  2. HTML DOM 教程
  3. Node.js 教程
  4. React 教程

 

 

如何学习Javascript 

作者：宋学彦

链接：https://www.zhihu.com/question/19713563/answer/23068003


第一阶段：《JavaScript DOM编程艺术》

看这本书之前，请先确认您对Javascript有个基本的了解，应该知道if else之类的语法，如果不懂，先去看看我第二阶段推荐的Javascript高级程序设计的前三章，记住看三章就别往下看了，回到《JavaScript DOM编程艺术》这本书上来。
学习Javascript用《JavaScript DOM编程艺术》来入门最好不过了，老老实实看两遍，看完了你就会对JS有一个大概的了解，整本书都围绕着一个网页效果例子展开，你跟着老老实实敲一篇，敲完之后，你会发现这个效果不是常在网页中看到么，发现自己也能做出来网上的效果了，嘿嘿，小有成就感吧
《JavaScript DOM编程艺术》下载地址


第二阶段：《JavaScript高级程序设计》

有的书是用来成为经典的，比如犀牛书；还有些书是用来超越经典的，显然这本书就是这种。书中章章经典，由浅入深，其中第6章，关于JS面向对象的解说，没有教程出其右
如果有一场满分100分的JS考试，看了《JavaScript DOM编程艺术》能让你拿到20分，那么看完这本书，你就能拿到60分以上了，学完后，你会成就感倍增的，相信我（至少看两遍，推荐三篇，跟着书上的代码一行行的敲）
这本书强烈推荐购买，写的太TMD牛逼了，给你带来的价值超过百倍千倍
这本书最新的是第三版，貌似就是前些日子出来的，我看的是第二版，第三版相对第二版变动不大，添加了几章内容，价格目前相差10元左右

接下来，恭喜你可以下山了，这个时候可以自己做一些事情了

  • 你可以去Ferris这个教程看看他写的这些效果，看看源代码，怎么样，是不是觉得有一部分很简单了，尝试着跟着他写一写这些效果吧，点这里
  • 学技术闭门造车是行不通的，适当的加一两个QQ群交流（注重质量），常去论坛（蓝色理想，CSDN）逛逛，你会经常有些小收获的
  • 再有就是看看前辈这些牛人前辈们分享的文章，它会让你的学习事半功倍的，这里是热心人收集的国内一些牛人的博客，个人网站，点这里

第三阶段：《JavaScript语言精粹》和《高性能JavaScript》

接下来两本书《JavaScript语言精粹》和《高性能JavaScript》算是JS高级教程的补充，里面有一些内容和JS高级教程重复了，两本书可以同时看，都不厚，可以对前面所学的有一个很好的加强和巩固
《JavaScript语言精粹》下载地址
《高性能JavaScript》下载地址


第四阶段：《JavaScript DOM高级程序设计》和《JavaScript设计模式》

在吃透了前面所说的书之后，接下来两本书的顺序已经无关紧要了，《JavaScript DOM高级程序设计》（注意和《JavaScript 高级程序设计》相区别）和《JavaScript设计模式》，这两本都是重量级的书，能让你的JS技术上一个新的台阶；这两本书前者主修炼外功，后者主修 炼内功，有点想乾坤大挪移和九阳神功的关系；
《JavaScript DOM高级程序设计》 首先教你搭建一个类似JQuery的额工具函数库，然后通过讲解几个实际中经常遇到的几个应用例子，会让初学者受益匪浅
《JavaScript设计模式》主要讲Javascript的设计模式，说实话，翻译的质量很一般，有些生硬，但已经基本不影响你的学习，看代码完全可以理解出自己的意思
这两本书出来一段时间了，可能买不着了，提供下载地址
《JavaScript DOM高级程序设计》下载地址，注意有三部分需要下载
《JavaScript设计模式》下载地址

 

其他：ECMAScript 和 JavaScript 的关系

前者是后者的规格，后者是前者的一种实现（另外的 ECMAScript 方言还有 Jscript 和 ActionScript）。日常场合，这两个词是可以互换的。

2015 年 6 月，ECMAScript 6 正式通过，成为国际标准。从 2000 年算起，这时已经过去了 15 年。

Mentioned contents are from ECMAScript 6 入门 作者：阮一峰

 

 

基于NodeJS的前后端分离的思考与实践

链接：https://www.zhihu.com/question/53377697/answer/138066126

  • java负责SOA的工作，建立各种微服务体系。
  • node负责CGI的工作，从SOA获取数据之后进行拼装管理，然后提供API给前端。
node本身不建议陷入过重的数据处理中，这部分由java来做更合适，包括很多复杂的业务逻辑，在node层做本身优势不大，node更多的做一些处理脚本和对外封装，同时可以规范API层和前端的model，这个优势还是很明显的。
 
 
单页Web应用（single page web application，SPA），就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
 

怎么做前后端分离

  • 前端：负责View和Controller层
  • 后端：只负责Model层，业务处理/数据等。
 
 
 

我所认为的比较合适的做法是用Node.js来解决server端UI层的问题，这样我就可以将这一层从后端的其他部分剥离出来。

现在越来越多的公司倾向于采用面向服务(service-oriented)的架构，由后端提供给前端RESTful的接口，这么做是为了更好的做前后端的依赖分离。

 

现在我们看看Node.js带来的好处吧，当后端程序员提供了REST服务之后，

前端程序员，可以使用Node.js来处理server端的UI层啦，我们可以将通过REST调用拿到的数据随心所欲地进行处理，不管是渲染模板还是直接提供给Ajax，现在我们仅仅用JavaScript一种语言就可以轻松实现这些。

后端程序员，他们只需要保证数据的正确性，无论他们使用任何一种语言来封装REST调用，都不会对前端造成影响。

这样前后端的职责不就被更好地划分了吗？这样分工之后前端的领域就从浏览器小框框里面扩展到了server的UI层，而这一层本来对于后端来说是一件他们做起来不轻松的零碎活儿。

 

只可惜，之前Node.js这样的东东不存在

所以当时没有前端合适的技术让前端工程师们自己搞定server的UI层。于是后端的同学们用PHP的人就顺手把UI用PHP的模板实现了，同样的用Java的后端同学也自然而然地用JSP搞定这个问题。这不是前端的同学不愿意去做Server的UI，而是因为在之前，没有一种我们熟悉的技术让我们能够搞定这些事情，但是现在不一样了，我们有Node.js了。

结论

我很喜欢Node.js，我喜欢由这项技术给前端界带来的更大的发展潜力。我并不认为整个后端完全用Node.js来实现会是一个很好的方案，尽管Node.js完全可以做到这一切。

我认为目前Node.js最大的价值是能让前端完全把控整个UI层，不论是浏览器的还是Server端的，做到这一点，我们工作的效率能得到很大的提升。我们前端更擅长于决定数据以何种方式呈现能带给用户更好的体验，而后端则更加了解如何处理数据。在这种新的分工方式下，后端只需要提供合适的数据操作接口，前端自己就能构建漂亮的、有效率的、可用性高的接口，从而实现用户所喜欢的各种交互。

 
 
链接：专访雪球网技术团队：用Node.js做前端的类SOA架构 

当时的架构是基于 Spring 的一种典型 MVC 架构：【早已淘汰】

    • 展现层使用 JSP，
    • 控制层使用 Spring，
    • Model 层使用自己开发的一个基于 SQL 的映射框架，
 
增加对手机客户端的支持。
把展现层单独剥离出来用 Node.js 实现，而后端只提供标准的 API 接口，这样不管是 WEB 还是手机客户端就可以使用同样的接口进行开发。
 
MVC模式大家都已经非常熟悉了，在这里我就不赘述，这些模式也是依次进化而形成 MVC —> MVP —> MVVM。
 
 
最大区别在于，在一般使用情况下，
    • mongodb可以当作简单场景下的但是性能高数倍的MySQL，【定位在"灵活"】
    • Redis基本只会用来做缓存，【定位在"快"】
    • HBase用来做离线计算【定位于"大"，数据有多大算大？例如，128GB内存双路CPU25TB存储只够一星期的时候，估计就没有选择综合症了，HBase成了唯一或者唯二选择了。 】
 
Nosql = Not only SQL
    • mongodb：我觉得定位是取代关系型数据库，想当一个主流数据库。因为他有非结构化、方便扩充字段、写性能优于mysql。万事万物有利有弊，mongodb的内存型缓存内容，让其速度飞快，带来内存率多，掉电数据问题等，加上自身代码还有很多bug带来不如老牌关系型数据库稳定，特别是在主从等分布式环境，其设计也带来诸多问题。
    • redis：是一个小而美的数据库，主要用在key-value 的内存缓存，读写性能极佳，list，set，hash等几种简单结构使得使用也很简单。缓存与简单是其定位，分布式redis架构的出现，让redis更加广泛的使用，稳坐缓存第一把交椅。
    • hbase：定位非结构化大数据，可伸缩性好，并不是完全高可用，底层依靠hadoop提供的HDFS，使用时有一整套zookeeper，pig，hive的生态系统。Cassandra可以算一个竞争对手，但Cassandra去中心化的自适应结构又跟Hbase中心化的生态系统完全不同。


 

手机开发？也许，DOM 不是答案

《React 入门实例教程》

React 起源于 Facebook 的内部项目，因为该公司对市场上所有 JavaScript MVC 框架，都不满意，就决定自己写一套，用来架设 Instagram 的网站。做出来以后，发现这套东西很好用，就在2013年5月开源了。

这个项目本身也越滚越大，从最早的UI引擎变成了一整套前后端通吃的 Web App 解决方案。衍生的 React Native 项目，目标更是宏伟，希望用写 Web App 的方式去写 Native App。如果能够实现，整个互联网行业都会被颠覆，因为同一组人只需要写一次 UI ，就能同时运行在服务器、浏览器和手机（参见《也许，DOM 不是答案》）。

React 的安装包，可以到官网下载。不过，React Demos 已经自带 React 源码，不用另外安装，只需把这个库拷贝到你的硬盘就行了。

 

《也许，DOM 不是答案》

Web app输给Native app的地方，不是界面（UI），而是操作性能。主要是互动（interaction）和动画（animation）这两方面，会出现卡顿（jank），用户会感觉到明显的时滞，有时简直慢得难以忍受。

Web app的性能瓶颈，主要有以下原因。

（1）Web基于DOM，而DOM很慢。浏览器打开网页时，需要解析文档，在内存中生成DOM结构，如果遇到复杂的文档，这个过程是很慢的。可以想象一下，如果网页上有上万个、甚至几十万个形状（不管是图片或CSS），生成DOM需要多久？更不要提与其中某一个形状互动了。

（2）DOM拖慢JavaScript。所有的DOM操作都是同步的，会堵塞浏览器。JavaScript操作DOM时，必须等前一个操作结束，才能执行后一个操作。只要一个操作有卡顿，整个网页就会短暂失去响应。浏览器重绘网页的频率是60FPS（即16毫秒/帧），JavaScript做不到在16毫秒内完成DOM操作，因此产生了跳帧。用户体验上的不流畅、不连贯就源于此。

（3）网页是单线程的。现在的浏览器对于每个网页，只用一个线程处理。所有工作都在这一个线程上完成，包括布局、渲染、JavaScript执行、图像解码等等，怎么可能不慢？

（4）网页没有硬件加速。网页都是由CPU处理的，没用GPU进行图形加速。

上面这些原因，对于PC还不至于造成严重的性能问题，但是手机的硬件资源相对有限，用户互动又相对频繁，结果跟Native app一比，就完全落在了下风。

 

DOM 与 XML

DOM是个接口: 文档对象模型（Document Object Model，简称DOM），是W3C组织推荐的处理可扩展标志语言的标准编程接口。

XML是一种结构性的语言，即可扩展标志语言。

Javascript可以动态改变可扩展标志语言的结构。

 

革新的尝试

FlipBoard原本是一个手机App，最近开始部署Web版本，一个史无前例的解决方案：

---- 他们没有使用DOM，而是将整个网站用canvas输出！

这个方案的出发点是这样的：

如果将网页变成了一个个canvas，用户就等于在跟图片互动，这样就绕开了DOM，降低了操作时滞。而且，canvas可以被硬件加速，这样就提高了性能。具体的技术细节，可以参考原文。

canvas的转化基于React框架实现，FlipBoard 开发了一个专门的库React-canvas，已经开源。

 

革新的问题

这个方案引发了很多争议（这里和这里），主要是canvas只是一个位图，本身没有语义，如果要在它上面实现UI，等于HTML语言已有的东西都要再发明一遍，比如如何实现超链接、如何实现CSS效果等等。一些最简单的东西都变得很麻烦，因为canvas不是自适应的（responsive），文字在哪里断行，都要自己计算，而且用户也无法选中文本。另外，怎么让搜索引擎检索网页，解决起来也不是很容易。

但是不管怎样，这是一个有意义的尝试。

 

 

 

《React 技术栈系列教程》 - 阮一峰

 针对初学者，尽量通俗易懂，节省一些看文档的时间，快速上手。

 

 

 

以上便是 React Native之前的故事

 

posted @ 2018-01-18 13:11  郝壹贰叁  阅读(260)  评论(0)    收藏  举报