@Asimov 你想说违宪？
1. 我认为对语言标准进行管理和言论自由无关
2. 对出版自由我国除宪法外尚无现行法律，对于实施细节没有明确的法律表述
3. 《出版管理条例》规定主管部门可以对出版物的出版进行准入和退出管理

如果你想说法律不全，这是事实，这一块没有现行法律，我承认；但你要说这违法，我个人持反对意见，具体的就看起诉广电的律师团队了

@Asimov 有什么好笑的？你发言就是为了嘲讽？能认真说话么？

@am241 这是你的自由，哪怕我的回复你看不到了，持有不同观点是你的自由，没有问题

泥人也有三分火性，看了几个相关帖子，感觉都是爆炸的能量，我会克制好自己不发表过于攻击性的发言，虽然这跟你没什么关系了

@Asimov 我认为争论是合理而且有益的，争论是一种非常有效率的交流方式，大家非常活跃地把自己的观点陈述出来并且相互间有很多交流，不过我认为如果真的是以交流为目的的话，在讨论和争论的过程中，大家需要克制自己的情绪和言行；对于不以交流为目的的发言，比如隐晦的或者直接的针对任何人或组织的攻击，或者是以发泄为目的的发言，我认为对交流是没有益处的

@youdu 禁止使用英文，谁给广电钱了？举个例子？

所以你理想中的社会就是没有任何监管，人们两两进行交易？
况且宪法中全文搜索并没有出现“交易自由”字样

既然在中国境内，主管部门就可以对其分管的领域进行监管， 2013 年两会审议通过的国务院机构改革方案明确说明了广电有统筹、监督、管理新闻和出版物的职责，对分管领域进行监管是它的职责，不是因为开发者侵犯了谁的利益

你是否认为无法社会就是你想要的？如果是，那没什么好讨论的了
另外，在没有人提到的情况下，你为什么要把腐败问题拉进来讨论，在当前语境下我认为这是一个跟我的任何回复无关的话题

我知道在这种帖子里回复支持或者中立只会引来一堆水军喷我，但是实在不吐不快，现在网络上戾气太重，大家攻击性都太强了，尤其是跟任何主管机构扯上关系的主题，根本没法好好讨论

预先做个防御，想喷我为什么用英文用户名和注册这么多英文网站的人，我在以外文为主的社区用的是外文，不会用中文，我想这是基本礼节，也是很正常的事情

到目前为止，就我所了解到的信息，相关消息来源仅限于“网传”。

以下回复建立在该传言为真实的基础上

@Andy1999 商标是商标；简写是简写；商标和简写使用原本的文字没有问题；玩游戏做一个任务，任务说明都是中文的，点击开始蹦出来一句“ Mission Start ”就是 SB ，如何
商标和缩写本来就是特殊的符号，我认为使用并没有问题，而在正文里使用我同意 lz 的意见，属于无意识地抬升英语

@wensonsmith 互联网和计算机科学本来就是来源于英语国家
@terence4444 这一套本来就是英语国家的人发明的，人家占了先手优势
@echo1937 我作为一个南方人不想被你随随便便代表

@kn007 是这么个道理，但是不注意的话混杂地讲多了确实会对人造成影响，不同的语言表达的方式不一样，我发现有些时候用英语表达更准确，用得多了，如果不注意锻炼的话，我用中文进行相关的表达就会变得困难一些

@wizardforcel 这主要是一个习惯的问题，类似于“ Mission Start ”的语句作为提示符，一方面让我感觉这游戏做的人不用心，根本懒得做，直接照抄，另一方面给人感觉“这里蹦出一句英文感觉很酷”，如果这些形成一个无意识的潮流或者风气，就会影响到人群对语言的感觉和认识，像我最近看朋友玩守望先锋，里面很多提示都是中文的，给我的感觉就是做的很用心，在我没玩过的时候给我的印象就很赞

@am241 我认为“ Misson Start ”不属于也不应属于外来词，目前外来词的产生主要是本国语言原本没有针对目标事物的描述符号，或者出现缩写（简记符号），才会被归为外来词被接纳，而一些提示符“ BOSS 战开始”或者“ Mission Start ”描述的并不是本地语言无法描述的对象
说了这么多，看你直接 block 的动作，我知道也是白说

@gefranks Next time when you met people with different opinions just go away, please do not leave a reply or let other people know who you are. Because you will not be welcomed by the same kind of people.

@youdu 开发者愿意用中文还是英文还是日文是自由，管理出版的部门愿不愿意同意出版也是自由；另外，政府机关不是“公民”，也不是“自然人”，本来就是“管理的权力”，而不是“权利和义务”

@jamiefang 如果这份传言是真实的话，我同意“强制规定”是不够合理的，应该有更细致的条例来进行更好的规范
1. 以学习语言或者传播文化为目的的严肃游戏应该被增加到允许的列表里，比如《 Never Alone 》这种游戏，我认为这出现不同语言没什么问题
2. 专业名词或者本土语言原本没有的词汇，在使用的过程中逐步被本土语言接纳和融合是一个正常的过程，而国家机关进行一定的引导我认为是可以接受的，这也将有助于语言的健康发展，如果没有一个机构进行语言的集中管理，就会产生混乱，不仅仅是语言，凡是符号都是同样的道理，比如前苏联的正切余切使用“ tg ”和“ ctg ”，我小时候看的书很多都是这种，后来我就很不习惯已经成为事实标准的欧美写法“ tan ”和“ cot ”了，符号的统一肯定是有好处的
3. 目前游戏业界的现状，我认为“表彰”甚至是金钱奖励，对于今天的人来说都已经没有了什么作用，很多行业，大家把政府的补贴当做理所当然，甚至当做来钱的路子，你提的这个想法我觉得只会是肉包子打狗，有去无回
4. 国产游戏缺少大作和优秀作品（我是说缺少，没有说不存在，准备咬文嚼字的注意了）这是事实，国家对于文化产业肯定也是想发展的，但目前也只能发展到这种程度，只能说大家再努把力了
5. 目前国产游戏的数量上已经是非常可观了，即使是在世界范围内，我们很多游戏厂商向海外市场的销售还是很可观的，更别说还有一些反向收购的案例，所以我们才更需要扭转“使用英文标识”这种刻板印象
总之，维护语言的发展我是欢迎的，目前由于全球化进程很快，语言的融合过程必然也是会充满冲突和阵痛的，比如我已经不太能很流畅地说家乡话了，未来的语言究竟什么样谁也不知道，这种政策也只是一种尝试吧

@milklee 由于百度贴吧的存在，其实这两个字的界限已经很模糊了……

@Felldeadbird 你如何使用语言是你的自由，我想这份传言如果是真实的话，并没有影响到你的这种自由，而出版物（比如游戏）中出现的文字是怎样的一种形态，这并不是你的自由，因为出版社不是你的

@beimenjun
1. 字母语言书写方便，缩写方便这是事实，在很多地方用的比较多是很正常的事情；语言毕竟也只是符号，这一点没什么可辩驳的
2. 不谈说服力，我们考虑一下语言的受众，推行英语教育多年后，我想大多数人（以全国人口为基数来谈）也只是见过这几个字符而已，如果你有关注过经济稍微落后的地区的生活的话，你会发现很多笔记本（我说纸质的）、衣服等很多日常生活中的物品上，会印上一些错漏百出的外文，这些年来，上面的外文的语法似乎是越来越好了（笑），如果你没有相同的看法的话，希望你能去了解一下；从这些生活中的发现，我确实隐约有点这种感觉，就是印上外文的东西，被赋予了一种“新的”、“酷的”（这个词本身还是外来词）的印象，这是由于近代西方发展太快，超过了我们，造成的一种，怎么说呢，心理上的落差吧，这一点主要是我个人的感受，我说的不太有条理，我目前对这个问题的认识还没有到可以顺畅地表达的地步，抱歉，希望你能理解我说的内容
3. 成本是商家考虑的事情，前几个月索尼网络娱乐和索尼电脑娱乐还合并了呢，这得改多少东西啊，但是这并不是管理者应该考虑的事情，商家又不是政府的爸爸
我这里为什么不说 SCE 和 SNE 呢，不是为了装，也不是为了佐证我的观点，因为这个缩写还真不一定多少人知道，所以你说的第一点表达的意思我是同意的，另外我也认为这个不应该是死的政策，应该有一个细则来细化
4. 化学、数学、物理等科学上，由于有非常多的新符号，我们原生的语言中没有的，要使用它们，我们就必须有一个符号来指称它们的所指，有些符号是先行者的翻译书籍给出了一些符号，后面的人沿用了，就留了下来；有些符号，比如正切 tg 和 tan ，由于我国数学教学曾经切换过流派，就需要一个总的推动力（教育部）来规范所有的用法（不管是从事实上还是从政策上）；而近些年来，特别是计算机科学发展非常快，很多词语根本来不及走“纸质出版”这条路，特别是由于电子出版物的出现，造成了大量纯外文词汇的使用，这倒也无可厚非，毕竟新出署之前也就只能管到纸质出版物。这一点（关于技术词汇）我是不反对使用外文原文的，但是就我目前看到过的关于这个流言“网传广电禁止英文字母”的报道，似乎针对的是在游戏中出现“ Mission Start ”这种英文提示，而不是你这一点里提到的技术词汇，你似乎是把问题扩大化了？
5. 你说的这一点我没看懂，矫枉过正确实是存在的一种自然现象，我认同这一点，在陈述这一点的时候你似乎有点过于激动
6. 借词没有错，外来词是语言的正常的组成部分，具体参见我回复你的第四点
7. 这一点对于讨论来说没有任何意义（我针对这一点的回复也是）

好多人，写的好累，下面的就不回复了，总的说一下吧，就我通读这篇帖子的各种回复来看，反对广电的人回复所带的个人情感比较丰富，骂人也比较严重；支持或者认为需要规范的人的回复普遍比较冷静，就算不讨论回复的内容，我也对反对广电的很多人产生了很大的恶感，不管是出言不逊还是过强的攻击性，毕竟攻击性无益于讨论

lz ，你贴的这一句里面， getYear(), getMonth()这些方法都是 native 代码，不用担心性能

@murmur 手机都可以做到的话， PC 端 js 就更不是问题了

@murmur
1. 软件上， NPAPI, NaCl, pNaCl, WebAssembly 都可以做到用 C++编写程序，用 js 调用，达到 C++级别性能，前面几个在目前的 Android Chrome 似乎是不可用的，但是 WebAssembly 已经可以打开
2. 硬件上，市面上 3G 内存手机已经大量铺货，下半年到明年， 4G 到 6G 内存手机会进入市场
3. 处理器上，我用 Geekbench 实测了一下:
小米红米 note3 ，使用高通 650 处理器，整机 1000
http://browser.primatelabs.com/geekbench3/7242545
PC 机， i7-4790k ， 32G 内存， 2 年前整机 1w+
http://browser.primatelabs.com/geekbench3/7242536
性能差距在 1 个数量级以内，价格差距在 1 个数量级以上

@murmur webmidi 是用来做手机端 web app 的，相似的还有 webusb ， webbluetooth ，
如果你用 android chrome ，它有一个功能“添加到主屏幕”可以把 webapp 添加到桌面上，这会产生一个很轻量级的应用，
如果 web app 可以接触更多的硬件 API ，比如蓝牙设备，比如 USB 口，比如 MIDI 设备，那么它的可用性就能增强，毕竟 js 门槛低， webapp 更新方便，如果 js 能做到所有的事情，那很多人就会考虑用 js 来做产品了，毕竟在同一个浏览器下开发 html 页面比开发全平台的 native app 方便多了

这些方面都是为了 web app 能在各方面接近原生手机应用而做的努力，你只考虑桌面浏览器的话现在是不需要这些

一个已经基本结束开发，正在长期稳定运营的工程，你这升级操作系统版本是不是太激进了？

@iugo 我确实不用 Ruby ，开发效率我是有关注的，我们前端很多项目整体采用 AngularJS+requirejs+karma+jasmine ，写起来还是蛮快的，不太用动脑子

确实，如果浏览器给力，技术这边可以很省力，我们在针对 Chromium 49 编写桌面程序的时候就很舒服；而为微信写东西就需要相对有经验的人来做

但是，了解针对限制更大的浏览器（ IE ，微信）进行开发的人，毕竟比了解 ES6 的人好招…

ES6 确实可以带来开发效率的提升，不过这些很大程度上是可以用框架来弥补的，更何况框架和 ES6 都有一定的学习成本

楼主你如果只是来吐槽，来骂这该死的内置浏览器怎么这么烂，没问题，我也想骂，各种排版不能用， WebGL 都不能用，简直坑爹，而且微信内置浏览器是提供 WebGL 接口的，就是调用之后没有任何效果，不是简直，就是坑爹。

但你抬头看看标题，标题是一个问句吧？

在
1. 所有 web 开发者都必须为每一个平台做 polyfill
2. 挑选一个弱一点但是在几乎所有机器上都能跑的版本，微信内置该版本的某浏览器，所有 web 开发者在这个基础上开发
两者中，我认为 2 是更负责任的

在附言中，你提到了一个前提：“ Android >= 5.0 ”，瞬间就少了 54.5%的用户 （数据来源： 2016/6/6 更新 https://developer.android.com/about/dashboards/index.html ）

使用系统 webview ， web 开发者需要适配 如下浏览器：
Android 2.x Webview; (市场占比 2%)
Android 4.0-4.3 Webview; (20.8%)
Android 4.4 (Chromium 30); (31.6%)（增加 GeoLocation 、 WebSocket 支持）
Android 4.4.3 (Chromium 33); (包含在上面)（增加 Vibration API 支持）
Android 5.x (Chromium 37+); (35.4%)（增加了 WebGL ， WebRTC ， WebAudio ， WebComponent 支持）
Android 6.x+ (>= Chromium 43) (10.1%)
我的手机目前是 Android 6.0.1 (Chromium 51)
iOS Safari （很多版本）
各种厂商自己做的奇怪的浏览器适配

使用微信 WebView ，开发者需要适配如下浏览器：
QQ X5 内核（提供基础 HTML5 支持，部分新特性如 WebSocket ，部分 WebGL 支持）
iOS Safari （没得选）
Android >= 5 的基于 Chromium 的 WebView

你觉得哪个比较简单？

为何使用内置浏览器（注意，微信不是“内置 WebView ”，是内置一个“浏览器内核”），而不是直接使用基于 Chrome 的 WebView
1. 54.5%的安卓机没有该功能
2. 然后就没有然后了

为何使用内置浏览器而不是使用系统 WebView 呢
你要谈技术，那就谈技术
举个例子， WebSocket ，我在 Android 4.1 的机器上，用微信可以使用 WebSocket ；而 Android WebView 只有 Android >=4.4 才支持 WebSocket
再来一个， Android 2.x 的 WebView 不支持 position:fixed 和 overflow:hidden ，你喜欢么？
安卓 webview 的坑很多，如果你真的做的话，你会后悔产生“用 polyfill 解决这些问题”的想法的

为何内置 QQ X5 内核，不内置一个 Chrome
1. Chrome 打包 zip ， 50MB ，（比微信大）
2. 然后就没有然后了

你使用最新的语法，然后来兼容老浏览器，这除了给自己开发带来快感（和恶心感），还有什么其他的好处？ polyfill 肯定是需要用原生实现来实现的（如果能实现），必然是有性能损失的。

关于你说的产品观，如果你是个人开发者，或者是个创业者，凭热情和自己的想法活动，或者说你面对的平台比较稳定，你这么做没有问题；如果是面向所有用户的公司行为，我认为稳定是高于对 bleeding edge 的技术的热情的

举个例子吧，我现在维护的项目里，有一个是针对我们在桌面应用内置 Chromium 浏览器的，版本统一是 Chromium 49 ，我可以在这里面非常自由地使用各种高级语法；而有另一个项目是针对微信用户开发的，开发的时候自然就得小心谨慎

微信是一个商业产品，做出来是给用户用的，不是给开发者狂欢的

补充：
http://caniuse.com/#feat=fetch

Android Browser 需求 Android >= 5.0

并且华为 P8 虽然是 Android 5.1.0 ，但是内置 webview 不是基于 Chrome 的，之前我们开发 WebGL 的时候就差点撞死在 P8 上，最后改成 canvas 了

顺便说下 fetch ，参见兼容表格：

https://developer.mozilla.org/zh-CN/docs/Web/API/Fetch_API#Browser_compatibility

Safari webkit 不能用，老的 Android webview 不能用，楼主你就不该用 fetch ，这个组件本身就不应该被用作移动端开发

@iugo 没有用户需求，就不需要开发者，开发者不是和用户对等的

使用系统 webview ，就像楼主你自己说的，只会增加适配的工作量，不会减少开发者的负担

开发一个页面，只有部分用户能看见，其他人只能看见一个报错信息，听起来不是一个好主意

比如 WebBluetooth ，比如 WebGL （没错，之前安卓微信不能在所有平台上使用 webgl ）

1. Chrome Webview 不是可以一个安卓项目可以“直接打包在 apk ”里面的东西，能用的只是“ Android Webview ”
2. Android Webview 在不同安卓版本是 **几乎完全不同** 的，在 Android <4.4 上， webview 不是 Chrome ；随着安卓版本的变化，内置 webview 所实现的技术标准差别太大，根本无法控制一个微信 web 页面在不同系统 webview 上的表现
3. Android Webview 在不同厂商的 ROM 上，实现也是天差地别，同第二点，无法控制产品的表现，而使用同一个内置的浏览器内核可以控制
4. QQ 内核是集团内部的东西，举个具体的例子，在当前 WebBluetooth 还在草案阶段， WebBluetooth API 目前只有 Android 6.0 及以上才能使用，而微信已经能在页面上使用蓝牙信息（只要有蓝牙和有微信），请问如何在系统 webview 上使用蓝牙接口？
5. 自定义 url scheme 是一个很重要的功能，系统 webview 能提供的自定义是受限的，如果使用自己的产品，可以无限制地自定义和使用，微信的交互很多，基于一个简单的系统 webview 开发如此复杂的功能，听起来像是一场噩梦


补充：
WebBluetooth 接口实现情况： https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md