不知道是人能力的问题还是前端技术栈的问题

[eGlhb2Jhb2Jhbw]

我之前是 mobile 开发。最近做过两三个 web 前端项目，当遇到一些问题的时候，去问资深的前端开发（四五个人），得到的答案基本都是“都可以”、“无所谓”、“暂时先这样”，甚至我问工程目录管理的最优实践的时候，也这样回答我。
我有点接受不了这样子的答案，我希望得到的是这么做的优点是什么，缺点是什么，之前项目遇到过什么坑，所以更推荐哪种方式。
因为遇到过太多的这样的前端开发了，所以我开始怀疑，是不是因为前端技术栈的某种特殊性，导致确实不像其他技术栈一样，能明确的说出方案的优缺点，给出一个明确的最佳实践。

[yaphets666]

目录这种东西除了某些特殊的,本来就是放在哪都可以,本来就是这样的,前端是个发展中岗位,甚至 js 这门语言都是在高速发展中.

[devwolf]

我猜……因为前端和后端精进的方向不太一样？
规范的话，
后端的很多规范，在前端来说，或者对于 js 来说是过于严格的，js 可以受用这些后端规范，但是真就没有“区别”。
我不太熟悉后端，没法子总结前端区别于后端有哪些特有的规范。

[summerLast]

个人认为是 js 之前的模块管理的概念很弱化，很多都是三方的，import export 语法也是 ES6 开始使用的，而之前前端组合大一些的项目应该也多是面向页面 而非是封装组件 组件在组合成页面 组件模块化的概念教弱，而且前端这几年变化也确实挺快的，最佳实践有的时候是和特定框架 特定版本有关的，所以不必过多纠结，先默认使用官方的脚手架，后面有了自己的领悟再去寻找最佳实践。包和组件化与模块化是将大问题分解成若干小问题人为抽象出的概念，其实还是没有跳出 目录 文件 的概念

[YoRolling]

1. 具体到某些问题的解决方案来说，前端确实有很多“都可以”的方案
2. 目录这种问题来说，也确实“都可以”，前端的“抽象”能力其实比较弱，一些组件的封装其实是个挺操蛋的事儿，就像有些老哥说的那样，复用度太少了。
3. 比如前端工程化这类的问题，很多人是不 care 的，“写代码就写代码，剩下的我不管也不想管”，这些东西首先来说没有像后端那样比较成熟通用的方案，各个公司的场景不一样，其次有些前端甚至认为上了 webpack 就是做了工程化
4. 最后也得扯到人身上，众所周知，前端的人是参差不齐的，当然后端也是，只不过前端更明显。有些人只知道该这么写，而不知道为什么。

最后说一句额外的一个事儿吧，我一朋友，也写了好几年前端了，npm scripts 抛出 error 到控制台，error 清清楚楚明明白白的，然而就是看不懂。

[wygege]

身为前端，讲一点俺的看法
我觉得浅层次的原因是，前端入行最容易，培训班转行的人最多，导致前端人员的水平层次不齐

但是我觉得根本原因是 JavaScript 本身就是动态语言，写法本身就很灵活，不存在什么固定的规范，很多开源项目或者大公司都是搞一套自己的规范，不存在什么大一统的概念。这种灵活也是前端这些年发展很快的一个原因吧。而且 js 本身也不存在一个“官方”的概念，ECMA 只是制定了一个标准，实际也是各家实现各家的

[zooeymango]

本来 js 就不是强类型语言, 写法就是可以很随便, 虽然随着模块化的发展现在有工程化的趋势, 但是总体来说很多地方就是可以“随便写”的, 要不然也不会有那么多轮子那么多框架了, 最终落实到项目的业务上, 能贴合业务、逻辑自洽, 就是好前端, 没有最佳实践之说

[horizon]

你这是群体归因错误

[horizon]

@3dwelcome 喷了，虽然前端有这样那样的问题，但你这个和舒适圈有什么关系？
拿着锤子到处找钉子

[zhaol]

追求统一规范即可，最佳实践不必强求。很多时候，这个最佳实践并不一样，一味的追求没有意义。但是你如果是想统一项目的代码规范，我觉得比较靠谱。

[encro]

作为一个后端偶尔学点前端，我鉴定是：问题没有问好。

“工程目录管理的最优实践”

每个前端框架一开始基本都定下来了，现在都是 page,state,component 那一套，不需要什么目录管理最佳实践，也没有讨论点。

所以问这个问题相当外行，小白一样，人家不想回答你是理所当然。当你问出这个问题，就将小白的标签给自己打上了----至少没用用过多个前端框架。

[3dwelcome]

@horizon "虽然前端有这样那样的问题，但你这个和舒适圈有什么关系？"

后端需要学各种语言，大部分前端都只用 JS ，别的语言都不想学的，所以 WASM 对大部分从业者，就是空气。

[nieboqiang]

@3dwelcome 你要知道，技术的替代不是他能更高的做什么，而是之前的技术不能做什么。

[nieboqiang]

我觉得技术不必太过于执着，尤其是工程目录这种不打粮食的问题，只要有规律，那怎么样都好啊。这东西本来就是为了让后来人看懂的，你遵循脚手架就好了啊。

其实你要不要想一下代码的本质是什么，我觉得他的本质是解决问题，什么规范之类的，只是为了让你同事看懂你的东西，这是个管理问题，不是技术问题。

[3dwelcome]

@nieboqiang 怎么说呢，我总觉得真正的编程，应该不分语言，不分运行环境。

但是 V 站上，前端和后端的割裂感是非常明显的。也就是前端的帖子，后端很少会参与。后端的帖子，前端也很少会参与。原因就是用的语言和技术栈不一样。

好不容易能通过 WASM 技术，把浏览器开发语言给众生平等了。结果大部分前端还是被 JS 给禁锢了，不免有点点可惜。

[nieboqiang]

@3dwelcome 我也觉得，程序员准确定位应该是工程师，为了解决问题而存在的。

但是现在的这套并没有出现不能解决的问题，那为什么要引入新的东西呢？新的技术，新的思想，那一定是能解决之前不能解决的问题，才会有活力。

[Envov]

是这种语境吗？

你：hello 在吗？这个项目工程目录管理的最优实践是什么啊？
资深的前端开发: 都可以。

如果是这种语境，我的看法是语境不对，没有表达的欲望。如果真的要表达，我可能需要精心的准备一个写稿的地方，毕竟写稿的地方也是最优实践的一种

[eGlhb2Jhb2Jhbw]

@Envov #96 可能回帖太多了，你没注意到中间楼层，我问的问题都是实际开发中遇到的细节问题，我在工作时候也没时间和别人大扯特扯 high level 的东西。