@auto8888 #17 我不是 C 程序员，完全不懂哈，我只是觉得您的截图，字体和配色太花眼了，我第一眼看过去就觉得看代码的成本太高。虽然 IDE 只是点缀，但是从某一个角度来说，配合熟练并且本身就更优秀的 IDE，应该相对来说更能提高工作效率。当然这点我有点主观，看看就好。

另外如果只考虑 IDE 本身，并且非要推荐的话：
假如没有特殊情况的话，比如 sublime text，相对来讲默认样式要养眼很多。
再现代化的就可以考虑 vscode 或者 Jetbrain 家的产品是否能满足你的开发要求。

我不懂 C/C++，所以考虑不到这些 IDE 是否适合对应的工作流。

@NeilWang #59 居然是不支持 firefox

我就想说 2 楼，搞 C 语言就必须用这种我一眼看过去直接眼花的字体和配色吗？
你们这些底层开发人员就不能对自己好一点，搞一些现代化的东西，非得整电话机 010101 那套吗？
而且现在市面上方便好用的 C 的 IDE 多的是吧？

我是真的替你们感到眼睛累。。。手动狗头

没懂，我还是打不开 demo 啊，大家都能打开？
比如这个： http://pywebio-demos.demo.wangweimin.site/?pywebio_api=bmi
打开之后 GET http://pywebio-demos.demo.wangweimin.site/bmi?test=1 返回 400 啊

demo 全都挂了啊？连不上 ws

@x1911 #1 直接去看原文啊，都写完了，不用等 https://i.v2ex.co/504J5BO2.png

其实是个聊天技巧的问题，跟工资有啥关系？

不顶不是打工人 https://i.v2ex.co/504J5BO2.png

哈哈，很强，值得 star 。

@44670 #5 横屏也挡住了呀。。。

@AllenHua #32 哦，对，是独占的。

@ETiV #79 就用用免费的吧，千万别赞助 https://i.v2ex.co/504J5BO2.png 。altserver 这套东西不稳定。

添加到主屏后点不到底下的按钮，被 ios 那条横线挡住了

首先你这个东西主要针对单页面，那就不要对标需要加载页面的情况。非 SPA 有各种存在的原因，比如说如果要考虑 SEO，多页面就比单页面方便很多。
其次即便是你所谓的 native，也很早就有使用 history 来进行页内跳转的小型框架了，不是没有，依然是看需求而已。
再次 redux 所谓的搞得太复杂了前端社区学不动了，真不知道是哪来的自信写出这样的话？不仅 redux 本身并不复杂，而且前端使用 redux 的大有人在，并且的并且也并不是人人都需要用 redux 。

‘虽然依旧是屎山’ 你写你的框架，我写的 Javascript 屎山关你屁事？在这强行提高自己自高 go 干嘛呢，当自己是 Linus ？

你可以不想学 Javascript 世界的新东西，这没问题，但是既不去了解，也不做客观的比较，匪夷所思。

下一步，搞定谷歌的 recaptcha https://i.v2ex.co/504J5BO2.png

改变路由何来的结论会导致 reload，又何来的消耗大？
而且也没听说谁开发 SPA 项目遇到了 router 导致的性能问题啊？

另外和 React 、Vue 对标的说法不叫 native 吧，非要形容应该是原生 Javascript，也就是 Vanilla Javascript ？

go 多好啊，折腾什么 Javascript https://i.v2ex.co/9kZ3y873.png

我说完全看不懂是因为贴文里太抽象化了：

‘SSR 返回的是一个 Html，而 React Server Component 返回的是一个 React 可解析的结构。’
看完原版：RSC 返回的是可以提供给客户端 React 用来进行 merge 的 tree 数据（看例子是纯文本，类似 reactjs.org 那种套路）

‘而 React Server Component 返回的并不会让页面重新刷新而丢失状态。’
看完原版：因为上一点，所以变化的只是 tree，不涉及数据，也就不涉及状态改变

‘组件的业务数据拉取放在了服务端来做，并且服务端组件不会被打包到前端代码中，对于前端来说，整个网络请求只有一次。’
看完原版：Dan 向来喜欢明晰概念，所以‘不会打包到前端代码中’的实现包含了他的核心概念：服务器端组件，客户端组件，共享组件。以此来区分和进行实现。然后就能理解到其实它是做了很细致的划分并且由使用者来保证如何不对前端的打包产生影响的。
并且‘整个网络请求只有一次’不太严谨。原版描述的逻辑是目前使用的 http chunk 来实现分段数据加载，我后面有看 RFC 理解到它一个例子里的那种组件，是有可能产生多个 chunk 数据段的。而且并不限于 http/1.1，websockets 和 http2 都是有可能使用的。

另外原版还有一些有意思的点：
1. 比如 search 功能，既展示了 RSC 使用服务器端资源的例子，也展示了（ RFC 里有描述） http chunk 传输数据的特性实际跑起来是什么样子；
2. RSC 返回的是 tree 用来 render 的数据，感觉可以理解为通过服务器来触发 reconcile，甚至还能按需加载组件，这是我个人觉得很厉害的一个点；
3. Shared Component，也就是共享组件的存在。当服务器端组件使用 SC 的时候，SC 不会传输到客户端。但是如果客户端组件使用了 SC，RSC 可以利用 2 描述的能力，通过 stream 把这个组件和该组件所需要包含的服务器端数据动态传输到客户端；

另外 RFC 里有写到一点是：会加重学习的负担，我觉得真的是说的太对了。。。https://i.v2ex.co/9kZ3y873.png

RFC: https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

还是看看原版吧。。。

原谅我完全没看懂