- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：是否可以考虑放弃浏览器另起炉灶 -- 益者三友
家园 是否可以考虑放弃浏览器另起炉灶 近来关于浏览器的贴子很多。
为了提高浏览器的执行效率，
google, ms, sun, adobe互相组团厮杀，好不热闹。
看来看去，看明白一件事：相对于其他程序，目前浏览器到执行效率是非常非常低的，程序结构是非常复杂的。而为了提高效率，未来设想的html5, FX等等，竟然更加复杂。
既然这样，说明目前的：浏览器+html+javascript+flash的组合，是非常糟糕的一种组合。为什么不想想，放弃这种组合，重新另找一种网络交互方式。
从历史上看，浏览器+html的出现，是很偶然的。而且也不是深思熟虑的软件业界高手的杰作。
html是专门为阅读文本文件，查找线索方便而设计的一系列标记。早期的浏览器仅仅是为了显示这些文字和标记而设计的。这个基础就不是为了多媒体和作为程序运行平台os而设计的。后来反复经过扩充功能，但浏览器的基础决定其扩充性并不好，代价就是结构复杂，运行效率低。
目前所用的javascript,是经过历史上多种动态网页技术PK而保留下来的。但这个结果并不是因为javascript非常杰出，而是大公司政治斗争的结局。
历史上曾有VBscript,activax,javabeans,swift,等等。但因为这些技术是由MS或SUN控制的技术，其他公司怕以后被人限制，所以就竭力抵制这些技术。而javascript并不是比这些东西好用，而是不受某公司单独控制，所以才勉强接受。
我记得看邓侃还是谁的贴里，提到一句很好的话：现在需要的不是一个新语言，而是一个协议。
现在争论浏览器扩充，不如重新回顾一下，在基础平台TCP/IP的基础上，重新设计一个网络交互协议。甚至连WWW协议都要重新审视。
因为未来的互联网，将包含有PC, phone, Mobile internet Device, Robot, 等等这些东西互相操作互相控制。目前的浏览器+html+javascript组合非常不适应未来需要。继续拆东墙补西墙的方法走不远的。付出的代价是浏览器越来越复杂，资源利用效率低，编程和跨平台交互越来越复杂。
本帖一共被 4 帖 引用 (帖内工具实现)家园 不太可能成功。 类似的问题，还可以问一下：
是否可以放弃X86的架构另起炉灶？
是否可以放弃Windows架构另起炉灶？
历史上，Windows3.1和8086都不是“深思熟虑的技术高手的杰作”（这样的杰作是有的，比如ISDN，一大群业界牛人在一起讨论了超过5年，可惜从来也没有在市场占据主流，技术的发展与这些牛人的预测完全不同，互联网的发展是主要的意外）
Z80曾经对抗过8086，在PC市场上输了，在工控市场还生存了一段时间。从技术上看，Z80要远比8086成熟。
68000曾经对抗过从80286到80486，以当时的技术条件，RISC远比CISC要“深思熟虑”的多，可是还是输了，其后代PowerPC现在也退缩到一个很窄的专业应用中了。
同样的，在Windws3.1的时代还有更加“深思熟虑”的OS2，也“香消玉殒”到天国去了。
另外，在通信技术中，我们也看到，更加“深思熟虑”的ATM技术，TokenRing技术，ISDN，统统被以太网打败。
是否“深思熟虑”不是一项技术能否占领市场的关键因素，用户是否欢迎才是。当然，如果推广者具有垄断性的实力另说。HTTP协议和浏览器能够在短时间内风靡全球，不是因为其技术领先，而是因为受到使用者的欢迎。甚至TCP/IP在“被迫”风靡的同时，更加“深思熟虑”的网络协议一大把。TCP/IP协议设计之初就不是为全球互联而设计的，而是为军事应用强抗打击要求而设计的，只是“碰巧”当时几所大学的教授学生们喜欢，又被有心的钱伯斯先生所利用而已。
在今天，IT技术进步在任何的方向上都可以认为是“创新过渡”的，最后“适者生存”留下来的才是我们未来能够普及的技术。
家园 性能是全方位的问题 想要传输的快，无非是在数据压缩处理与连接并发性上做文章，最后再加上可选安全性的功能。
这和CPU的发展是一样的道理，双核不够还有四核，八核，以及微软实验室中这样的机器。
外链图片需谨慎，可能会被源头改另外一方面就是开发人员的问题，尽量优化代码，少用javascript库。否则再好的应用协议也满足不了需求。
家园 痛苦的地方就在这里，要增强用户体验，不用js不可能 如果要做出超炫的效果，比如，网页做的跟客户端程序一样，什么拖放、右键菜单……不用js是根本不可能的。
但是最终用户根本不看你后台代码怎么效率高，怎么结构清晰，他单单就看页面如何好看，是否符合他的使用习惯。
还好现在带宽够大，用户的计算机速度够快，一般的js执行速度也不会太慢，尤其是使用非传统js引擎的浏览器。
家园 想法是好的，但是实施起来会很困难 技术的发展通常是渐进的。如果革命的话，不仅会割裂前人所做的工作，更担心的是会丢失先前技术的用户。
当然革命的做法也不是没有了，主要还是看大公司是不是愿意联手推动。
家园 从经济学的角度看 在现有平台上面开发，对开发人员来说，更经济，因为需要学习的东西少，开发速度快，所以支持的人也就越多。
新的框架，或者说平台，多半不是直接取代现有的平台，而是在新的应用领域拓展，最后才把已有的领域囊括进来。PC如此，web如此，将来手机也会如此。
家园 难啊 楼主所建议牵涉利益过大，除非能联合大部分相关利益厂商，否则没戏。
协议往往是大公司妥协的结果，就和楼主说的jas差不多，不是看技术先进与否。
参加过几个IEEE的协议开发，其中有2个还是根据draft版本开发的，因为大公司都想抢着出新产品，看着协议有个雏形就想先抢着把自己东西生产出来，如果卖得好可以形成实际标准，让别的厂商去适应。
IEEE在开会的时候，那几个委员发言基本是自说自话，因为大部分委员本身就是某公司的。有时候明摆着有问题的地方，委员居然能投票通过，实际利益使然啊。
中国人根本插不上嘴。。。。
家园 Google 研究比 HTTP 快两倍的新协议 SPDY http://google.org.cn/posts/google-spdy-2x-faster-web.html
http://dev.chromium.org/spdy
家园 好大的计划，连tcp都想干掉 这个说实话，根据他的宣传。我对能否快两倍表示怀疑。
最后吐糟下，他的某个测试 标题是world leaders
结果有 日美意韩什么的，就是没有中俄
家园 哪儿提到替代TCP了？ 标题是替换HTTP，是替换应用层协议，不是通信层。
看他的第一个版本的实现：
Connections
The first implementation of the SPDY session runs atop TCP, similarly to how HTTP works today. The client is expected to be the TCP connection initiator. Because it runs on TCP, we have a reliable transport. Unlike HTTP, all connections with SPDY are persistent connections. The HTTP connection header does not apply.
For best performance, it is expected that clients will not close open connections until the user navigates away from all web pages referencing a connection, or until the server closes the connection. Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections after some amount of inactivity if necessary.
他是建立在TCP之上的
