(1) 2020 Dec. 21st

目前这个网站是采用的gulp + webpack的方式打包的静态网页,采用NGINX作为中转服务器的方式来架构。而博客端是采用的jekyll生成的静态网页。

所以尽管服务器非常便宜而低廉,仍旧可以保持非常高效的访问状态。
同时在大陆由于没有申报,所以处于半步被墙的状态。即便如此,在大陆仍旧可以有着可以接受的访问速度。
原因很简单。因为一切的一切,都是静态网页而已。
没什么能比静态网页更快了。

但是目前涉及到几个问题。
(1)gulp + webpack的模式,可以很好的完成自动部署。事实上我已经没有连接上服务器很久了,每次更新网站都是采用这种方式进行的自动部署。所以有一个大前提,就是无论如何优化,自动部署这一点不能扔下。
(2) 目前的前端完全是pure js,很标准的格式,所以有很多可以进行共通化的部分,没有进行共通化。这样在maintain的时候造成了一些困扰,不得不使用全局搜索。这也是我本次重构的一大原因。
(3) blog的静态部分,目前是使用的jekyll进行的部署,在文章数量还不算多的前提下,ruby base的jekyll可以达到很好的效果。但随着文章数量的上升,一是部署的速度势必会下降,二是jekyll必须遵循jekyll的文件夹结构,这对许多事情造成了一些麻烦。所以未来一定是用ajax来抽取markdown的文章,然后实时反映到网页上去。这方面以后再做。

这两个简单的功能,事实上使用vanilla js也并非办不到。
不过从便利性,以及维护性的角度来说,怎么看都是使用某一个framework比较好一些。

目前着眼的framework有两款,一款是reactjs,一款是svelte。
在多次尝试后,更加的偏向于使用svelte。纯粹的个人喜好原因。

但可惜的是,svelte是一个才面世没有多久的框架,整个生态还并没有很成熟,而且svelte很多时候很明显是在追随reactjs的脚步。

仿照reactjs的nextjs,svelte也有elderjs。但不得不说,这个elderjs并没有很棒的体验,它繁杂的配置,完全让svelte的优势荡然无存。
同时对于multi-page app,官方也有着自己的解决方案,就是sapper。
然而sapper本身竟然不是一个静态的网页的genetator,而是一个自带后端的一体化解决方案。这就有些让人头大了。 原来还有sapper export的存在

目前还在各种方案的检讨中。
看看能否用sapper,或者用svelte来用自己的方式写一个multi-papge的网页。
PS:这里的multi-page,指的是REST式的结构,唯一的URL可以确定唯一的页面。这也比较符合个人网站该有的样子。

(2) 2021 Jan. 6th

Bad Sapper

目前在逐渐的使用sapper来进行网页的重构,包括网站的模样也进行了一部分的精修改装。
然而sapper并不是处方良药,sapper也有着它作为新生子的一系列问题。

(1)由于是进行的client编译处理,导致无法直接使用browser API。 当然有着足够的回避策略。但是由于某些奇淫技巧而导致的系统维护困难,我想大家在c++身上已经栽过够多的跟头了。 (回避策:https://stackoverflow.com/questions/63044344/api-requests-in-svelte)

(2)sapper本身使用了一些“反正我不说你应该也懂的吧”的东西,譬如 _layout.svelte,譬如_error.svelte

(3)sapper至今仍未发布稳定版本,对于未来的维护而言有一定上升的成本

Good Sapper

然后为何使用sapper,而不是原生的svelte。 原因有这么几个。

(1)可以生成静态的html网页,而不是依赖page.js的动态解析的html,这样的网页对于SEO有莫大的好处。而且生成单独的静态网页,依赖svlete的优势,js包的size会变得非常小,网页的加载速度更快。是一种的极限编程。

(2)由于每个页面都是一个svelte,这种思路使得整个网页的层级关系会很明确,对于日后的维护会有所帮助

(3)sapper本身就是一个完整的全栈式解决框架,如果是从零开始的会非常有帮助,当然这一点对我来说几乎无效。

Svelte is not always good

当然,svelte本身也是有着不便的一面

(1)SASS的部分功能无法正常使用。 比如SASS代表性的MIXIN,想要跨越多个svelte控件使用几乎是不能完成的。(当然使用global可以部分使用,或者在html中import编译好的css)当然,跨越多个svelte空间使用css本身就不符合svelte的规矩。

(2)导入node_module的时候,如果是css,会非常的不便。最终的简单解决方案反而是放入static文件夹……简直本末倒置。当然也有别的方案可以解决这个问题。 (解决案:https://carlosroso.com/how-to-import-css-files-to-svelte/) (解决案:https://stackoverflow.com/questions/56483209/import-css-in-node-modules-to-svelte)

近期我还会仔细的考虑,是应该使用sapper继续重构我的个人网站,还是使用svelte本身来重构,亦或是Inferno.js。reactjs就免了吧,它的rebuild的速度慢到我要睡着。

(3)) 2021 Jan. 12th

网页构建完成。

使用的是svelte构建的单页面程序,使用pagejs来进行分页操控。

彻底放弃sapper,主要原因在于sapper是server渲染, 比如client端的fetch用不了,必须要用node-fetch。 client端的xhr用不了,必须用npm上面的xhr……

好端端的程序非要引入各种各样的package。
遂,放弃。

blog暂时仍然使用的jekyll来构建,不过未来打算使用svelte进行构建。

对网页整体的css量进行了大量的缩减,让网站的速度更提升了一个台阶。
不过svelte也还是有着各种微妙的小问题的。

(1)SEO不用说,必须对默认的index.html进行修改,不然很多爬虫是抓取不到页面数据的

(2)使用nginx配合page.js进行页面解析,把所有的url全部解析到index.html上面。 不过遗憾的是/about无法定义到/about, /about/倒是可以定义到/about上面。无奈只好使用301跳转,强制所有的/about跳转到/about/上面。

(3)svelte会对自己手写的css进行min压缩,但是对于@import引入的css并不会进行min压缩。(v3.31.2)

总体来说体验还是非常不错的,打算进行下一步的写作。


creativ common license