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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

The other kind of JavaScript fatigue

21 点作者 innerspirit大约 9 年前

4 条评论

Chris_Newton大约 9 年前
Yes, this is a real problem.<p>The solution, as I see it, is to teach less experienced developers about why old school ideas like standardisation and curation and longevity and compatibility are important in the first place. We should be sharing knowledge about the sound programming fundamentals and good practices that we’ve spent half a century and change learning. This is particularly true in fields like web development, where the low barriers to entry and potential for great success (mostly illusory, of course) attract a lot of practitioners who are relatively inexperienced and may simply have no idea how much they are missing.<p>We shouldn’t be praising those who advocate moving fast and breaking things, or auto-updating software every few days, or so-called living standards. We shouldn’t be encouraging a programming style that is one step above join-the-dots puzzles and colouring by numbers (or downloading random modules from some package repo and then asking on Stack Overflow how to make them work, as we call these games in 2016). We shouldn’t be encouraging anyone to treat an applicant’s GitHub account as their CV, and by extension both encouraging less experienced developers to pad out their GitHub with trivial reimplementations of things so they look busy and overlooking anyone who’s too busy doing real work to play the game. We shouldn’t be encouraging those who want to deprecate anything older than five minutes and expect the whole world to stop what it’s doing and update for their convenience. These are the get rich quick schemes of the software development world, the ways that a few people win big but most people just produce poorly-conceived, short-lived, low quality work that in many cases will fail soon afterwards.<p>Unfortunately, the second set of ideas there have been getting far more attention than the first lately, and it doesn’t help that some of the biggest names in the industry are some of the worst offenders. Until some high profile organisations or established thought leaders start promoting a few more old school values like building things that actually work and not penny-pinching at every possible step along the way, it’s hard to see the overall culture shifting in a more healthy direction, and the best we can do is try to do better with our own projects.
评论 #11507625 未加载
matthewtoast大约 9 年前
The &quot;other kind of fatigue&quot; mentioned is that we have an overabundance of tools&#x2F;interest in making ourselves more prolific, but a scarcity of tools&#x2F;interest in improving our code&#x27;s quality. We chase immediate productivity at the expense of longer-term survival (and happiness).<p>I agree with this sentiment, but the problem is barely tractable even at a small company working in a closed codebase.<p>The thing about those disregarded edge cases, which OP uses to exemplify the quality problem, is that there&#x27;s always an opposite edge! Your fix might be a bug for someone else. There was one particular beautiful, high-quality, generalized, and case-covering npm module, but those very facts about it made it unworkable in one past project of mine, which had strict requirements around footprint size.<p>It&#x27;s funny we use the word &quot;ecosystem&quot; to talk about this stuff. An interesting parallel is r&#x2F;K-selection in ecology, where your species either favors nurturing a small few offspring, or churning out a big swarm and hoping that a few survive. Elephants vs. lemmings.
评论 #11506220 未加载
EvanPlaice大约 9 年前
So, what&#x27;s the solution here? Other than some &#x27;hand wavey&#x27; call to action for devs to work together?<p>I am the author of a handful of OSS libs, one of which is very popular. Of the 500k+ downloads; not including repo clones, package manager installs, etc I can count the number of contributors other than myself on one hand.<p>Considering the relatively recent migration over from Google Code the number of stars it has is under 100. From the users I&#x27;ve interacted with, I would be shocked to find that even a small fraction of them understand how it works.<p>From the 4 contributors, except for one useful bugfix (that introduced another bug), their impact has been mostly insignificant.<p>At one point, one impatient dev requesting a fix forked and atrempted to assume ownership of the project. But that dev disappeared soon after and just left more work for me to clean up after.<p>So, do tell. Aside from marketing the hell out of it on blogs and referencing it on SO by answering relevant questions, where do I go to find other passionate OSS devs to help support my project.<p>It&#x27;s easy to find contributors on projects that require only general knowledge, such as building a website or creating collections of links.<p>For anything that requires even a little specialized knowledge, it&#x27;s difficult borderlining on impossible to find help.<p>I don&#x27;t need contributors with specialized knowledge. I need contributors who can provide more working examples, better documentation, and can improve the tests.
评论 #11508295 未加载
manibatra大约 9 年前
Completely agree. I have found myself more often than not trying to &quot;bet&quot; which framework I should learn next that will give me an edge. And this always leads to the fear of missing out and sometimes learning seems a chore.