目前的博客存在的问题:
总之, 现有的博客程序,
上面的各种模块, 主题, 插件各自独立, 使用者可以抽取需要的, 在简洁的基础上完成特定需求.
已经筹备良久, 预计七月正式开始开发. 当然, 这个项目的难度非常大, 正式版本的推出时间至少要一两年, 也随时有弃坑的可能性.
相关信息将在Azalea.moe和 QQ 群 107349757 进行更新. 欢迎关注. 也欢迎提出建议.
最后如果觉得不错, 请点个赞, 这将成为这个计划是否实施的决定性因素 因为如果预料到用的人不会多的话, 我只能开发我需要的部分, 只集成我个人需要的功能.
1
laoertongzhi 2019-05-20 22:01:21 +08:00
标记下
|
2
ningfeng 2019-05-20 22:02:37 +08:00 1
Wordpress 万物起源,你说的这些他都可以实现
|
4
pluvet OP 文章中漏掉的几个字(貌似被锁定了, 不能修改):
>前者还过于臃肿(指 Wordpress) >总之, 现有的博客程序, 已经不能满足人们表达自我的需要 |
5
oblivious 2019-05-20 22:07:46 +08:00 via iPhone
插眼!我也觉得 hexo 好不方便(部署在 github pages 上的确很方便)。
数学公式真心是硬需求,点赞点赞! |
6
pluvet OP 想要参与开发的同学, 也可以入群, 不会写项目的, 虽然本人不才但也可以现教, 我一个人恐怕要的时间会非常多
|
7
ShangJixin 2019-05-20 22:22:39 +08:00 via Android
typecho 这边 肥皂群里有个大佬总结了一份手册之类的那种东西,基于官方文档改的,然后又加了些其他人总结的东西。感觉折腾 typecho 起来能方便不少
https://docs.qqdie.com |
8
dixeran 2019-05-20 22:23:07 +08:00 via Android
Ghost 不是静态的,能在线编辑,也提供 API。另外,博客系统的吸引力很大程度上相关于优秀主题的数量。
|
10
Newbing 2019-05-20 22:42:44 +08:00
contentful
|
11
Kilerd 2019-05-20 22:49:18 +08:00
跟我现在自己写的那个博客系统很像了。
其实最重要一点就是提供完善的 API 就完事了。 |
12
4IoNut698v3Xgc2p 2019-05-20 22:53:51 +08:00 via Android
看你说的不赖啊,感觉我可以帮写主题
|
15
liangzi 2019-05-20 23:03:34 +08:00 via Android
wikijs 你值得拥有
|
16
agdhole 2019-05-20 23:09:11 +08:00 via Android 1
楼主这个系统我以前搞了一半放弃了,当时还是多语言多框架同步搞方便用户选择,后面发现如果要部署后端,太笨重,遂弃之,现在在搞基于 github api 的纯前端文档中心,只需要一个前端程序并输入项目地址即可解析 GitHub 上的 md 文件,兼容类 gitbook 目录结构,部署也方便,不需要单独购买服务器,GitHub page 直接就能跑。
|
18
pluvet OP @agdhole 谢谢回复, 后端打算先用 php 做一份, 相较于 nodejs 更容易跑起来, 关键是要让**虚拟主机**都能安装, 门槛越低越好
|
19
Akkuman 2019-05-20 23:23:32 +08:00 via Android
我倒是越来越懒了,我倒是直接想写个 shell 脚本自用,自动查看我的博客园然后同步到我的 github pages ( github pages 也是用的 TravisCI),之前也考虑过上面的所说的直接用 api 去搞,不过感觉这样来说的话,都是 json 数据,收录很不友好感觉会
|
20
pluvet OP @Akkuman 这个我也考虑过,打算支持多端同步,并不只是做个博客,什么微博啊,推特啊,甚至贴吧发帖,b 站,还有博客园都要有自动同步的选项或者插件,最终目标就是彻底的个性化,沉浸式,同时多端备份,确保个人的东西能保存好,像不久前贴吧就出事了,多少人辛辛苦苦写的东西就没了
|
21
Kilerd 2019-05-20 23:36:56 +08:00
@pluvet #14 我现在的逻辑是这样的
完善的 RESTFUL API (施工中) 简单的本地模版,用于脱离云使用。 有了 API,就可以做这些事情了。 一个云管理平台(依赖 API CURD 文章),甚至可以做到多个网站一起管理 文法的话,这个在系统实现好这些,然后在新建文章的时候指定某一种就好了。反正 JS 很多 math 和 latex 的插件。 这个也不是难事 支持主题. 支持自动静态 git/ftp 部署. 这两个就是做不做的问题了,有了 API,简直不要太简单。github + ci => github page 也就是几分钟的事情。 |
22
Mayuri 2019-05-21 00:09:16 +08:00 via Android
前景真心不错,赞!!
|
23
RYAN0UP 2019-05-21 00:14:19 +08:00 via Android
点赞! 顺便推推 https://github.com/halo-dev/halo.git
|
25
FrankFang128 2019-05-21 02:37:40 +08:00
你不如先定 spec,而不是先去实现
|
26
d5n 2019-05-21 06:45:24 +08:00 via iPhone
说的这些功能都是我想要的!期待楼主大作!
|
27
sama666 2019-05-21 07:39:11 +08:00 via Android
@pluvet wp 用了两三年了,的确太过臃肿,有时候回归本心直接 typecho jelly 和 hexo 了
|
28
Cbdy 2019-05-21 09:07:55 +08:00 via Android
说出来你可能不信,我用 Confluence
|
29
SuperMild 2019-05-21 09:24:36 +08:00 via iPad
api 设计是重中之重,一定要考虑周全。
|
30
sanmmmm 2019-05-21 10:48:11 +08:00
额。。跟汤不热有点像?
|
31
gz911122 2019-05-21 10:55:00 +08:00
支持一下
我也想过做个这种东西 |
32
edsheeran 2019-05-21 11:44:58 +08:00 via iPhone
先了解一下 wp 和 ghost 再來做你要做的替代品,你這樣顯得很不專業
|
33
mzsongyan 2019-05-21 11:50:21 +08:00
|
34
hing 2019-05-21 11:55:20 +08:00
可以了解一下 JAMStack
|
35
lotosbin 2019-05-21 11:55:25 +08:00
|
36
pluvet OP |
37
flxxy 2019-05-21 12:35:53 +08:00 via Android
……你和我去年开始整的一样
|
38
designer 2019-05-21 12:44:19 +08:00
这个工程很大,而且以后流行组件拖拽形式创建页面样式。
|
40
looking0truth 2019-05-21 13:48:39 +08:00
说起部署简单 就不得不提一句 Go 了 /狗头
|
41
hcs66 2019-05-21 13:50:47 +08:00
Writeathon 也在考虑提供开源版本,这方面经验不足,可以探讨下
附介绍: https://www.writeathon.cn/share/5c0df586e893e179e9f944dd |
42
pluvet OP @hcs66 试用了一下,UI 比较美观,编辑界面样式不错,比 VSCODE 美观好用,书写体验很不错。但是没有 stackeditor 和 typora 直观。比较特色的一点是个人主页和分享功能,目录大纲漂亮,还可以导出,让用户更放心。
以后希望能考虑和我们合作,实现一些像是直推到博客的之类的功能。 |
43
alan0405 2019-05-21 15:00:15 +08:00
给客户一个空间,让他自己写
|
44
woahishui 2019-05-21 15:33:50 +08:00 via Android
楼主的意思是让客户选择一个随时可能被放弃的程序用到自己的公司中,脑子瓦特掉了
|
45
woahishui 2019-05-21 15:35:20 +08:00 via Android
如果一个客户连一年的空间费用都要考虑,那你的意思是大家都要跟着你给这些吝啬到极点人提供安心的服务了
|
46
huiyadanli 2019-05-21 15:40:04 +08:00
既然前后端完整分离,且语言不限制的话,先出一个 API 的设计与约定吧。。
|
47
woahishui 2019-05-21 15:42:11 +08:00 via Android
有很多人很奇怪,说是做项目积累经验,以后可以找到好工作,我希望大家真正体会积累的意思,希望大家积累项目而不是项目经验,项目永远是你的,即使别人否定了他也是你的,但如果你只积累经验,被否定你剩下的只有。。。。
|
49
cifermail 2019-05-21 15:54:52 +08:00 1
也遇到过题主的问题,觉得想法很好,不过难以落地。
1. 首先开发量很大,做这个的目的是什么,毕竟时间比金钱还贵,这么做能获得什么样的收益? 2. 支持前端自由模板,后端自由语言,这个想法非常好。前端可以让用户选一些默认模板,后端如果让用户自己写的话,是不是对用户会有一点要求,这与先前的 30s 搭建完成有冲突。那就相当于要有一个默认后端语言开发好的东西,而自由后端语言只是扩展,这个 RESTFUL 也只是扩展下的一个标准( PS:好奇为什么用 RESTFUL 而不是 GraphQL ),然后,自己能写后端与前端的用户,已经可以随意的订制个人博客了,本人博客就是自己订制的。 3. 支持在线公式、图形,这个应该是亮点了,这个难度较大。 4. 代码高亮,这是个难题,十有八九还是可能会选择一个现成的库。 5. 对于新手是否需要一个富文本? 如需,也是一个麻烦,这是个大坑。 6. 如何让博客不是孤岛,这些博客都是用户自己安装到自己的服务器上了,本来就是独立的。话说,买域名,域名解析,买服务器( wall 外),配置搭建难以一键化,新手搞上一天都有可能。如果完成做成注册制写死的话,又不自由了,只要数据库与代码不在用户手上,都是不自由的。 7.上面有人说了,从 api 拉取数据自定义解析成 html 的话,解析过程放在前端的话,就无法 SEO。 8.上面功能较多,但还是不全,不同的用户会有不同的需求。与此同时,现有的功能已经有点“重”了。 9. 真的,真的有这么多用户写博客吗?他们缺的可能不是笔,而是动力。缺的不是博客网站,而是写博客本身的需求。 |
50
ylsc633 2019-05-21 16:03:00 +08:00 1
"Hexo, Ghost, Hugo 等静态博客: 不能在线编辑, 不能手机编辑. 对于非专业人群难以快速实现搭建. 维护难度大."
非专业人群难以快速实现搭建.. 我觉得.. 最简单的 lnmp 很多非专业人士也搭不起来..... 另外, 后面说到前后端分离.. 我不知道 题主打算怎么做 seo... 我觉得最简单的方式(我没用过), 好像是那种直接 markdown 编辑直接发布. 连后端服务都不要的是最简单的.. 如果想要 UI 好看的.. 但是不会写很多代码的. 还是现成的博客系统比较好用.. 因为主题够多.. 下载后会点 html 就可以改.. 如果想要不一样的.. 那就只能自己上手自己写了... 最后弱弱问下.. 玩博客的.. 还喜欢独特 UI 界面的.. 大多都应该会自己写吧... |
51
pluvet OP @cifermail 感谢你的回复,下面我说说我的想法,如有不明白的,欢迎加群或 slack,然后进入我们的 trello 讨论组讨论。
1. 做这个的目的很简单,就是满足需求,这个项目本身不指望也不在乎盈利的,它是对现状不满的产物,即使我现在不做,只要需求还在,以后也会有其它人做。 要完成一切的功能,我一个人鼓捣几年绝无可能,而且现在的设想也只是头脑风暴而已,理论和实际上都不可能全部实现,仔细看看就会发现,光是需求之间就有矛盾。我的打算是先出一个精要的版本,作为内测版本,此版本首先解决的核心需求就是:a. 创造的同时博客间社交的需求 b. 多客户端的优质书写体验的需求 c. 数据安全、数据同步的需求 。这些需求实际上各有现成的实现,甚至可以和已有的服务对接,因此在这一阶段,工作量并不算大,也就是几个月的事情。 2. 后端如果让用户自己写的话,是不是对用户会有一点要求? 这个项目的纽带其实在于 API,它更像是一个规范。我们打算用门槛最低的 php + sqlite 作为官方示例后端。而有能力的开发者,也可以用 go,nodejs,python 等等实现。(不过说实话,这里存在大量有待进一步考虑的问题)。用户的行为是这样的:域名和主机的绑定->上传程序->打开安装页面->设置管理员账号密码->安装完毕。对于官方后端,可以保证安装的便捷性。而对其它语言的后端,我们无法左右开发者的选择。至于 restful 的问题,其实现在还没有拿定主意,选择 Restful,Graphql 或者传统的 service.Action ( rpc ),各有优劣都有可能。GraphQL 的话后端用 nodejs 写会更好,但目前决定用 php,个人更偏好 rest 是因为 rest 比较成熟,工具也多(指 php 上) 3. 这些属于前端插件,是否实现,如何实现取决于前端工程师。统一用现成的 js 库是最快的方法。我们的能力做不到连这个都造轮子。官方前端的话,自然会选现有库。 4. 代码高亮这种自然也是丢给前端和用户去选择。官方前端的话,自然会选现有库。 5. 仍然是前端的事情。到时候应该会有各种编辑器的插件可供选择。由于前后分离,切换起来非常方便。 6. 博客互联并不是强制的。站长同意接入之后,先注册一个账号,验证所有权,互相分配密钥,就可以接进来了。 7. SEO 本质上就是输出 HTML 的问题,正文部分用后置解析器解析为 HTML,然后统一一个输出格式就行。比如 discuz archiver,收录效果就比较好。当然,服务端渲染也是一个选择,但不是一个好的选择。 8. 有插件机制。模块是可拆解的,你可以做出庞然大物,也可以做得小巧。这取决于用户,我们会提供灵活度。 9. 这个问题我已经详细回答过了,不重复了。 |
52
d5 2019-05-21 17:24:23 +08:00
mark,netlifycms 对静态博客的可视化编辑支持得挺好的
|
53
pluvet OP @ylsc633 在云主机搭建 lnmp/lamp 是比较困难,甚至比 nodejs 和 golang 搭建都难。所以选择 php 开发,虚拟主机就可以运行。虚拟主机是不需要你搭建什么的,只要设置域名,绑定域名,上传安装就行。
|
54
gonnacai 2019-05-21 18:25:08 +08:00
楼主,CPU 和内存不值钱。真正值钱的是写博客的、发照片的和维护人员的时间。
根据摩尔定律,宽带和硬件只会越来越便宜。 发射阿波罗的计算机性能,不如今天一台 iPhone 的 CPU。 不要重复发明轮子 |
56
guixiexiezou 2019-05-21 18:34:15 +08:00
重复发明轮子
|
57
dsnake1984 2019-05-21 18:35:42 +08:00
毕业论文?
|
58
AlloVince 2019-05-21 19:06:40 +08:00
我的 blog https://avnpc.com/ 基本实现了 lz 的大部分想法
后端 ( https://github.com/AlloVince/avnpc.js )支持将 Github repo 作为数据存储,支持 RESTFul 和 GraphQL 两种格式的 API 前端 ( https://github.com/AlloVince/avnpc.front ) 基于 next.js ,使用 SSR 渲染后端 API。 使用了 markdown-it 系列,因此可以支持 markdown、语法高亮、数学公式,mermaid 图表 ( https://avnpc.com/pages/markdown-render-demo ) 评论使用 gitalk,直接用 github issue 作为评论组件 当然现在只是我个人自用的,不过应该可以作为参考 |
59
nn1023 2019-05-21 19:14:01 +08:00
标记
|
60
LokiSharp 2019-05-22 08:45:47 +08:00
数据库别用 MySQL 了 直接 Postgresql 吧
|
61
ccino 2019-05-22 08:56:53 +08:00
少打字了? |
62
maemolee 2019-05-22 19:49:13 +08:00
我其实很期待楼主的作品,或者说,符合楼主这个设想的作品。
|
63
OysterQAQ 2019-05-23 21:41:26 +08:00
建议先设计出一套真正经用巧妙的、可扩展的博客 api 规范,这一点先完成吧。足够好,就会有人愿意遵守。才有可能有生态
|
64
UIXX 2019-05-24 10:47:27 +08:00 1
经历过 Web1.0、2.0 时代,并且做过大大小小博客以及论坛系统的人说几句。
通常一个想要开发新博客系统的人,包括以前的我,都有一个误区,那就是站在自身技术的角度来设计程序。 博客是一个重内容、重运营的自媒体形式,其系统的大部分设计都是偏向创作者的内容产出,而不是技术运维。 知道了这一点就不难理解,为什么这么多年,大部分人都还在用 wordpress。(论坛系统在这方面尤为突出,Discuz、动网、phpWind、phpBB 这些十几二十年前的程序至今仍占领着互联网论坛系统的百分之九十以上。) 是否前后端分离,怎么设计前端,怎么开发后端这些东西,作为被服务对象的创作者,他们不关心也不应该去关心。 他们在意的是,有没有足够多的功能以及插件可以用,能不能支持社区建设以及 RMB 打赏...这类系统越来越重恰恰是说明了它们想跟创作者靠得更近。 当我们自以为是的这些技术特性无法在博客运营当中产生效益,它们自然也变成了可有可无的东西。 试问,重新设计系统的产出与获得的利益不成正比,谁还会去花大力气地去发明轮子。 -----------------------论点分割线----------------------- 从现在的硬件角度来看,云主机 /VPS、独立主机价格越来越便宜,(博客经营者的)运维成本越来越低。只要维持“博客产生收入--收入支持( IT )服务--服务支撑博客”这个链条,在硬盘、内存、IO、带宽等资源绰绰有余的情况下,即使 Wordpress 再大一倍,使用者也不会有任何差异感知。当然访问量上百万是另一个话题了,但这个用户比例很低。 -----------------------论点分割线----------------------- 博客的衰落也不是单单一句“缺乏互动性”就可以概括的,事实上,博客本身并不缺乏互动性。 博客的问题并不是技术上能解决的,根本原因是它的经营理念(初衷)落后于时代。 1. 自我表达的欲望一直都在,不过表达的门槛在随着时代逐步降低,当今互联网得草根(屌丝)者得天下 博客时代对于创作者来说是有文字门槛的,它隐性地要求创作者必须要有自己的消化产出,且这类产出必须是要书面的。 从微博->直播->短视频媒体这个媒体爆红链条可以看到,文字创作成分减少,所见既得的要素越来越多,媒体服务的受众也越来越广。 “(门槛低导致的)创作者多--产出内容多--促进更多创作者加入”良性循环,大大挤压了博客时代的受众。(不过内容质量平均是在下降,这是另一个话题了。) 2. 泛娱乐产业更加成熟,内容的创作与运营更趋于专业化 博客在 Web2.0 的使用跟运营都很单一,无非是写文字、发表、链接转发,可以由创作者一个人完成,效果也常常跟创作者自身的条件(声望、文字功底)相挂钩。 现在的媒体表达更加多样化,媒体大咖有自己的团队,包括策划文案、视频拍摄、后期剪辑、经纪法务。创作的内容偏视觉感受,更能调动读者的感性思维,用户粘性更强。 3. 博客的效益转化很低 文字创作创作周期长,对读者有要求的同时版权保护力度小。 而现在的媒体偏视觉化,内容带有明显的个人或者团队的印记,有大众监督且平台参与维权。另外受众面广,粉丝经济效应明显。 并不是说改一下博客系统的实施,让用户有更强大的定制能力就可以完成时代复兴。 -----------------------论点分割线----------------------- 我始终认为下一个大众媒体的转折点还会回到内容本身上。没错,这与内容载体(背后用的什么技术)并无太大关联。 如果非要改进旧的博客系统,我有几个比较硬的需求方向。 1. 以 IM 来替代旧的评论系统 2. 运用更人性化的排版系统(大部分博客这一点做得很差),不需要让创作者去记什么 MD 语法,做到真正的所见即所得 3. 增加版权保护机制 |
66
UIXX 2019-05-25 11:53:45 +08:00
@songkeys
增加实时互动,有点类似于 gitter 的方式。 现在一些技术性的博客,对于用户反馈的处理方式都是将其导向 QQ 群或者微信公众号,那为什么不能直接在博客里面开一个 IM channel 来做这个事呢,还免去了加群关注等繁琐操作。 不过贴出二维码吸引粉丝加群是无可厚非的,毕竟那样更容易巩固粉丝群。所以才说要想办法提升博客机制的转化量,技术效能跟运营等非技术因素是息息相关的。 |
67
pluvet OP @UIXX 非常感谢你的回复, 你是少有的真正思考问题的人. 我也说说我的看法.
写博客的行为属于**创作或记录**, 而**后者**的目的可以分为以下几个方面(及其交叉和综合): - 经济效益. 获得稿费, 或者获得流量, 然后把流量变现. - 心理满足. 得到读者的关注和认同, 增加自身的知名度. 或者是为了让他人了解自己的内心世界, 对孤独的反抗. 或者是为了一种责任感, 一种使命感. - 寻求意义. 记录笔记或日记, 证明自己曾经学习过, 生活过, 经历过, 从而找到一种意义感. (我写作,是为了让光阴的流逝使我心安。——博尔赫斯 ) - 巩固知识. 更好地掌握知识, 获得能力. 从而能做更多的事情, 获得报酬或乐趣. - 其他目的, 如政治目的, 辩论的目的 博客的话, 对于第一类人来说, 并不是一个好的选择. 我打算造轮子, 主要是为了服务后几类人. 不过, 如果能实现博客的互联化, 能为其带来流量, 那么也将自然称为第一类人的选择之一. |
68
songkeys 2019-05-26 01:39:10 +08:00
@UIXX #66
> 为什么不能直接在博客里面开一个 IM channel 来做这个事呢,还免去了加群关注等繁琐操作。 可能触及性不如微信、QQ 那么强。用户没法主动每天都登录你网站。 不过我假想未来可能实现「万物」互联,任何博客、IM 等工具之间的也都有一套统一的通讯协议,这样大家都可以随时方便地触及任何不同的媒介。 |
69
UIXX 2019-05-27 13:36:23 +08:00
@songkeys
所以我才说博客系统的落后是一个时代的选择。 越来越多的人把发声渠道交由独立的 IM 系统,大众产出内容在 QQ、微信等工具上积累。这不是单独改善程序的某个点可以逆转的。 但如果想在原有博客系统上做文章,这的确是一个方向。 |
70
headwindx 2019-05-28 05:58:46 +08:00
比起做一个新博客,相信你更应该提前设计好 “社区技术协议”
|