个人觉得前端挺苦 b 的

[arachide]

1.各种js框架／类库有不兼容
2.框架／类库对javascript干扰
3.每个框架都是新一套新东西新语法 多个框架堆在一起变成一坨屎

[otarim]

准备转后端了。。。所以还是喜欢自发的项目，用的都是自己的框架，有问题就修复[抠鼻]

[scarlex]

自己写最后的结果也是写框架，苦逼的不行。

[arachide]

@scarlex html/css/js就是终极框架

用库组合 不用其它框架

[randyzhao]

为什么楼上有人会说 "最蛋疼的应该是前端的工作谁都能指手画脚"

如果 UI UE 整个流程都很完备, 前端写出来的东西完全按照设计去做的话, 产品出来之后只会去针对 UI UE 而不会去针对前端.
很多时候, 的确, UI UE 可能缺乏前端常识, 设计出来的什么鬼, 前端没法去100%实现, 然后么, 就自己脑补一下. 结果显而易见就是被围攻了...

说下鄙人所在公司的撕逼现状
前端只和 UI UE 撕
后端只和产品撕
相对来说, 开发岗, 撕逼的对象都算是比较单一的关系, 不会有群攻的情况出现.

产品, UI, UE, QA 的话... 各种互相撕啊... 啧啧...

[sammo]

工程问题需要有工程问题的解决办法。
工程问题的解决办法最终就是 framework
因为每个工程都不同，所以基本没有通解。
因为每个工程都不同，所以不必追求通解。
工程问题需要有工程问题的解决办法。
-
虽然很冒昧，但还是思考了一下为什么一个 framework 会被有的人抹黑、有的人推崇 ?
工程项目有大有小
在工程问题面前，可控性、适配性、效率不可兼得

+可控性+适配性-效率：
每个工程都造轮子，为此工程自己写一个小 framework 出来，如果工程较小较可控，则可避免把简单事情搞复杂；如果工程较大较可控，最终就会一步步从 lib 写出 ng 这样的框架来

+可控性-适配性+效率：
每个工程都用现成的 framework ( ng ember.js 等 ) ，代价是如果你的工程在后期发展到足够复杂要自己去苦逼地补课填坑，以保证对现成的 framework 的可控性。当然如果能保证复杂度不超过 现成的 framework 的解决范围内就 ok 了

-可控性+适配性+效率：
根据工程难度，为每个工程选择现成的 framework ，并且保证工程在后期不会极为复杂，但然后就是轻松地，虽然很冒昧，去看文档添代码了

[angelself]

@randyzhao
“很多时候, 的确, UI UE 可能缺乏前端常识, 设计出来的什么鬼, 前端没法去100%实现”可能是实际情况吧，其实也挺伤心的，又不是故意的。大家职能不同，学科互涉是一个长期过程。谁想“设计个什么鬼”呢……
为了避免给前端GG添麻烦，我都是主动学习的……
有需求有改动温柔提出，出现问题责怪自己，平时还给前端GG修修照片搞好关系。

[BigDecimal]

后端难道不苦逼吗？需求文档都没有然后让你开发，倘若客户或者老总不满意就是各种改。。。

另外，后端还得会前端的活，前端的页面写的一坨屎，你还得帮他擦屁股，哪个更苦逼？