HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    编程与软件工程about.gitlab.com

    GitLab 如何用 Vue:一年之后

    How we do Vue at GitLab: one year later

    2次上首页
    2年跨度
    694累计得分
    353条评论

    2017 — 2019,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    GitLab 工程师回顾团队采用 Vue 一年后的经验:他们分享了单文件组件、Vuex 状态管理、与 jQuery 混用的取舍等实践心得,并总结了 Vue 在大型团队协作中的优势与坑。文章发布后多次登上 HN,成为前端框架选型的经典参考。

    为什么经久不衰:它来自真实大型开源项目的一线实践而非布道文,多年后仍是讨论 Vue 与 React 选型时被反复引用的案例。

    关键词 VueGitLab前端框架选型React对比

    HN 评论精选

    单文件组件、官方统一生态和从 Angular 1 迁移的平滑性是他们选 Vue 的关键原因

    我们上次重写大型前端应用前对比了 Vue 和 React,用两者各做了 POC,最终选了 Vue,主要因为:单文件组件是 Vue 最好的特性,让我们想避免 CSS-IN-JS 的设计师(只会 HTML/CSS、JS 是新手)也能和我们一起并行迭代;Vue 对大多数事情有官方推荐做法,Vuex 和 Vue-Router 由核心团队维护,而 React 的选择太多常让新手不知所措——搜 'React CSS style' 出来一堆都有效但要翻好几个才能找到想要的,搜 'Vue CSS style' 前几条全是官方文档;此外团队原本写 Angular 1,转 Vue 也比转 React 更顺。

    gt5050查看英文原文

    At my last job we did a comparison between Vue and React before rewriting a major frontend application. We did a POC in both React/Vue and ended up using Vue mainly due to the following reasons: Single File Components Single file components (.vue files) is the best thing about Vue. I understand this might be a personal preference, but we wanted to avoid CSS-IN-JS. Our designer could churn out neat html/css, but was a beginner in Javascript. With Vue's single file components, he could also hack parallely with us while iterating on html/css. Standard / Official way of doing things This again is a personal preference but Vuejs comes with a recommended way to do a majority of things. Vuex(state management) and Vue-Router are provided/maintained by same Vue core team. React at times can be overwhelming for beginnners, just because of the amount of choice available Example: Google Search for 'React CSS style' [https://www.google.co.in/search?q=react+css+style] points to a bunch of links all of which link to valid solutions, but I have to go through a few of them before I get what I am looking for. Similar search for 'Vue CSS style' [https://www.google.co.in/search?q=vue+css+style] all top links lead to official documenation on vuejs.org. Excellent documentation Also, as a team we were primarily writing Angular 1 when we decided to choose a frontend framework for newer projects. I feel this also made our transition to Vue easier vis a vis React

    担心 Vue 生态复杂化后会重蹈 React+Redux 让新手学习曲线陡增的覆辙

    「中大功能用 Vuex,小功能可以不用」——我感觉 Vue 开始走上 React 的老路了。React 本来一直是个很简单的库,直到大家发现要靠各种花活才能管理复杂应用:Redux 出来后人人爱上它,React+Redux 成了官方标配,结果造成 React 学习曲线陡峭的印象,因为新人是在没学 React 的情况下直接学 React+Redux。不知道 Vue 能做什么来避免同样的坑。

    ng12查看英文原文

    > We discovered that VueX makes our lives easier. If you are writing a medium to large feature, use VueX. If it's a tiny feature, you might get away without it. I feel like this is Vue starting to get the React treatment. React was (and still is!) a very simple library until people realized they needed to do fancy things to make complex applications manageable. Redux came out, everyone fell in love with it, and React+Redux became an official couple. This lead to the perception that React has a steep learning curve because new developers were learning React+Redux without learning React first. I wonder what Vue can do to avoid the same pitfall.

    在 Vue 中混用 jQuery 是代码坏味道,正确做法是学会用 Vue 本身解决问题

    我强烈反对在 Vue 里用 jQuery 是可以的这种说法。当然多数时候只是查询 DOM 不会出问题,但它永远不应该是必要的,用 jQuery 对我来说是代码坏味道,说明这段代码没在正确使用 Vue。让开发者多花时间学会用 Vue 而不是 jQuery 来解决问题,长期看更有价值。(更正:GitLab 的结论和我一致——他们研究发现两者混用不是好主意,总会有更好的方案,如果你发现自己在 Vue 架构里需要查询 DOM,那说明你哪里做错了。)

    lucisferre查看英文原文

    I would strongly disagree that it is ok to use jQuery with Vue. I mean sure, it's ok in that most of the time it isn't going to hurt or break anything, at least if you are just using it to query elements from the DOM. However, I would argue that is not ok in that it should never be necessary and it's use would be a code smell to me and indicate that the code in question is likely not using Vue properly. I suspect it would be more valuable in the long term to ask people to take more time and learn to use Vue instead of jQuery to solve the problem at hand. Edit: I should note that Gitlab came to the same conclusion and I misread their comments on it as accepting the argument that it would be ok for querying the DOM. What the article says: > At first I had several discussions about using jQuery with Vue. Some had said it might be OK, but only in read-only (querying) situations. However, after doing the research, we found that it is not a good idea to use jQuery with Vue. There will always be a better solution. We found that if you ever find yourself needing to query to DOM within a Vue architecture, then you are doing something wrong. This I completely agree with.

    Vue 以易上手换取了可维护性,存在全局状态泛滥、缺受控组件、语法不便等结构性问题

    我用 React、Angular、JSP、Rails、Django 多年后转用 Vue 几个月了。虽然很多人(尤其在 HN)对它印象深刻,但我觉得它很欠缺:上手容易、学习曲线平缓,但代价是稳定性、简洁性和可维护性。主要问题:全局状态太多——Vue 实例成了新的 window,是全局注册表,插件、指令、过滤器都往里塞,虽然可以不用,但所有库都这么用,你很难避免;缺少受控组件——比如要做一个拒绝某些字符的输入框,React 可以直接不更新渲染值,Vue 只能靠监听 keypress 事件变通,而且这种模糊性弥漫在整个生态;组件定义语法(data/props/methods/computed/hooks)是写类的一种很别扭的方式(Vue 3 才原生支持);写过 JSX 后回到模板语法体验不佳,对 IDE 支持也差。

    Illniyar查看英文原文

    I've been working with Vue for a few months now, after several years with React, angular, JSP, rails and django (and of course jquery). I know a lot of people, especially in HN, are impressed by it but I found it very lacking. It makes things easy to write at first and with very little learning curve but trades that ease of use for stability, simplicity and maintainability. The main problems, to me, are: * too much global state - the Vue object is the new window,a global registry, you add custom elements,filters,directives,plugins and even just utility methods. You can of course opt not to use it, but since all the libraries use it and it's the canonical way, you'd be hard pressed to. * lack of controlled components - unlike react there are no controlled components. For example if you are trying to make an input that doesn't accept certain characters, in vue you'll need to handle keypress events to make sure the value doesn't change, while in react you can simply not update the rendered value. This can be worked around of course, but the fact that vue doesn't have a clear definition of it permeates throughout the ecosystem. * component definition syntax - the syntax for definition a component with it's data,props,methods,computed,hooks is a very inconvenient way of writing classes (which vue 3 is going to support natively finally) * template syntax - after doing JSX, going back to template syntax is not the greatest experience. It doesn't work as well with IDEs, you have to spin circles to do things that can be a one liner in javascript and it prevents doing any form of reuse and structure unless it's by splitting it to more components (I.E. no way to use just functions or internal methods). Of course vue prides itself for the fact that you can choose to do things a different way - use JSX instead of template Syntax, don't use the global vue registry, etc... But that's really in theory, it's like React can be used without JSX, it's technically true, but it's extremely hard not to and the ecosystem won't work well. As to VueX, for me it takes the verbosity, single global object and dependence on strings for differentiation from redux and leaves out the immutability and reducer syntax. It takes the publish/subscribe technique from ReactiveX or mobX but leaves out the ability to combine, manipulate, stream and the general reusability that those frameworks provide. It is almost a comical selection of the worst features of both without any of the benefits.

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。