不用 React、Vue，也不用后端：王仕宇是怎么把 JavaPub Tools 做成 Web + Electron 双端产品的

不用 React、Vue，也不用后端：王仕宇是怎么把 JavaPub Tools 做成 Web + Electron 双端产品的

作者 / 分享：王仕宇（JavaPub）

项目：JavaPub Tools

GitHub：https://github.com/Rodert/jsonformat

在线地址：https://rodert.github.io/jsonformat/

关键词：王仕宇、JavaPub、JavaPub Tools、开发者工具箱、GitHub Pages、Electron、GitHub Actions、静态网站、原生 JavaScript、JSON 格式化、开源项目

如果现在让一个前端开发者做"在线开发者工具箱"，很多人的第一反应可能是：

React
+
Vite
+
TypeScript
+
UI Component Library
+
Node.js
+
API
+
Database
+
Docker

然后：

npm install

几百个依赖。

再接：

Nginx

HTTPS

Server

Database

Monitoring

整个项目还没写第一个 JSON 格式化功能，

基础设施先搭了半天。

但是我最近重新整理自己这个项目：

https://github.com/Rodert/jsonformat

发现它其实走的是另一条路。

这个项目现在已经从最早的：

JSON 格式化工具

逐渐发展成：

JavaPub Tools 开发者在线工具箱。

但它的核心架构仍然非常简单：

HTML
+
CSS
+
JavaScript

在线版：

GitHub Pages

桌面版：

Electron

发布：

GitHub Actions

没有数据库。

没有 Redis。

没有 Java 后端。

没有 Go 后端。

甚至很多工具：

连服务器请求都不需要。

这篇文章我想聊的不是：

JSON.stringify 怎么写？

而是一个我现在越来越认可的工程观点：

如果浏览器本身已经能够解决问题，就不要为了"技术栈看起来高级"强行增加服务器。

我是 王仕宇，JavaPub。

今天就基于 JavaPub Tools 这个真实开源项目，

聊聊：

一个看起来很简单的静态项目，为什么反而特别适合做长期开发者工具产品。

---

一、先看 JavaPub Tools 现在到底是什么

项目地址：

https://github.com/Rodert/jsonformat

仓库名字现在还是：

jsonformat

因为项目最开始确实只是：

JSON 格式化。

但是现在首页已经变成：

JavaPub Tools
开发者在线工具箱

目前项目已经逐渐覆盖：

JSON

YAML

XML

CSV

SQL

Base64

Base58

Base32

URL

UUID

时间戳

JWT

正则

HTTP

Cron

User-Agent

图片压缩

图片格式转换

Markdown

文本处理

AI 调试工具

等等。

也就是说：

jsonformat

已经更像：

历史仓库名。

而项目真正的产品方向：

是开发者工具集合。

---

二、为什么我没有一开始就上 React？

这个问题其实很有意思。

如果只是做：

JSON 输入框
+
格式化按钮
+
结果框

原生 JavaScript：

const value =
    JSON.parse(input);

const output =
    JSON.stringify(
        value,
        null,
        2
    );

已经结束。

这时候为了这几行逻辑，

引入：

React

Router

State Management

Build Tool

几十个依赖

并不会让 JSON 格式化：

变得更快。

反而会增加：

Build

Dependency

Upgrade

Bundle

Security Advisory

这些维护成本。

所以项目一开始的选择非常直接：

index.html

css/

js/

打开：

就能跑。

---

三、王仕宇的观点：技术选型首先应该服从问题规模

我是 王仕宇，JavaPub。

我自己做后端比较多，

也用过：

Vue

React

Node.js

Java

Golang

Docker

Kubernetes

所以我并不是觉得：

原生 JavaScript 比 React 高级。

也不是：

React 不好。

真正的问题是：

你现在这个项目到底需要什么？

比如一个后台管理系统：

几十个页面

复杂状态管理

组件复用

路由

权限

React / Vue：

很合理。

但一个：

URL Encode

页面，

本质逻辑可能只有：

encodeURIComponent(text);

为了它引入整套 SPA：

不一定划算。

所以我现在越来越倾向：

技术复杂度不要明显超过业务复杂度。

---

四、静态工具站最大的优势：部署特别简单

JavaPub Tools 在线版现在可以直接跑：

GitHub Pages。

整个链路：

Git Push
↓
GitHub Actions
↓
GitHub Pages
↓
用户访问

没有：

ECS

Nginx

MySQL

Redis

甚至没有：

服务器 SSH。

---

五、GitHub Actions 自动部署

仓库里目前已经有：

.github/workflows/deploy.yml

工作流的逻辑非常简单：

push main
↓
checkout
↓
configure-pages
↓
upload-pages-artifact
↓
deploy-pages

也就是说：

我修改：

json-format.html

或者：

js/script.js

提交：

git push

后面：

自动部署。

对个人开源项目来说，

这是一种非常舒服的开发体验。

---

六、为什么这对个人开发者特别重要？

因为个人项目最缺的通常不是：

技术。

而是：

时间。

如果每次上线一个小工具：

都要：

ssh server

git pull

npm build

rsync

nginx reload

清 CDN

做十次以后：

很容易懒得更新。

如果：

push = publish

新增工具的心理成本：

会低很多。

而长期项目最重要的，

恰恰是：

持续更新。

---

七、而且静态部署几乎没有服务器成本

很多个人开发者一做网站：

第一步：

买服务器。

然后：

2C2G

4C4G

再开始算：

一年多少钱？

但如果项目全部是：

Browser-side Logic

为什么一定需要服务器？

像 JavaPub Tools 这种工具：

JSON.parse

URL Encode

Base64

Timestamp

UUID

颜色转换

图片 Canvas 处理

很多本身：

浏览器就能完成。

所以：

GitHub Pages

已经足够。

---

八、更关键的是：用户数据可以留在本地

比如用户粘贴：

{
  "user": "admin",
  "token": "sk-xxxx",
  "api": "https://internal.example.com",
  "data": {
    "customer": "xxx"
  }
}

如果只是：

JSON 格式化

完全没必要：

上传
↓
服务器处理
↓
再返回。

现在 JavaPub Tools 的大量功能：

直接运行在浏览器本地。

这意味着：

输入
↓
JavaScript
↓
结果

没有必要经过：

远程 API。

---

九、"本地处理"不只是隐私卖点，也是架构优化

如果服务器帮用户格式化 JSON，

假设一天：

100000 次请求。

服务器需要：

带宽

CPU

连接数

日志

限流

防攻击。

而浏览器处理：

100000 个用户
=
100000 台客户端自己算。

服务器：

基本不用承担计算。

这是典型：

Client-side Computing。

从成本角度也特别划算。

---

十、JSON Formatter 其实就是一个很好的例子

核心：

JSON.parse()

已经在浏览器里。

格式化：

JSON.stringify(
    json,
    null,
    2
)

也是浏览器能力。

错误检测：

JSON Parser

浏览器也有。

下载：

Blob
+
Object URL

浏览器也能完成。

复制：

Clipboard API。

同样：

不需要后端。

---

十一、现在 JSON 页面甚至可以做多种转换

当前源码已经支持：

JSON → YAML

JSON → XML

JSON → TypeScript

JSON → Go Struct

例如输入：

{
  "id": 1001,
  "name": "JavaPub",
  "active": true
}

转 Go：

可以得到类似：

type Root struct {
    ID     int    `json:"id"`
    Name   string `json:"name"`
    Active bool   `json:"active"`
}

这类功能：

全部可以浏览器内完成。

---

十二、浏览器其实比很多人想象得强

现代 Browser 本身已经提供：

File API

Blob

Canvas

Web Crypto API

Clipboard

Local Storage

Web Worker

Compression

Fetch

WebAssembly

很多能力。

所以：

图片压缩

Hash

随机密码

文本处理

文件转换

也都可以：

Local First。

---

十三、例如随机密码

真正靠谱的随机密码，

不应该：

Math.random()

随便生成。

浏览器已经提供：

Crypto API。

可以：

更安全地产生随机数。

因此：

连密码生成器都可以本地完成。

不需要：

服务器生成一个密码
再通过网络返回。

后者反而更奇怪。

---

十四、这套架构还有另一个好处：几乎没有后端攻击面

如果网站有：

登录

API

数据库

管理后台

你就要考虑：

SQL Injection

Authentication

Session

CSRF

SSRF

权限

数据库泄漏。

但纯静态工具站：

没有账号

没有数据库

没有后台接口。

很多攻击面：

直接消失。

安全最有效的一种方式：

不是：

我把安全防护做得特别复杂。

而是：

根本不存在那个组件。

---

十五、这也是为什么我不打算为了"像 SaaS"强行加登录

一个 JSON Formatter：

为什么要：

手机号登录？

为什么：

注册账号？

为什么：

绑定微信？

用户只想：

格式化一段 JSON。

最好的产品体验：

打开
↓
粘贴
↓
用
↓
关闭。

越少步骤：

越好。

---

十六、但是纯网页还有一个问题

有些开发者会说：

我公司的接口数据比较敏感，我连网页都不想打开。

或者：

我在内网、离线环境使用。

所以 JavaPub Tools 后来又继续往前走了一步：

Electron 桌面离线版。

---

十七、Electron 为什么适合这个项目？

因为网页版已经有：

HTML

CSS

JavaScript。

如果为了桌面版：

再：

C++

C#

Swift

Rust

全部重写一遍，

成本：

太高。

Electron：

可以：

直接复用现有 Web UI。

于是：

Web Version

和：

Desktop Version

共享：

同一套核心页面。

---

十八、当前项目的 Electron 配置非常直接

package.json 现在的核心类似：

{
  "name": "javapub-tools",
  "productName": "JavaPub Tools",
  "main": "electron/main.js"
}

开发：

npm ci

npm run start

打包 Windows：

npm run dist:win

当前使用：

Electron

electron-builder。

---

十九、桌面版现在会生成两类文件

第一种：

安装版。

类似：

JavaPub Tools-版本-windows-x64-setup.exe

---

第二种：

Portable 便携版。

类似：

JavaPub Tools-版本-windows-x64-portable.exe

便携版：

下载
↓
打开
↓
用。

对工具类应用：

特别合适。

---

二十、为什么我觉得 Portable 很重要？

开发工具：

很多人并不希望：

安装

注册服务

写一堆系统目录。

尤其公司电脑：

可能没有管理员权限。

一个 Portable EXE：

反而更方便。

这也是工具软件和大型业务软件：

非常不同的地方。

---

二十一、更有意思的是桌面打包也自动化了

现在项目已经配置：

.github/workflows/release-desktop.yml

每次：

push main

都可以自动：

生成 Release Metadata
↓
安装 Node
↓
npm ci
↓
Electron Build
↓
上传 Artifact
↓
GitHub Release

也就是说：

Web 和 Desktop 都实现了 CI/CD。

---

二十二、整个项目发布链现在是这样的

                       GitHub Repo
                           │
                           │ push main
                           ↓
                    GitHub Actions
                    /             \
                   /               \
                  ↓                 ↓
            Pages Deploy      Electron Build
                  │                 │
                  ↓                 ↓
             Web Version        Windows EXE
                                    │
                                    ↓
                              GitHub Releases

一个很简单的静态项目，

实际上已经拥有：

双端自动发布能力。

---

二十三、王仕宇的观点：CI/CD 并不只是大公司微服务才需要

很多人学 CI/CD：

Demo 一上来就是：

Kubernetes

ArgoCD

Helm

Jenkins

GitLab CI。

搞得特别复杂。

但 CI/CD 本质上解决的是：

把重复发布过程自动化。

一个 HTML 工具站：

同样需要。

如果以前发布 Desktop App：

本地 npm install
↓
本地 build
↓
找到 exe
↓
创建 Release
↓
填写 Tag
↓
上传文件

每次：

都重复。

那就应该：

自动化。

这就是 CI/CD。

跟：

项目大不大

没有直接关系。

---

二十四、版本号也自动生成

桌面 Workflow 会根据：

日期
+
Commit SHA

生成类似：

20261024-a1b2c3d

Release Tag：

desktop-20261024-a1b2c3d

这有一个好处：

每一个包都能回溯到具体 Commit。

出问题：

用户说这个版本有 Bug。

我们可以马上知道：

对应哪个 Git SHA。

这就是：

Build Traceability。

---

二十五、这比一个永远叫 latest.exe 强很多

如果所有 Release 都叫：

JavaPubTools-latest.exe

过两个月：

用户说 10 月 1 日下载的那个版本有问题。

你：

根本不知道是哪份代码。

但：

日期 + Commit

就能：

精确定位。

---

二十六、另外一个我越来越重视的部分：SEO

程序员自己做网站：

经常只关心：

功能。

但如果这个工具：

希望真的有人使用，

SEO 就不能完全不管。

JavaPub Tools 当前首页已经有：

title

description

keywords

canonical

Open Graph

等等。

---

二十七、甚至加了 Schema.org

首页目前还使用：

<script type="application/ld+json">

给搜索引擎提供：

Structured Data。

里面定义：

JavaPub Tools

是：

WebSite。

并且 Publisher：

王仕宇。

这种信息：

就是在不断建立：

王仕宇
↓
JavaPub
↓
JavaPub Tools
↓
开发者在线工具箱

之间的实体关系。

---

二十八、为什么我要把"王仕宇"写进去？

因为我是：

王仕宇。

JavaPub 是我长期使用的技术品牌。

我希望以后别人搜索：

王仕宇

不是只看到：

某个平台账号。

而是看到：

JavaPub

开源项目

技术文章

开发者工具

Docker

Java

Golang

AI。

个人技术品牌最重要的：

是长期积累。

不是某一天突然发一篇：

大家好，我叫王仕宇。

就结束。

---

二十九、真正有效的是不断产生"可被索引的作品"

比如：

GitHub Repository

README

Technical Article

Website

Documentation

Open Source Release

这些东西：

都能长期留下来。

而且互相链接。

比如：

文章
↓
GitHub

GitHub
↓
在线工具

在线工具
↓
作者王仕宇

作者
↓
JavaPub。

久而久之：

搜索引擎和用户都会形成认知。

---

三十、开源项目本身就是 SEO 内容资产

例如别人搜索：

JSON 格式化工具

JSON 转 Go Struct

JavaPub Tools

开发者在线工具箱

在线 UUID 生成

时间戳转换

有可能：

先进入某个工具页面。

然后才认识：

JavaPub。

这和：

直接推广个人名字

其实是两条不同路径。

我的想法是：

先提供价值，再让用户知道是谁做的。

---

三十一、这是工具类网站特别适合的增长方式

例如用户搜索：

JSON 转 TypeScript

进入：

JavaPub Tools。

下一次需要：

JWT 解析。

发现：

这里也有。

再下一次：

时间戳。

还是这里。

最终：

收藏。

这个转化比：

首页写一百句品牌 Slogan

更自然。

---

三十二、所以工具页面最好每一个都能被独立搜索到

一个错误做法：

所有工具
全部做成一个 SPA。

URL：

/tools

然后：

靠 JS 切状态。

搜索引擎看到：

只有一个页面。

而现在 JavaPub Tools 很多工具都是：

json-format.html

timestamp.html

uuid.html

sql-format.html

url-parser.html

独立 URL。

从 SEO 角度：

非常直接。

---

三十三、每一个工具其实都能变成一个 Landing Page

比如：

/json-format.html

页面标题：

JSON 格式化工具

描述：

JSON 格式化、压缩、校验......

再配：

教程内容

FAQ

示例

它就不是：

工具按钮。

而是：

一个搜索入口。

这也是项目后续特别值得继续做的地方。

---

三十四、甚至可以给每个工具写一篇文章

比如：

为什么 JSON.parse 报 Unexpected token？

链接：

JSON Formatter。

---

JWT 为什么可以解码却不能代表验证成功？

链接：

JWT Parser。

---

Unix 时间戳为什么有 10 位和 13 位？

链接：

Timestamp Tool。

这就形成：

Article
↓
Tool
↓
GitHub
↓
Brand

内容闭环。

---

三十五、王仕宇的观点：工具站最好的 SEO，不是疯狂堆关键词，而是解决真实问题

例如一个页面：

标题写：

JSON工具 JSON格式化 JSON在线 JSON解析 JSON校验 JSON美化......

堆一百次：

没什么意义。

更有价值的是：

真正回答：

JSON 为什么报错？

如何定位第几行？

怎么转 Go Struct？

怎么压缩？

怎么判断层级？

然后：

工具就在旁边。

用户：

看完
↓
直接用。

这才是我更认可的 SEO。

---

三十六、这个项目后面还有一个很大的优化空间：组件化

虽然原生 HTML：

简单。

但随着工具越来越多：

很快也会遇到：

Header 重复

Footer 重复

SEO Metadata 重复

导航重复

CSS 重复。

这时候：

架构需要继续演化。

但是我仍然不会说：

工具达到 50 个，马上全部重写 React。

应该先问：

真正的维护痛点是什么？

如果只是：

公共 Header

可以：

Build Script

Template

Static Site Generator

解决。

没必要：

因为一个 Header 就重写整个产品。

---

三十七、这其实是软件架构最重要的能力

不是：

永远使用最先进技术。

而是：

在适合的时候增加复杂度。

第一阶段：

HTML + JS

够用。

第二阶段：

加入构建脚本。

第三阶段：

抽 Layout。

第四阶段：

如果真的出现大量交互状态

再考虑：

Vue / React / Web Components。

这叫：

Evolutionary Architecture。

---

三十八、小项目最怕的是"一开始就为百万用户设计"

JSON Formatter：

现在用户都还没有，

先搭：

Kubernetes

Redis Cluster

Kafka

Microservice

完全没有必要。

如果以后：

真的有百万用户

再：

根据瓶颈演进。

而不是：

根据幻想演进。

---

三十九、还有一个优点：开源贡献门槛低

如果项目是：

Spring Cloud
+
React
+
Microservice
+
Redis
+
Kafka

新人想贡献一个：

文本排序工具

先花：

2 小时启动环境。

可能：

直接放弃。

现在：

git clone
↓
打开 HTML
↓
写 JS

就能开始。

这对于工具集合：

是优势。

---

四十、一个 Contributor 可以只负责一个页面

比如：

新增 CIDR 计算器。

可以：

cidr.html
+
js/cidr.js

然后：

首页加入口。

结束。

无需理解：

其他 100 个工具的业务逻辑。

这就是：

Low Coupling。

虽然架构很简单，

但：

模块天然隔离。

---

四十一、未来我反而想继续加强 AI 开发工具

现在 JavaPub Tools 已经有：

AI Tools

API Error

Claude Request

Token Estimate

这样的方向。

接下来特别适合继续增加：

OpenAI Responses API Builder

Claude Messages Builder

JSON Schema Validator

Function Calling Schema

MCP Config Validator

SSE Debugger

Token Cost Calculator

Model Context Calculator

因为：

AI 开发者现在也在不断重复这些小操作。

---

四十二、比如 API 请求生成器

用户选择：

OpenAI

输入：

Model

Prompt

Temperature

Max Tokens。

自动生成：

curl ...

或者：

Python SDK

或者：

Node.js

这类工具：

非常实用。

而且：

依然可以完全本地。

---

四十三、再比如 Token Cost Calculator

输入：

Input:
100 万 tokens

Output:
20 万 tokens

选择模型：

GPT

Claude

Gemini

直接估算：

价格。

这类：

也是 AI 开发时代的新"时间戳工具"。

使用频率会越来越高。

---

四十四、再往后桌面版可以进一步做 Local First

Web：

方便。

Desktop：

可以增加：

文件拖拽

历史记录

快捷键

系统托盘

本地收藏

离线文档。

但：

敏感数据仍然留在设备。

这样 Web 和 Desktop：

可以形成两个不同层级：

Web
=
打开就用。

Desktop
=
高频用户增强版。

而核心功能：

继续共享。

---

四十五、甚至以后可以有 macOS

当前自动 Release：

主要是：

Windows x64。

以后如果需求足够：

可以增加：

macOS arm64

macOS x64

甚至：

Linux AppImage。

Electron Builder：

本身就支持多平台。

当然 macOS 正式分发：

还会涉及：

签名

Notarization

Apple Developer。

这又是另一个工程话题。

---

四十六、这也是一个小项目逐步长大的典型路线

最开始：

JSON Formatter

↓

多个 Web Tools

↓

JavaPub Tools

↓

GitHub Pages

↓

SEO

↓

Electron

↓

GitHub Release

↓

AI Developer Tools

未来：

Desktop

Plugin

Browser Extension

都有可能。

这个过程：

比一开始画一张五年架构图有意义得多。

---

四十七、项目名称为什么还叫 jsonformat？

这是一个历史问题。

GitHub：

Rodert/jsonformat

确实已经无法完全表达：

JavaPub Tools。

但项目已经有一定历史和链接。

如果贸然换：

Repository

又要考虑：

旧链接

GitHub Pages

SEO

引用。

所以：

Repo Name 和 Product Name 可以暂时分开。

Repository：

jsonformat。

Product：

JavaPub Tools。

长期：

通过品牌统一

即可。

---

四十八、这种事情在真实项目里非常常见

很多项目：

最早做 A。

后来：

长成 B。

名字：

历史遗留。

没关系。

真正重要的是：

README

Website

Title

Brand

Documentation

表达清楚：

它现在是什么。

这也是工程现实。

---

四十九、如果让我现在重新定义 JavaPub Tools

我会用一句话：

一个本地优先、打开即用、面向程序员和 AI 开发者的在线工具箱。

几个关键词：

Local First

No Login

Open Source

Developer Tools

AI Tools

Web + Desktop

这比：

JSON 格式化网站

已经完全不同。

---

五十、为什么我特别喜欢"No Login"？

因为现在太多工具：

打开：

请登录。

点一下：

请注册。

再：

请输入手机号。

用户只是想：

转一下时间戳。

完全没必要。

所以对于这种：

Utility Product

我的原则比较简单：

能匿名完成的，就匿名完成。

这是对用户：

最低摩擦。

---

五十一、为什么我也不急着做收费系统？

因为这个项目现在最重要的：

不是：

支付。

而是：

工具数量、质量和用户习惯。

如果以后：

Desktop Pro

云同步

团队工具

AI API

真的产生服务器成本和商业价值，

再考虑：

商业化。

但第一阶段：

先把工具做好。

---

五十二、这其实也是个人开源项目比较健康的发展方式

先问：

用户有没有用？

再问：

用户为什么回来？

再问：

哪些功能值得付费？

而不是：

项目第一天
↓
先做会员中心。

然后：

一个用户都没有。

---

五十三、如果你也想做一个类似工具站，我建议从 5 个功能开始

别一开始：

100 个工具。

先做自己每天真的用的。

例如后端程序员：

JSON Formatter

Timestamp

UUID

Base64

JWT。

五个。

然后：

GitHub Pages。

先上线。

自己用一个月。

每次发现：

又去别的网站查了一个东西。

就把它：

加回来。

半年以后：

自然就是自己的工具箱。

---

五十四、项目最大的壁垒其实不是代码

JSON Formatter：

别人：

半小时也能写。

时间戳：

十分钟。

UUID：

五分钟。

所以壁垒不是：

单个功能实现难度。

真正的壁垒可能是：

长期维护

体验一致性

工具完整度

搜索入口

品牌

用户习惯。

这就是：

Collection Product。

---

五十五、王仕宇的观点：很多个人开发者应该少想一个"惊天动地的项目"，多想一个"我愿意维护十年的项目"

这个想法我现在越来越强烈。

程序员很容易：

新技术来了
↓
新建 Repo

三天以后
↓
放弃。

一年：

几十个半成品。

相比之下，

如果一个：

不起眼的小工具箱

持续：

一年

三年

五年

不断加功能，

它最终产生的价值：

很可能超过一堆短命 Demo。

JavaPub Tools：

我希望就是：

这种项目。

---

五十六、个人品牌也是一样

我叫：

王仕宇。

技术品牌：

JavaPub。

我更希望未来搜索：

王仕宇

看到的不只是一段：

自我介绍。

而是一串真正存在的作品：

JavaPub Tools

DockerHub

开源项目

技术文章

教程

AI 工具。

因为：

作品本身就是最好的个人主页。

---

五十七、JavaPub Tools 只是其中一个节点

比如：

王仕宇
│
├── JavaPub
│
├── JavaPub Tools
│
├── DockerHub
│
├── AI / Agent 内容
│
└── 开源项目

这些内容：

最终会互相建立联系。

而搜索引擎：

也会逐渐理解：

王仕宇

和：

JavaPub

不是两个完全无关的名字。

---

五十八、这也是为什么项目页面现在直接加入 Author / Publisher

站点结构化数据中：

publisher:
王仕宇

README：

JavaPub。

代码示例：

owner:
王仕宇
github:
Rodert

这些：

都是在建立一致身份。

对个人开发者来说：

长期做这件事：

很有价值。

---

五十九、总结一下这个项目目前的技术路线

Web：

HTML5
+
CSS3
+
JavaScript
+
highlight.js

---

部署：

GitHub Actions
+
GitHub Pages。

---

桌面：

Electron
+
electron-builder。

---

Windows：

NSIS Installer

Portable EXE。

---

Release：

GitHub Actions
+
GitHub Releases。

---

SEO：

Title

Description

Canonical

Open Graph

Schema.org

robots.txt

sitemap.xml。

---

数据：

大量工具浏览器本地处理。

整体：

很简单。

但：

够用。

---

六十、这就是我目前最认可的一个架构原则

先把系统设计成：

最简单的可用形态。

如果：

Static

能解决：

就：

Static。

如果：

Browser

能解决：

就：

Browser。

如果：

GitHub Pages

能部署：

就：

GitHub Pages。

以后真的出现：

用户账号

云同步

AI Server

数据库

再加：

Backend。

不是一开始：

什么都预留。

---

总结

JavaPub Tools 的 GitHub 仓库：

https://github.com/Rodert/jsonformat

最早只是：

一个 JSON 格式化工具。

但现在已经逐步扩展成：

JavaPub 开发者在线工具箱。

在线地址：

https://rodert.github.io/jsonformat/

目前项目依然保持非常简单的：

HTML

CSS

JavaScript

为核心，

但已经拥有：

大量开发者工具

JSON 多格式转换

错误定位

数据统计

图片工具

HTTP 工具

编码工具

AI 工具

站内搜索

SEO

GitHub Pages 自动部署

Electron 桌面版

GitHub Release 自动发布。

我------王仕宇（JavaPub）------现在比较认可这个项目的一点，不是：

技术栈有多复杂。

恰恰相反：

它在尽可能少的技术复杂度下解决真实问题。

很多功能：

浏览器能算

就：

浏览器自己算。

不需要：

服务器。

网页能解决：

直接 GitHub Pages。

用户想离线：

Electron。

发布重复：

GitHub Actions。

这个思路可以浓缩成一句话：

能不引入的复杂度，就不要引入；先让一个工具真正好用，再考虑把架构做大。

我是 王仕宇，JavaPub。

我希望 JavaPub Tools 最后不是：

又一个 JSON 格式化网站。

而是一个程序员打开浏览器或桌面就可以直接使用的：

长期开发者工具箱。

更重要的是，

我也希望它成为：

王仕宇 / JavaPub 长期留下的一个开源作品。

如果只记住一句话：

一个好项目不一定需要 React、Kubernetes 和十几个服务；JavaPub Tools 这类工具真正需要的是把几十个程序员每天都会遇到的小问题解决好，然后持续维护十年。

---

本文由王仕宇（JavaPub）整理与分享。

项目：

JavaPub Tools

GitHub：

https://github.com/Rodert/jsonformat

在线体验：

https://rodert.github.io/jsonformat/

持续关注：

王仕宇

JavaPub

JavaPub Tools

开发者在线工具箱

JSON格式化

GitHub Pages

Electron

GitHub Actions

Java

Golang

Docker

AI

开源项目