TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Developers Rail Against JavaScript 'Merchants of Complexity'

13 点作者 unclebucknasty9 个月前

4 条评论

cjs_ac9 个月前
I work in the Python ecosystem, and I see the same problems here as in JavaScript. The problem, as I see it, is moving fast and breaking things. I appreciate that it's very fashionable, and that the people making these libraries and frameworks are much cleverer than me and are building these things out of very elegant ideas that I don't understand, but building things on moving foundations is more trouble than it's worth.
评论 #41390666 未加载
d139 个月前
There’s a simpler solution that allows you to leverage the <i>simplicty</i> of good modern tools without suffocating in dependency hell:<p>Ban ‘npm install’<p>It’s nothing more than a party drug.<p>Just copy&#x2F;paste any helper code you need into your ‘libs’ folder and be done with it. Your app will still run in 2044.
tnomey9 个月前
As I’ve gained more experience I feel like this advice is just “edgy” and no real engineer would willingly pick a solution that might not scale if things pick up. HTML and JQuery starts nice but add enough complexity and tell me you didn’t just hand roll your own framework. Now you’ll need documentation in order to onboard anyone if you are lucky enough to be in a position to expand.<p>The shiny new framework can create a static site and a true web app and is likely well documented with examples. The tradeoff is a subset of users have longer load times.
评论 #41396458 未加载
评论 #41391170 未加载
评论 #41391021 未加载
mablopoule9 个月前
&gt; “The merchants of complexity will try to convince you that you can’t do anything yourself these days,” wrote David Heinemeier Hansson (DHH), the creator of Ruby on Rails. “You can’t do auth, you can’t do scale, you can’t run a database, you can’t connect a computer to the internet. You’re a helpless peon who should just buy their wares. No. Reject.”<p>Such a beautiful quote, and really describe well my experience. For the past few months I&#x27;ve been in a team that keeps trying to pull dependencies and library of components for the simplest of things, and trying to argue my point kinda in vain, to the point that I&#x27;m starting to get cranky and rant-y about the subject[1].<p>Need a header on top of our application? Let&#x27;s use a Angular Material component, why would you code it yourself? Need to display stuff in a grid, oh we better should center our project around Ionic so we can use ion-grid.<p>More than &#x27;merchant of complexity&#x27;, I thing that a huge culprit is the need for content marketing, and so any new thing in a framework become the theme of multiple conference, and the obligatory Medium posts explaining the new stuff (in itself, not necessarily a bad thing), but which often tend to snowball into &quot;Method X is obsolete, why you should all port your code using newfangled method Y&quot;.<p>And now, I have a colleague working in an Angular app that keeps on rewriting stuff and wrap everything with signals. Signals can be good sometime, I&#x27;m not against angular signals in itself, but he&#x27;s just taking dead-simple code and making it more complicated because apparently now everything Angular should be about signal. At least I&#x27;m away from the part of the React ecosystem that keeps trying to re-invent the cascading part of CSS but with Typescript in the mix. <i>shudders</i>.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40476275">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40476275</a>