提要：
url anchor (ajax) => javascript engine (1~4 articles) => java VM vs. python interpreter => pypy
##
前两天在写《HTTP 初步探究》时，碰见一个问题，放到了 stackoverflow 上，简单讲，就是对于 /#wd=keyword 形式的链接，在 Fiddler 抓包里，并没有看见 wd=keyword 被上传到服务器，但最终，keyword 被正确处理了（HTTP 交互里出现了 GET /s?wd=keyword HTTP/1.1 请求），而整个 HTTP 交互期间没有出现 HTTP/1.1 302 之类的回应。
根据下方的一个回答「The component of the url after the # sign is called the URL Fragment. It is not directly sent to the server as a part of the HTTP request (which is why you don't see it in Fiddler); it is only accessible by the JavaScript running on the page.」以及评论里的补充可知，# 后面的这部分，被称作 URL fragment，仅可被页面运行的 js 处理，顺带还提供了一个链接，是关于不同浏览器对于重定向场景下 #url_fragment 的不同处理。另外，我也找到了一篇博客，《QQ 密码修改的小问题》，也是类似的问题。
两点印象：1. 前端蕴含丰富的技术含量（请原谅先前滴无知），要懂各种标准、理解网页排版、会做 profiling 以优化页面显示、浏览器兼容性，最深的误解莫过于「用 Dreamweaver 画网页的」；2. Javascript 目测很强大。
##
读了四篇系列文章《The race for speed》（整体观感是不明觉厉…… 囧）。讲述的是，Javascript 是如何从一个未被标准化的浏览器脚本语言（最初的 runtime environment 仅有 Netscape – 即后来的 Mozilla Firefox）演变为现如今拥有庞大社区的通用语言（其运行时除了浏览器，也出现了 Node.js 这样的可编写服务器端网络程序的平台）。
从「Javascript => machine code」的基本流程是「lexical analysis =(tokenised_code)=> parser =(Abstract_Syntax_Tree)=> translator =(byte_code)=> byte code interpreter =(native_code)=> rendering / executing process」，除此之外，类似 Firefox SpiderMonkey 和 Google V8 Javascript engine 都做了大量的优化工作，来更好折衷「更快的载入运行 js 代码」和「让 js 代码跑得更快」，以达成使用 web app 替代 native app 的宏大远景（可谓 think big and do right things to make it happen）。
从第三篇文章里看，这些优化工作，似乎不少都和 Javascript 的动态语言特性密不可分，比如 type inference 和 hidden classes，甚至 inline caching 都需要考虑多态缓存……
所谓的「Just-In-Time compilation」则是在一条条编译执行的基础上，缓存一部分编译过的 building block 以降低重新编译的性能损耗（可能还有其他高大上的加速思想）；由于 Javascript 的动态特性，还要区分 typed JIT 和 un-typed JIT，有点像「分支预测」，如果 type inference 预测正确，则执行先前已经编译并缓存的机器码，否则算是 miss 并提交给 un-typed JIT 执行进一步编译和执行。
这个系列的最后一篇，展望了 Javascript 的未来。其中提到了正在标准化的 ECMAScript 6 和越来越强大的 WebGL，唔，觉得未来 web app 还真可能会大面积替代 native app，Google 当年的宏大远景很牛逼。点赞。
还有两篇可扩展视野的文章，未读，备份一下：《Chrome V8 Degisn Elements》《Explaining JavaScript VMs in JavaScript - Inline Caches》。后面那篇似乎很厉害的样子，「I want to help JavaScript developers understand how JS engines work. I think understanding the tools you are wielding is of uttermost importance in our trade. The more people would stop seeing JS VM as a mysterious black box that converts JavaScript source into some zeros-and-ones the better.」如果是用 Node.js 开发者，可能深入了解一些 internals 有益于更上一层楼。俺这里就纯粹先 #mark# 了……
##
理清了一下 virtual machine 和 interpreter 的异同，这两天经常看见这两个词，表示略微傻傻分不清楚，伤不起…… 参考这个 stackoverflow 链接的回答一和回答二，前者讲的比较抽象，后者讲的比较实在（community wiki），读完了就比较清晰了。
理论上：
virtual machine 是提供了一组类似汇编语言 primitive operation 的运行时环境，也是其上所运行 byte code 的沙盒环境，JVM 不仅仅可以运行 Java 程序生成的字节码，也可以运行 python => JVM byte code 的字节码（只要你可以完成这个编译转换），换句话讲，是和语言无关的。
interpreter 则是和语言息息相关，其名称由来也和动态语言密不可分，静态类型（static typed）语言一般不需要「解释」，类型都是固定的，还解释个毛线呢，直接编译链接执行就完事儿了；但动态类型的语言，可能源程序里写着 someDict 的变量在第一轮循环里是哈希字典、第二轮循环里就变成了字符串，所以，需要 interpreter 好好「解释」。第二个回答里提到「The moral of the story is that primitive data type information is really helpful to a compiler/virtual machine.」值得好好体会，其中的 primitive data type 就是指那些 in-memory storage size 固定已知的元类型……
实际上：
在追求效率的场景越来越多的时代，类似 Python 这样的动态语言，也有 PyPy 这样的第三方实现，能够类似 SpiderMonkey / V8 对 Javascript 所做的那样，通过一系列优化，以提升解释执行的速度、优化内存使用、通过微线程提升并发效率。
有两篇和 PyPy 相关的文章，似乎不错，未读，备份先。《Why PyPy is the future of Python》《Wikipedia processing. PyPy vs CPython benchmark》。#mark# 另外，还有一篇官方文档《Python Speed – performance tips》，有时间通读一遍（总觉得有点 pre-mature optimization 的味道，由于 cPython 的优化不够所以需要在 code 层面避免掉坑。囧 如果真是这样，也算是某个历史阶段的 practical practice 吧，动态语言嘛，有得必有失……）。