#技术选型

1天前

问：n8n和Dify哪个好？

#n8n #Dify #对比 #技术选型 #工作流

1天前

前几天开会聊独立开发有同学问我为什么选择 react 而不是 vue 我之于这两个框架都是新手哪怕是现在我也可以随时切换，毕竟懂得不多，投入不多我选择 react 原因如下： - next.js : next.js + supabase 是新时代的技术栈 - react native: 感觉总有一天我会去写 app，react native 是一个非常好的选择 - 个人趣味：我觉得 react 更有趣一些

#独立开发 #React #Vue #技术选型 #Next.js

2天前

vibe 越久越怀念 vue 我建议零基础 Vibe Coding 的，直接选 Vue 原因很简单： React 那套开发、生产不一致问题谁不晕：本地好好的，线上挂了，本地有问题，线上就可以 react 性能优化也很跨，一点不友好，memo、useMemo、useCallback...... 我已经在这浪费了好多时间如果不是我的技术合伙人是 React 技术栈，才不用 React 呢

#Vue #React #前端开发 #技术选型 #吐槽

3周前

今天读了一篇文章《Microservices Are Quietly Dying — And It’s Beautiful》想起我还在公司的时候，言必称微服务，面向简历编程这也是一个必须，别问，问你就是单体不能扩展，现在好像没人提了，不根据自己的需求就用微服务确实是可笑的，不知道各位有公司改回单体的吗？文中就说：团队为初创公司拆分了47个微服务，目标是“像Netflix/Uber一样规模化到百万用户”，却从未突破百万用户，反而每月烧掉2.3万美元AWS账单、遭遇14小时宕机。最终醒悟：“我们不是在建产品，而是在建一座分布式自我纪念碑。” 他们公司恐怖的架构： * 47个服务散布12个GitHub仓库 * 部署流水线像地铁图，架构图需4K屏 * 复杂性扼杀生产力

#微服务 #单体架构 #技术选型 #架构复杂性 #反思

3周前

软件的错误处理有不同的方式。 Java、JavaScript 和 Python 是抛出异常，C 语言和 Go 语言是返回一个错误值。我一直想知道，哪种方式更好？前不久，我读到一篇多年前的文章，明确提出抛出异常好于返回状态码。他的理由很有说服力，文章好像还没有中译，我就翻译出来了。

#编程 #错误处理 #异常 #状态码 #技术选型

鹿 𝕟𝕠𝕜𝕚𝕟𝕠𝕜𝕚 祥子

3周前

所以跨平台 UI 大家只讨论 Electron 和 Tauri 有时候说一下 Flutter 和 RN 真的没有人看 Qt 了么😭

#跨平台UI #Electron #Tauri #Flutter #RN #Qt #技术选型 #前端开发

3周前

程序员已经变成了技术词典，需要向 AI 输入合适的技术词汇（包括架构、技术栈、技术选型）等等，然后由 AI 拼接这些词汇变成最终的产品。

#程序员 #AI #技术词汇 #技术选型 #自动化

1个月前

看了一个按钮数量只有个位数的竞品，然而引用的库却很夸张，光 JSON 解析就嵌了三个 frameworks

#竞品分析 #JSON解析 #过度设计 #技术选型 #负面

1个月前

有些道理看似简单，却常常因为我们未曾深入体验或换位思考而难以真正理解。最近在实践中，我有了几点真切的感悟，或许能给我们一些启发：首先，以技术视角看问题时，要明白表象之下往往有更深层的价值。比如我们常讨论的一些技术平台，像Solana，很多人一开始可能会把它简单看作一个高性能的数据库，觉得实现相应的接口和API并不复杂。但实际上，当它被广泛应用于金融场景时，其核心价值远不止于此。它真正解决的是“信任”这个根本问题：通过技术手段确保每一笔交易100%可靠，并且从源头上杜绝了像程序员通过代码凭空生成大量虚拟资产这类滥用行为。这就像在数字世界里建立了一个值得信赖的“账本”，让人们能够放心地进行价值交换。其次，在评估新技术框架时，不能只看表面的性能参数。最近尝试使用HonoJs这个新兴框架，它在速度和成本控制上确实表现出色。但在实际压力测试中，当我们用100个并发用户发起10万次请求时，却出现了约60次莫名的错误。这让我意识到，对于金融交易、线下商超系统、地图服务、自动驾驶数据传输、物流调度以及支付系统等对稳定性和可靠性有极高要求的场景，这样的框架可能还无法胜任。因为在这些场景中，哪怕是一次数据传输的失误，都可能导致巨大的经济损失，甚至影响到实体与虚拟资产的正确流转——多一个零少一个零，或者数据出现偏差，都绝非小事。当然，它或许更适合内容管理系统（CMS）、客户关系管理（CRM）、企业资源规划（ERP）、博客平台、视频直播、图文社交社区、即时通讯以及生成式AI应用等对实时性和成本更敏感，但对极端可靠性要求稍低的场景。再者，编程的本质是为了提升效率、降低成本，但这并不意味着技术要从一开始就追求复杂。当业务规模较小时，大家没有形成统一的行动模式，一个简单的Excel表格，或许就能清晰地管理所有事务，满足需求。但随着业务的扩张，角色的增多，以及用户行为的复杂化，我们就需要通过明确角色定义、梳理用户行为分类、制定标准化操作流程（SOP）等方式，让整个系统高效运转，这才是编程真正发挥价值的“大后期”。最后，关于“耐心”，我理解它并非消极等待，而是一种积极的“从容”。这意味着我们要踏踏实实地做好眼前的每一件事，专注于日常的积累和成长，少一些患得患失的焦虑，也不必总去过度担忧未来的结果。与其在空想中消耗精力，不如一步一个脚印，用行动去积累力量。就像种树，耐心等待的不是什么都不做，而是默默耕耘，等待它自然生长。这些感悟或许朴素，但在实践中却能让我们更清晰地看到事物的本质，找到更适合的路径。无论是技术选择、业务规划，还是个人成长，保持这种务实而深刻的思考，总能让我们走得更稳、更远。

#技术选型 #Solana #HonoJs #效率提升 #耐心

1个月前

最近在做一个模板商城/创作者平台的 MVP：预期要支持投稿、审核、付费下载、分成提现。技术上想走 MedusaJS + Mercur（多商家）+ Stripe Connect + S3，前端 Next，后面接 SSO & 搜索。有做过类似闭环的小伙伴吗？有没有更好的选型？或者这一块经验的小伙伴，可付费咨询，头大😭 #技术选型

#模板商城 #创作者平台 #技术选型 #MedusaJS #付费咨询

象牙山刘能

1个月前

初学者找到大师请教跨平台 App。初学者：我现在考虑两种选择，第一是用 Tauri，它的优点是轻量级，支持所有主流平台…… 大师：第二个。必须选第二个。

#跨平台App #技术选型 #Tauri #大师建议 #简洁

2个月前

最近又看到前端组件库之争，我想说小孩子才做选择，我全都要。目前在 #Noi 项目中，shadcn/ui 与 antd 共存，但侧重点有所不同： - shadcn 适合轻量级 UI 交互，美观大方（源码本地化适合高度自定义） - antd 适合复杂逻辑交互，中规中矩（如设置界面，就需要强大的表格表单处理。功能第一，美观其次）

#前端组件库 #shadcn/ui #antd #UI交互 #技术选型

2个月前

刚聊一哥们，他说他们用 rust/nodejs 不是不可以只是国内搭建系统还是 Java 好点好招人

#Rust #Nodejs #JAVA #国内系统 #技术选型

2个月前

原来我对dotnet 的认知这么落后，国内有多少团队选择 .net core 作为核心技术栈的呢

#dotnet #.NET Core #技术选型 #国内团队 #认知落后

3个月前

数据库付费还是自建呢😠，付费neon如何？

#数据库 #付费 #自建 #Neon #技术选型

砍砍@标准件厂长

3个月前

更新一下我对语言模型各个方面技术选型的表格，供参考。

#语言模型 #技术选型 #参考

3个月前

睡觉了，也许两个月后我会写出我的第一个Windows桌面软件技术选型PySide6

#PySide6 #Windows桌面软件 #技术选型 #编程 #期待

4个月前

Generalist Engineer 即全栈思维 + 跨域技能 + 系统视角 + 快速学习能力的工程师。不等于「什么都会一点」的半吊子，而是一种宽而不浅、深度够用、具备整合与落地能力的技术型人才。在现实中：可以快速理解不同技术栈，前端、后端、数据库、DevOps、AI、API集成等；面对一个新需求，能独立端到端把 80% 的系统做出来；知道怎么做技术选型，权衡成本、交付、性能、可维护性；懂产品逻辑、用户需求、业务上下游，而不仅仅是技术本身；遇到新问题，能快速学习新框架、新工具，解决实际问题。有点像早期创业公司里的 “one-man army”（一人军团）。

#全栈工程师 #跨域技能 #系统视角 #快速学习 #整合能力 #落地能力 #技术栈 #前端开发 #后端开发 #数据库 #DevOps #人工智能 #API集成 #技术选型 #成本权衡 #交付能力 #性能优化 #可维护性

在悉尼和稀泥

9个月前

有了 AI，国内 35+ 的大龄程序员，应该翻身了吧？项目经验，系统架构经验，团队协作经验，技术选型，产品感觉等等，配合 AI。已经不需要和年轻人比 996 了才是。

#AI #程序员 #大龄职场 #项目经验 #团队协作 #技术选型