https://www.smashingmagazine.com/2022/05/you-dont-need-ui-framework/
这篇文章写的不错。很多人选择使用UI Framework主要是三大原因：
- 更专业的设计
- 快速搭建
- 预制的组件（Modal、Tooltip等），能更好的处理A11y的问题。
针对更专业的设计：设计不仅包含组件本身，还包含如何使用组件。组件库并不能解决这件事。而你想要用好组件库（比如Material UI），需要先深入理解这个组件库。而如果你能深入理解、用好某个组件库，那已经具备了一定的设计能力。
针对快速搭建：组件库确实可以快速搭建，但当你想要定制化时，需要的时间会显著提升。
预制组件A11y更好：组件库并不会把A11y作为首要考量。如果想要更好的A11y，最好选择没有样式、专做A11y的组件库。比如 https://headlessui.dev/ https://react-spectrum.adobe.com/react-aria/ 等等。
这篇文章写的不错。很多人选择使用UI Framework主要是三大原因：
- 更专业的设计
- 快速搭建
- 预制的组件（Modal、Tooltip等），能更好的处理A11y的问题。
针对更专业的设计：设计不仅包含组件本身，还包含如何使用组件。组件库并不能解决这件事。而你想要用好组件库（比如Material UI），需要先深入理解这个组件库。而如果你能深入理解、用好某个组件库，那已经具备了一定的设计能力。
针对快速搭建：组件库确实可以快速搭建，但当你想要定制化时，需要的时间会显著提升。
预制组件A11y更好：组件库并不会把A11y作为首要考量。如果想要更好的A11y，最好选择没有样式、专做A11y的组件库。比如 https://headlessui.dev/ https://react-spectrum.adobe.com/react-aria/ 等等。
Smashing Magazine
You Don’t Need A UI Framework — Smashing Magazine
Developers often reach for UI frameworks like Bootstrap or Material UI, hoping that they’ll save a bunch of time and quickly build a professional-looking app. Unfortunately, things rarely work out this way. In this article, Josh Comeau is going to make his…
👍4
我不是"羊" 请以我的名字呼唤我
去人格化的过程也是"差异识别"的过程，这些包含偏见的语言自然地区分着"他我"甚至"敌我"
这些词汇以其背后所蕴含的社会情境
“遮蔽了这些人群所遇到的困难”，“当你在使用这样语言时，就意味着你无法感同身受和你同样的人群所遭遇的…而且你可能就成为了现行的一些不合理措施共同的执行者”。
去人格化的过程也是"差异识别"的过程，这些包含偏见的语言自然地区分着"他我"甚至"敌我"
这些词汇以其背后所蕴含的社会情境
“遮蔽了这些人群所遇到的困难”，“当你在使用这样语言时，就意味着你无法感同身受和你同样的人群所遭遇的…而且你可能就成为了现行的一些不合理措施共同的执行者”。
👍14
https://browser.kagi.com/
Kagi团队做的浏览器Orion。
相较于其它浏览器，它的思路挺有意思：
- 是Native App，而不是基于electron构建
- 基于WebKit（和Safari一样）
- 支持Keychain和LiveText
- 同时又支持Firefox/Chrome的扩展
- 跨设备。macOS/iPadOS/iOS 同时在多设备之间同步标签等数据
- 速度快、省内存。适合性能一般的电脑。
- 内置广告屏蔽，使其性能要比Chrome + uBlock后置效果更好。类似于Brave的实现原理。
Kagi团队做的浏览器Orion。
相较于其它浏览器，它的思路挺有意思：
- 是Native App，而不是基于electron构建
- 基于WebKit（和Safari一样）
- 支持Keychain和LiveText
- 同时又支持Firefox/Chrome的扩展
- 跨设备。macOS/iPadOS/iOS 同时在多设备之间同步标签等数据
- 速度快、省内存。适合性能一般的电脑。
- 内置广告屏蔽，使其性能要比Chrome + uBlock后置效果更好。类似于Brave的实现原理。
👍5
https://basicpitch.spotify.com/
https://github.com/spotify/basic-pitch
Spotify开源的一个自动将音乐转成MIDI的工具。
对技术细节感兴趣的可以阅读论文： 《A Lightweight Instrument-Agnostic Model for Polyphonic Note Transcription and Multipitch Estimation》
和博客：https://engineering.atspotify.com/2022/06/meet-basic-pitch/
https://github.com/spotify/basic-pitch
Spotify开源的一个自动将音乐转成MIDI的工具。
对技术细节感兴趣的可以阅读论文： 《A Lightweight Instrument-Agnostic Model for Polyphonic Note Transcription and Multipitch Estimation》
和博客：https://engineering.atspotify.com/2022/06/meet-basic-pitch/
GitHub
GitHub - spotify/basic-pitch: A lightweight yet powerful audio-to-MIDI converter with pitch bend detection
A lightweight yet powerful audio-to-MIDI converter with pitch bend detection - spotify/basic-pitch
https://liveblocks.io/
最近几年这种较小型的SaaS产品越来越多，它们的开发者体验都非常好。
- 不到一小时，就可以让应用支持多人协作。
- 官网做得不错。提供相对够用但非常直观的的Dashboard。
- 对于个人开发者和小型项目，Free Plan就够用。
- 专注于解决一个领域的问题
- 很多都提供开源自部署方案
开发者可以把这些SaaS服务像LEGO一样堆起来使用。再辅以Serverless之类的方案，几乎不需要有后端服务器了，让成本大幅度下降。
其它类似产品：
- Vercel：现在也算不上”小型“了。但是开发者体验依然极好
- PlantScale: Database
- Upstash: Redis & Kafka
- Supabase: Firebase替代品
- Plausible: Google Analytics
- Pipedream: 对接各个其他产品的API。有点像Zapier的可编程版
- Pusher: pub/sub
我个人非常看好海外的小型SaaS产品，专注一个领域做到极致。持续不看好国内的SaaS产品。
有其他的类似产品也可以直接评论推荐给我~
最近几年这种较小型的SaaS产品越来越多，它们的开发者体验都非常好。
- 不到一小时，就可以让应用支持多人协作。
- 官网做得不错。提供相对够用但非常直观的的Dashboard。
- 对于个人开发者和小型项目，Free Plan就够用。
- 专注于解决一个领域的问题
- 很多都提供开源自部署方案
开发者可以把这些SaaS服务像LEGO一样堆起来使用。再辅以Serverless之类的方案，几乎不需要有后端服务器了，让成本大幅度下降。
其它类似产品：
- Vercel：现在也算不上”小型“了。但是开发者体验依然极好
- PlantScale: Database
- Upstash: Redis & Kafka
- Supabase: Firebase替代品
- Plausible: Google Analytics
- Pipedream: 对接各个其他产品的API。有点像Zapier的可编程版
- Pusher: pub/sub
我个人非常看好海外的小型SaaS产品，专注一个领域做到极致。持续不看好国内的SaaS产品。
有其他的类似产品也可以直接评论推荐给我~
liveblocks.io
Liveblocks | Ready-made collaboration for your product
Liveblocks gives you the building blocks and infrastructure to enable people and AI to work together inside your app.
👍15❤1
https://tauri.studio/
类似Electron，使用Web开发桌面端。
和Electron最大的区别是（具体的见图，来自Tauri官方Repo）：
Electron由 Chromium + Node.js + 定制和扩展组成。
而Tauri则是 系统WebView + Rust组成。
这样Tauri相较于Electron会有几个好处：
1. 安装包会更小。因为Electron包体积那么大，绝大部分都是Chromium和Node带来的。而Tauri的WebView是系统的，本身是Rust写的。
2. 应用启动速度会快很多。
3. 由于MainProcess是由Rust开发，意味着应用可以更加轻松地和系统交互，和一些native lib交互。比如FFmpeg、SDL2之类的多媒体库。而Electron只能通过Node.js Addon实现，不仅效率低，而且开发比较痛苦（虽然可以用neon这种Rust binding）。
4. 需要的话，也许可以让Rust渲染一些native window（待验证），而这个Native Window的性能就和原生程序可能是一致的。
优点1和优点2，使得用Tauri开发小工具变得容易了许多。比如Launcher（已经有一些Launcher是由Electron开发的）。
优点3，使得Tauri更容易开发后台任务非常重、或者和系统UI交互比较频繁的应用。比如截图、录屏工具，直播工具（Streamlabs是Electron + OBS），音视频处理工具等等。
当然它也有缺点
1. Main Process需要用Rust开发，这是一个很高的门槛。
2. 默认情况下，Windows下是Edge WebView2，macOS下是WKWebView，Linux下是webkitgtk。我个人觉得这是最大的缺点。假设这个应用需要运行WebGL/WebGPU/WebAudio等目前各个浏览器不统一的API，那Electron就是唯一选择。我还没找到Tauri跨平台统一WebView的办法。
类似Electron，使用Web开发桌面端。
和Electron最大的区别是（具体的见图，来自Tauri官方Repo）：
Electron由 Chromium + Node.js + 定制和扩展组成。
而Tauri则是 系统WebView + Rust组成。
这样Tauri相较于Electron会有几个好处：
1. 安装包会更小。因为Electron包体积那么大，绝大部分都是Chromium和Node带来的。而Tauri的WebView是系统的，本身是Rust写的。
2. 应用启动速度会快很多。
3. 由于MainProcess是由Rust开发，意味着应用可以更加轻松地和系统交互，和一些native lib交互。比如FFmpeg、SDL2之类的多媒体库。而Electron只能通过Node.js Addon实现，不仅效率低，而且开发比较痛苦（虽然可以用neon这种Rust binding）。
4. 需要的话，也许可以让Rust渲染一些native window（待验证），而这个Native Window的性能就和原生程序可能是一致的。
优点1和优点2，使得用Tauri开发小工具变得容易了许多。比如Launcher（已经有一些Launcher是由Electron开发的）。
优点3，使得Tauri更容易开发后台任务非常重、或者和系统UI交互比较频繁的应用。比如截图、录屏工具，直播工具（Streamlabs是Electron + OBS），音视频处理工具等等。
当然它也有缺点
1. Main Process需要用Rust开发，这是一个很高的门槛。
2. 默认情况下，Windows下是Edge WebView2，macOS下是WKWebView，Linux下是webkitgtk。我个人觉得这是最大的缺点。假设这个应用需要运行WebGL/WebGPU/WebAudio等目前各个浏览器不统一的API，那Electron就是唯一选择。我还没找到Tauri跨平台统一WebView的办法。
👍11
image_2022-06-21_18-52-41.png
227.4 KB
https://quic.ulfheim.net/
《The Illustrated QUIC Connection: Every byte explained and reproduced》
解释了QUIC建立连接的每一步、每一个字节
《The Illustrated QUIC Connection: Every byte explained and reproduced》
解释了QUIC建立连接的每一步、每一个字节
👍6