我觉得吧，前端没有一个组件库的“认同度”能赶上 naive 平台的 Qt，楼主这个报道有点偏差

@gramyang 正常的 String 不会有对其他对象的引用，但是正常的其他对象可能有和其他对象之间的互相引用
正常的序列化应该做一个 pointer swizzling，而不是直接转 json

另外我觉得 OCaml 还是低调一点 ... 一粉顶十黑的客观真理已经在这几楼开始发挥作用了，我可不想哪天 OCaml 变成人人喊打的东西

说起来，我之前用 PHP 重新实现了一个系统，结果发现 PHP 的实现比原来的 C 语言实现快了 50 倍。经过 C 语言的那个小组对算法多次的优化，PHP 的版本还是快好几倍。（转移话题

我看 flipboard 那个文章的意思就是他主要是为了性能做的

这个问题我觉得可以换一个角度看

根据我的观察，UI 库（指广义的 UI 库，不是前端一亩三分地里面的那几个）按照其绘制界面的方式可以分为两个流派
一个是用更高（或不同）的抽象包装平台提供的 GUI 相关的 API 和控件，比如 Windows 平台的原生 API 是 Win32，微软就有 MFC、WinForms 等一堆库来做这个包装，Borland 的 VCL 应该也算（没记错的话应该是）。这种做的比较大的，跨平台的我就知道一个 wxWidget。还有 SwiftUI，按照 Apple 的说法（ SwiftUI 使用了 UIKit/AppKit ）。
SwiftUI 是属于这一类的，另外 UIKit 和 AppKit 的基本思路一样，但是确实是两套不同的 API，所以如果 SwiftUI 能实现一套代码在不同 Apple 平台上跑（这个我没了解过，我主要对框架设计思路感兴趣），那勉强也算个跨平台吧 ...
我们把这一种框架称为“老实人框架”

另一种就是我用平台原生的 API 帮我创建一个窗口，再让平台帮我在窗口里面搞一个 canvas （指代任意图形 API 的 context ），跑一个 event loop，然后就变身渣男把平台给踹飞了。窗口里面的控件则完全由 UI 库自己模拟出来。这种做的比较有名的，远有微软的 WPF ——虽然只能在一个平台上面跑，但是还是自己把 Ｗ in32 控件重新做了一遍 ... 然后到死都还有性能问题，近有 Flutter （ Flutter 用的应该是 Skia，Chrome 的 UI 应该也是这么画的，所以 Chrome 也 ...）
实际上 Qt、GTK、Swing、JavaFX 都是这种方式，几乎所有的游戏也是这种方式（ Apple 甚至默认了游戏可以随便折腾不用管他那一套理论）
我们把这一种框架称为“渣男框架”

现在我们来证明“老实人框架”和“渣男框架”是可以无限互相嵌套的 ...

说到平台，这里的平台 API，在 Windows 指的是 Win32 那一套（ CreateWindow 之类的），在 Mac/iOS 指的是 Cocoa/CocoaTouch，在 Android 指的是 ... 好吧就是 Android 那个 ... 我也不知道叫什么，可能谷歌起名部需要努把力了
Linux 不存在（至少是不存在唯一的）平台原生 GUI API，非要说的话 libX11 算一个？好吧这个还是以你用 X 为前提的 ...

这里有意思的是，如果你把 GTK 看成“ Linux 原生 API ”的话（毕竟 GTK 在其他平台使用的很少），那 GTK 就可以被归类为“老实人框架”了 ... 其实还是有一点区别的，因为这种情况下你就是在直接调原生 API，而没有在用额外的 UI 框架 ... 所以应该说是 gtkmm 属于“老实人框架” ... 不过 anyway，这里的启发是，Cocoa 和 Android 这些框架在 UI 方面的内部实现实际上可能和“渣男框架”区别并不大，只是人为原因（官方钦定硬点）把它放到了“平台原生”这一层里面

有了上面的思考，现在我们就把 Android API 本身当成一个“第三方 UI 框架”，然后你写了个 Flutter 程序跑在 Android 上面，这就相当于你在一个“渣男框架”里面嵌套了另一个“渣男框架”
你写了个 React Native 程序跑在 Android 上面，React Native 是创建 native 控件的，因此属于“老实人框架”，这个相当于你在“渣男框架”里面嵌套了一个“老实人框架”

回到楼主的问题，首先 Web 这个东西可以被认为是一个拙劣的“渣男框架”
这个和计算机中另外一个规律，“ Greenspun ’ 10th rule ” 是异曲同工的：“任何 C 或 Fortran 程序复杂到一定程度之后，都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是 bug 的、运行速度很慢的 Common Lisp 实现。”
做过前端应该明白为什么 Web 可以被称为“拙劣的‘渣男框架’” ...

DOM+CSS 可以被看作是 Web Native API，从这个角度讲，Angular/React/Vue 这些可以被视为建构于 Web 之上的“老实人框架”

然后你在 Android 上面跑的 React Native 程序里面嵌套了一个 WebView，里面放了一个 React 应用，现在你在：
一个渣男框架里面 （ Android API ）
嵌套了一个老实人框架 （ React Native ）
里面又嵌套了一个渣男框架 （ Web ）
里面又嵌套了一个老实人框架 （ React ）

有没有一点 “ Java 应用调用栈”（ https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png ）的意思？

楼主的意思就是，我能不能在一个“渣男框架”里面再嵌套一个“渣男框架”，理论上显然是可以的，你甚至可以继续嵌套 ...
至于实际有多大意义，那就是另一个话题了

“这两天有心再阅读，网上搜索相当困难，若干已经消失” 等等他也删文章的么？不会是跟某中文博主学的吧

OCaml 的编译器实现确实很高效，不过这个“高效”更适合用来指代该编译器本身，而不是编译器生成的代码。这么说把，OCaml 的编译器的**编译速度**，和 C++/Haskell 的编译器相比是两个极端

不过鉴于 OCaml 的编译器是 OCaml 写的，所以你说 OCaml 运行时性能高效，也还凑合，不过和 C/C++ 比性能上限还是算了吧

个人见解，OCaml 编译器本身能做的如此高效，一个重要原因是坚持了四项，啊不四字基本原则，即 KISS。另外 OCaml 编译器对所生成代码进行的优化，相比于各大 C/C++ 编译器来说是很少的，flambda 什么的也是最近才开始搞（效果貌似也没好到哪去）。对于 C/C++ 编译器来说，如果你把优化开满，编译是很耗时的

某中文博主的文章里面应该也有一部分这个意思，但是他吹过头了

我只记得这个 http://www.ffconsultancy.com/languages/ray_tracer/comparison.html
然而这个在 HN 上被喷成狗了

C/C++ 的独特优势是性能**上限**高，意思是假定使用的是未经定制的编译器，同时假定有一个水平无限高的程序员（或者有无限多只猴子在”写”同一个程序），用 C/C++ （以及其常见扩展）写的程序的运行时性能的最大值是其他语言比不上的

这个条件很值得玩味

当然汇编是个例外，不过这里即使排除汇编，以及 C/C++ 的內联汇编扩展，C/C++ （以及其常见扩展）对硬件和内存的精确控制还是可以使其在运行时性能上限这一方面把其他语言轰成渣

U 系列本来就一般啊，显示器这个东西，没比 SSD 好到哪去
UP 系列可以搞两台看看

@sorasyl 自己搜 3.96 升 itx 机箱
不一定靠谱

我这个是我自己的机箱数据库，desk mini 和 Mac mini 是放在上面做对比的，都是放不了显卡的，据我所知没有比我这个更小的

其实还有更小的 ... 我摘一段我这的数据吧

NeXTcube 305x305x305 28.38L
Power Mac G4 Cube 200x200x250 10L
Mac Pro (2013) 167 d * 251 h 5.5L (7L)
PlayStation 4 Pro 5.31L
IN WIN CHOPIN 244x84x217 4.45L
PlayStation 4 275x53x305 4.19L
我现在用的某能装显卡的 ITX 机箱 180x100x220 3.96L
AsRock DeskMini 155x155x80 1.92L (Mini-STX)
Mac Mini 200x200x36 1.44L

抱个路子广的大腿 ...

楼主标题说天猫，最后又说淘宝 不知道什么意思 ...

我一般是其他社区里面找店铺，店铺里面再找商品
极其冷门的商品就只能随缘了
不过我貌似淘宝用的比天猫多 ... 天猫价格有时候比京东还贵，水也不浅，唯一的优势就是福报教主比两分钟人品好那么一丢丢

@autoxbc 问题是从很多年前开始，就连和 iPhone 小屏一个级别的大小，在安卓机里面都几乎很难找到了
所以说这个 5.5 对于 iPhone 来说不算小，对于安卓来说确实不容易啊 ...

另外根据 spec，8 是要比 X/XS 稍微小那么一点的，20SE 要是能再小一点其实效果也还不错

本来所谓全面屏这个东西，我是以为他们会把原来手机的边框裁掉，最后能小那么几圈，没成想一群不争气的全都搞成了把屏幕放大到原来的边框 ...
不知道菊花手机的保值效果如何，这个要是真能出，过个一两年价格跳水了倒是可以考虑一下

自己家的电台听腻了可以偷偷收听敌台

不过 BBC 一些节目好像要英国 IP

@ChristopherWu 我觉得不听古典没必要用，这货比你这 6-10 RMB 每月烧钱多了
其实我发现 Spotify 也能听 King Crimson 了，然而一大半专辑已经买下来了 ...

求推荐我觉得还是得带个预算
而且既然是 hifi，基本规矩还有听音类型，前端吧

我用的 Qobuz

优点：
部分专辑有 Hi-Res 的选择（虽然我听不出来
可以买专辑，买后云端永久保存，提供各种格式下载（ Qobuz 的 Streaming 和 Download Store 貌似是分开的业务，只是你可以直接从 Streaming 的界面里面加购物车而已）（虽然论实惠应该是比不过收旧 CD 的
“可以买专辑”有一个额外好处，就是一些其他国外流媒体听不到的曲子，可以去 Download Store 里面买，然后就可以 Streaming 了，比如 King Crimson 一直对 Streaming 不太友好，Spotify 和 Tidal 都是不能听的，Qobuz 里面可以试听 30 秒买下来（然而前两个月 King Crimson 的专辑全线上架 Streaming 了 。。。
开放 API （ Tidal 官方不开放 API，Qobuz 官方态度是开放 API 的，并且在 GitHub 有维护文档，但是 key 需要申请，我发过邮件，他们问我想做什么 app。。。 我看意思大概是只有商业合作才能搞 ... 死脑筋欧洲人 ... 不过作为前前端工程师，很容易发现他们自己 WebPlayer 用的就是自己的 API，并且 Key 是明文写在 JS 里面的 ... 另外他们 Streaming 放的 flac 貌似是没有 DRM 的 ... 也就是说不要脸的话可以直接拉下来。还有现在 mpd 的 Tidal 和 Qobuz plugin 貌似都是挂掉的状态，Qobuz 被我一通乱改勉强能用了
部分专辑提供 Digital Booklet，闲的没事可以看下背景信息，比如我随便找的 http://static.qobuz.com/goodies/79/000074497.pdf 。部分专辑会有文字的背景信息和部分奖项的收录（这个做的很 primitive，我估计 Roon 会好一点）
曲子本身的元数据也更完善：每个曲子能告诉你 Composer，Conductor，Performer 都是谁，歌剧告诉你是谁唱的，流行告诉你谁写的词谁弹的吉他（这个信息可能靠不住，不过古典一般都分的清楚）


缺点：（简单来说，除了上面这些优点，基本全是槽点
貌似要稍微贵一点（英镑结算
曲库太受限，我主要听欧美系的还凑合，但是华语之类的就只能去 Spotify。曲库组织的也挺奇葩的，经常看见两张一样的专辑 ...
欧洲线路太慢 ... 太慢 ... 梯子质量不好的话，放个歌缓冲个五秒十秒，半路中断个三两下是正常现象（我在 PC 听 CD 和在手机听 320k 都有这毛病）
从 REST API 看这公司还是有基本的技术能力的，但是 App 做的一般，设计也就勉强能看（尼玛 Loading 的时候那个转圈的 Logo 圆心居然是歪的 ... 歪的 ...），总之流媒体要想享受互联网的技术水平就老实 Spotify 吧 ... 我已经有自己折腾个客户端的计划了

来举个哭笑不得的例子，上面说 Qobuz 有个吼处，就是对古典音乐“优化”得吼，其中的一个体现是专辑里面曲子的安排： https://imgur.com/gallery/1TZ4glR
他是把作品名和各乐章分开显示的，这避免了其他播放器（一般针对其他类型音乐设计）的一个通病，就是把古典曲子音轨全名作为标题，然后在手机上播放的时候就给 truncate 成了屏幕宽度，然后不紧不慢的滚啊滚 ... 滚了十秒钟你才知道这一轨是啥曲子 ... 要是一个不注意错过了你还得再等他滚十秒钟
然而 ... 这个作品名称，对就是红圈里面的那个，在几个月前是不会在手机上显示的 ... 也就是手机上就只能看见乐章的标题 ... 这更蛋疼，因为这样你压根不可能知道现在放的是啥曲子
此外从这个截图也可以推断出 iPad 的 app 就是 iPhone app 的简单放大，你看上面的专辑名，那个还在滚啊滚 ... while 周围有一大片的空白啥都没有
真是太不上心了 ...