Just similar to Client side routing VS. server side routing, the topic is now change to rendering. Actually, the client side rendering make it possible for client side routing as each route invokes at least a rendering operation. If the rendering is executed by the client, that routing is client side routing. See, they are just the same thing at the end.

Why server side rendering?

• server-side rendering is great for SEO
• faster for the first time reaching the site

Why client side rendering?

• less requests for server
• better user experience after loading all resources

For my opinion, the only reason I may choose server side rendering is for SEO (and it won’t be a problem as crawler tech evolves). Assume you’ve opened a web page, it may be awful that each link on the page still costs seconds to open up. The client side rendering is more like loading a game. Once loaded, enjoy everywhere.

0

首先，一个很好的项目例子：express-4.x-local-example。

1

如果用到了session来存储登陆的信息的话（默认是用了的），必须实现passport.serializeUser和passport.deserializeUser两个函数，分别用于从user对象中提取一个唯一能代表该user的字符串（从而生成session key），以及通过之前提取的字符串反过来得到user对象。

2

passport.deserializeUser会在passport.session()返回的中间件中被调用，用来产生req.user属性。即，每次有请求进来，只要经过passport.session()中间件就会调用passport.deserializeUser，所以渲染一个页面可能会调用多次哦。这个函数的优化也就比较重要了，如果每次都要去数据库中查找用户信息不光效率低，数据库的压力也比较大，一种优化方法是把最近用到的一些加载到内存中（或者直接使用in-memory database，如果整个数据量不是特别大的话）。

3

passport.js对于登陆成功或失败提供了选项来redirect页面到不同的地方：

app.post(
  '/login',
  passport.authenticate('local', {successRedirect: '/', failureRedirect: '/login', failureFlash: true}),
);

最近尝试用了下react-starter-kit，其中进行预编译的方式是直接使用babel-node来执行Node.js脚本，比如npm start对应的命令为：

babel-node tools/run start

这个命令本身并没有什么问题，问题在于使用babel-node的方式无法用Webstorm进行debug，作为替代，官方建议使用如下的方式来执行脚本（见How to make Webstorm 2016.2 debug work with ES6 and babel）：

node -r babel-register tools/run start

然后问题就来了，在我尝试用后者来执行同样的脚本时冒出了下面的错误：

ReferenceError: regeneratorRuntime is not defined

这个错误的原因是有用到生成器的语句没有被正确polyfill，因而编译器执行时不认识这些语句了。但为什么后者会出现这样的问题呢？以及究竟要怎样做才能成功地使用Webstorm结合Babel进行debug呢？

babel-node VS babel-register

首先来解释为什么。

node -r babel-register其实相当于在执行后面指定的JS脚本之前先加载了babel-register（-r等同于--require）。因此上面发生错误的命令类似于使用node执行了下面的代码：

require('babel-register');
require('./run.js');

假设页面上有两个元素，一个很经典的CSS布局问题是：如何指定一个元素的宽（高）度，并让另一个元素的宽（高）度占满浏览器。正好之前做的项目中的前端部分碰到了这个问题，这里就来好好研究一下几个解决方法以及它们是如何达到这个效果的。

Use float

Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float did not exist. However, the current and subsequent line boxes created next to the float are shortened as necessary to make room for the margin box of the float.

float的元素虽然说是脱离文档流了（out of flow），但脱离得并不彻底，在同一个容器内的line boxes还是能看得到浮动的box，并且在布局时会让出空间给浮动的元素。作为对比，position: absolute的元素是彻底脱离文档流的，即其他任何元素在布局时都会对它视而不见。

w3c中关于line box的定义如下：

In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block. Horizontal margins, borders, and padding are respected between these boxes. The boxes may be aligned vertically in different ways: their bottoms or tops may be aligned, or the baselines of text within them may be aligned. The rectangular area that contains the boxes that form a line is called a line box.

一个例子如下：

See the Pen float - 1 by Curtis Yu (@curiousY) on CodePen.

可以看到，#right元素其实和左边的浮动元素发生了重叠，即block level box在布局时无视了浮动的元素，而#right其中的文字部分却挤在了浮动元素的右侧，即line box是能“看到”浮动的元素的。

浮动属性最初的目的就是如此：文字之类的inline-box可以围绕浮动的box进行分布。

SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.

SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLite does not have a separate server process. SQLite reads and writes directly to ordinary disk files. A complete SQL database with multiple tables, indices, triggers, and views, is contained in a single disk file.

SQLite，正如其名（SQL + light），是一个比较轻量级的支持SQL查询语言的数据库，它的数据就存储在文件系统的文件中（或者单纯的在内存中），因此创建数据库连接时（这种情况更像是初始化），只需要指定目标文件即可，同时也因为这种设计，它并没有像一些大型数据库那样提供一个TCP server来供远程调用（serverless），更不用说分布式了。因此，只有存储数据库文件的那台机器能够创建数据库连接，其他机器想要连接上该数据库只有进行文件的mount才有可能（当然并不建议这么做，同时操作同一个文件会有风险）。

SQLite is a compact library. With all features enabled, the library size can be less than 500KiB, depending on the target platform and compiler optimization settings.

SQLite非常适合用于嵌入式设备等存储和性能要求比较低的系统（比如手机）。

因为SQLite是基于文件来操作的，文件的写入肯定是要加锁的，虽然SQLite对并发性做了一系列优化，但这始终会是一个瓶颈，所以不建议把SQLite当做中大型服务端的数据库来使用。