react-ssr同构

前言

来 最右 这边俩个多月了,技术氛围和工作同事都很好。这俩个月周末,基本上每周都有“约”,,,导致自己没时间总结技术。从此之后,还是要拒绝一些无意义的“聚会去”。其中有俩个周末,去参加 了俩个论坛,水的一批。
总结如下:

  • 1、不参加无意义的聚会
  • 2、不参加所谓的技术论坛

    react同构

    同构是最近一俩年才“火”的。一套代码可以在服务端运行,又可以在客户端运行,就是同构。

    为什么要同构

  • 通过后端直出html,降低首屏时间
  • SEO:搜索引擎想到。spa的话,因为只有一个页面,所有不利于SEO。
  • 兼容性:比如在hybrid中,经常会出现“白屏”

    一些概念问题

  • ssr: server side render(服务端渲染)
  • csr: client side render(客户端渲染)
  • spa: single-page application(单页面应用)

    其他

    React同构总结

    一些方案

  • 基于egg的北斗,封装的太厉害。暂时把控不了。Beidoujs
  • Next.js同样有些封装,容易上手,但还是很慌。
    next.js
  • 所以还是基于底层原理,自己做一套脚手架吧。
    React同构总结

扩展

1、
预编译技术:可以用另外一种技术方案,称其为预编译。ssr本质上就是把客户端处理的任务交给了服务端,从而加快速度。预编译这种黑科技,是在代码编译的时候发生的,多以理论上来说会更快。相关技术可以参考prerender-sap-plugin
预编译原理:通过使用puppeteer或者比较旧的phantomjs进行浏览器模请求,生成静态html。打包的时候,将静态html打包的工程下。就这么简单。类似提前“彩排”了一样。当真实用户访问的时候,将已经“彩排”好的html直接发送给用户即可。
2、
缓存技术:缓存技术,在首次加载的时候,会很慢。之后会很快。包括pwa等等,感觉暂时没啥新意。或许对于目前的我来说,离线缓存等技术,应用的场景不是很多。本身spa的速度其实已经挺快了。暂时不去研究。

狼叔的一个问题回答

问题:2018 前端技术规划该包含什么?
答案:目前大家都在炒冷饭,pwa,ssr,amp,webcomponent,甚至是graphql,毫无新意,没啥劲,散了吧。如果发非要掰扯,我推荐node搞区块链智能合约truffle,node做ai的tfjs,就算风口过了也能学点东西,万一上风口呢?