个人觉得前端挺苦 b 的

[arachide]

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

[arachide]

框架很多时候看着便宜其实是当
n多没法写正经javascript多前端很悲剧

[kungfuchicken]

个人觉得写PHP挺苦B的
1. 各种PHP框架／类库不兼容
2. PHP运行版本对程序功能的干扰
3. 每个PHP框架都是新一套新东西新用法 多个框架堆在一起变成一坨屎

[arachide]

类库对语言能产生干扰对应该只有javascript
偶知道的
$('a') 别的语言没见过

[dalaomj]

httponly，剥夺你操作cookie的权限。

[jimwoo]

@arachide 我觉得你这么说就不对了~

框架、类库不兼容是因为没有遵循唯一命名空间，我一般用jQuery这样的,很少用$.

新语法?语法可以被框架改变？？？

[Mirana]

明年打算转后端了

[arachide]

偶觉得css框架（类似bootstrap）＋purejavascript就好了

mvc framework太乱了

[EXDestroyer]

我感觉php更是

[ffffwh]

@dalaomj
总得有个js不能操作的机制。除非全部https，否则XSS攻击理论上防不了。

[arachide]

这篇文章偶赞成
http://segmentfault.com/blog/bum/1190000002455654

[loading]

现在前端技术一直在革新，追不上。

[arachide]

@loading
很多人活着就是为了把简单事情搞复杂

[andy12530]

很多人活着就是为了把简单事情搞复杂

+10086

写 JS 两年了，为毛我觉得挺爽的。。

[arachide]

@loading

delphi／vb时代没见过谁专门定制ui算是技术的

[dong3580]

@Mirana
后端更苦逼，作为一个后端，表示动不动都要去做前端，赶紧好混乱，以致于以为自己是个前端程序员，拿着后端卑微的工资。

[hackwjfz]

感觉PHP更苦逼。

任何公司项目都需要前端、但不一定需要PHP
前端能写出漂亮页面把妹、妹子看不懂PHP

[FrankFang128]

楼主搞笑

[akfish]

这些算什么，最蛋疼的应该是前端的工作谁都能指手画脚。
反正是个人都能觉得好看或者不好看，当然你问有的人哪里不好看时却又说不出个道理来。

[zzNucker]

最蛋疼的应该是前端的工作谁都能指手画脚。+1

问题是写界面最苦逼好吗。。。 而且后端还老过来指手画脚跟我说体验卧槽扯个几把啊好好写你的后台好吗我们前端+视觉+PM都确定的东西你说个屁啊。

[Mirana]

@dong3580 那有可能是公司的管理不合理，不是后端的问题

[shiny]

@zzNucker 当设计师缺乏前端知识的时候容易出这样的问题

[rentaro]

明显是“体验·”一词流行的时候，人人都成了产品经理，然后还出了本书

[arachide]

@zzNucker

偶赶脚传统后端如果不转写hadoop的mapreduce都得失业

[soulteary]

@arachide 全局变量这个话题，老生常谈了，不多做解释和建议了，对前端有兴趣，不妨多搜索下，有一些国内前端已经用烂的技术可以参考下，关键词：模块化/CMD(KMD)/AMD

实际业务场景不需要cover所有，以及不需要对所有端提供一致性功能。

@arachide vb时代，蛮多UI方案的，包括并不限于用web ui，可能也算是当下的webview的hybird模式吧。

@zzNucker 说明团队存在不靠谱成分，职责划清后，除了讨论外，不应该越权处理事务（这里的指手画脚特指不清楚实际场景时他人的『友善』建议）

[arachide]

@soulteary 偶没提全局变量 不知到你联想到什么了

老外这篇文章提到 要库不要框架
http://segmentfault.com/blog/bum/1190000002455654

国人很多发明错在一个苍蝇拍都要搞出平台
其实做个小而美得库有何不可 小而美做到极致也是nb的

javascript是图灵完备的 理论可以做任何事情

偶个人用到web前端， nodejs， qt／qml， nosql／mapreduce， cocos2dxjsb， unity3dscript，嵌入
都是生产环境的东西
这东西不是玩具

何必在html／css／js上搞另类的框架平台呢

cocoa touch也有类似的东西 three20

现在已经死了 呵呵

[arachide]

另外google不一定都是高大上

google搜索引擎三个主力程序之二是印度人

以前阿三都是搅屎棍是没错的

今天一样的 嘿嘿 偶没细看angular 但是感觉那是一坨大屎

[arachide]

纠结几坨屎大营养区别偶感觉不是个事情
html／css／javascript已经足够强大
只需若干js类库活着pure css框架就好了

不需要雾上之雾类似angular ember这些框架

这些很多都是人没事找事 老外这种人也不少

个人观点 嘿嘿

[ianva]

空谈一些概念，站队，没有任何意义，框架有框架的应用场景，库有库的应用场景，什么都不是银弹，能够提高项目的生产力就是好猫。

至于社区无法统一规范，这个是语言在设计之初就一直存在的问题，javascript 并不是一个好的语言，但被互联网推到风口浪尖也没办法，当然也带来了技术的百花齐放，虽然有点杂，但比没的选要好太多了。

javascript 跨平台的优势带来了繁荣，也带来了语言难以更新换代，这是结症，结果到是导致了 javascript 成了 web 的汇编，各种编译成 javascript 的语言也在市面上流行了，这么看不只是库和框架，语言层面这么来更是混乱，但既然有这样的语言出现就说明有强烈的需求。

[arachide]

@ianva 空谈一些概念当然没用
javascript最新热度脚本世界第一 超过python php
离开这个说它不是一个好的语言 有意义吗

[ianva]

这话说的，探讨一个语言是否是好语言和占有率有什么关系，python 要是能在各个浏览器上跑，那也是第一脚本，另外这和主题也没啥关系
框架带来了什么？ angular 这类东西，还有 react 都在很大程度上提高了生产力，mvvm 框架的繁荣也让 web components 这类标准上了日程，从各方面来说都很大的促进

[breeswish]

js 最初本不是做这些什么 Web Application 事情的 233

[br00k]

前端的确苦逼很多，写后端保证逻辑OK，基本就OK了。前端太多意外状况了，数不胜数。

[ianva]

另外关于一些框架如 angular，ember，真不是显得蛋疼，没事找事的人才去用，
如果做过交互足够复杂的项目你就知道，所谓的小而美的库要挖多大的坑，化多少时间才能完成那些成熟的框架完成的东西，且还不讨论代码的维护性

[garfeildma]

找一门编译到js的语言，cljs，typescript

[bfti]

@hackwjfz 前端如何把妹?
@dong3580 后端比前端工资高的吧?
@arachide 你从来不用框架么?
@kungfuchicken 前端框架也是屎吧

[arachide]

@用 jquery bootstrap
不用框架

[sm0king]

我会说，现在基本都在手写么
那样，更苦逼！写到哭····效率还极低···

[RaymondYip]

TAT Jquery,Lo-Dash 必须啊,, 特别是工作多,,还要考虑 IE 兼容, 100%对照设计稿的时候.. 不考虑兼容倒是不觉得苦逼,, 看着一堆好东西用不了才叫苦逼哇

[otakustay]

楼主你主导过的最大的前端项目大约有多少行javascript的source code？有上十万的不？有上十万并且在一个页面内运行的不？

[arachide]

@otakustay 10W行你都运行？
没事挂坨东西不累啊

别说你搞的是web office
嘿嘿

[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]

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

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