UPDATE: Some folks think that saying "JavaScript is Assembly Language for the Web" is a totally insane statement. So, I asked a few JavaScript gurus like Brendan Eich (the inventor of JavaScript) and Douglas Crockford (inventor of JSON) and Mike Shaver (Technical VP at Mozilla). Their comments are over in this follow up blog post.
更新：有些人认为说“ JavaScript是Web的汇编语言”是完全疯狂的说法。 因此，我问了一些JavaScript专家，例如Brendan Eich(JavaScript的发明者)，Douglas Crockford(JSON的发明者)和Mike Shaver(Mozilla的技术副总裁)。 他们的评论已在此后续博客文章中结束。
I was talking to Erik Meijer yesterday and he said:
昨天我正在和Erik Meijer交谈，他说：
JavaScript is an assembly language. The JavaScript + HTML generate is like a .NET assembly. The browser can execute it, but no human should really care what’s there. - Erik Meijer
JavaScript是一种汇编语言。 JavaScript + HTML生成类似于.NET程序集。 浏览器可以执行它，但是没有人应该真正在乎那里的内容。 -埃里克·梅杰(Erik Meijer)
This discussion started because I was playing with Google+ and, as with most websites that I'm impressed with, I immediately did a View Source to see what was underneath. I was surprised. I saw this:
之所以开始讨论，是因为我在玩Google+ ，就像我印象深刻的大多数网站一样，我立即做了一个“查看源代码”来查看其背后的内容。 我很惊讶。 我看见了这个：
Let's just say that this went on for about 1300 lines. It is tight and about 90k. This is just the first half. It's mostly minified JavaScript. The middle part of the page is all spans and divs and generated class ids like this:
让我们说这持续了大约1300行。 它很紧，大约90k。 这只是上半年。 主要是精巧JavaScript。 页面的中间部分是所有span和div以及生成的类ID，如下所示：
Oy. The whole page is a big GUID.
哦整个页面是一个很大的GUID。
However, I see this on http://msn.com, http://www.bing.com, http://www.facebook.com and on and on. Even http://www.twitter.com is starting to "tighten" up a bit. All large sites appear to care not one bit about the aesthetics of their markup. So why do we?
但是，我在http：//msn.com、http： //www.bing.com，http : //www.facebook.com以及其他地方都看到了这一点。 甚至http://www.twitter.com也开始“收紧”一点。 所有大型网站似乎都不在乎其标记的美感。 那我们为什么呢？
It works, and it works great. Many of Google's best properties have GWT behind them. Would you be more impressed if you did a View Source and found that it was not only pretty on the outside but also inside?
它有效，而且效果很好。 Google的许多最佳资产都支持GWT。 如果您查看了View Source，并且发现它不仅在外观上而且在内部都很漂亮，您是否会印象深刻？
This seems a little ironic because it was just a few years ago when ASP.NET Developers were railing against ViewState. "It's so heavy" really means "I don't understand what it does." ViewState was (and is) a powerful enabler for a development methodology that gets folks developing on the web faster than before. This is not unlike other toolkits Google Web Toolkit (GWT). GWT isn't completely unlike Web Forms in its philosophy. From the GWT website:
这似乎有点讽刺意味，因为仅在几年前，ASP.NET开发人员才开始反对ViewState。 “它是如此沉重”实际上意味着“我不明白它的作用”。 ViewState是(现在是)一种强大的开发方法促成器，可以使人们在网络上开发的速度比以前更快。 这与其他工具包Google Web Toolkit(GWT)一样。 GWT的哲学并不完全不同于Web Forms。 从GWT网站：
Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.
Google Web Toolkit(GWT)是用于构建和优化基于浏览器的复杂应用程序的开发工具包。 它的目标是实现高性能Web应用程序的高效开发，而无需使开发人员成为浏览器怪癖，XMLHttpRequest和JavaScript方面的专家。
That seems like a very admirable philosophy, no? You could even say (with apologizes and tongue in cheek):
这似乎是一种非常令人钦佩的哲学，不是吗？ 您甚至可以说(道歉，面颊含糊)：
"ASP.NET WebForms" is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.
“ ASP.NET WebForms”是用于构建和优化基于浏览器的复杂应用程序的开发工具包。 它的目标是实现高性能Web应用程序的高效开发，而无需使开发人员成为浏览器怪癖，XMLHttpRequest和JavaScript方面的专家。
The intent of this post isn't to shine a light on WebForms or be a WebForms apologist. It's great for certain kinds of apps, just as GWT is great for certain types of of apps. What I want to focus on is that working with server-side toolkits could be argued as going against the alternate philosophy that the real joy of developing on the new web comes from clean jQuery JavaScript and clean, clear markup ala Razor or HAML. It all comes down to what level of abstraction you choose to play at.
这篇文章的目的不是要对WebForms发光或成为WebForms辩护律师。 这对于某些类型的应用程序来说非常有用，就像GWT对于某些类型的应用程序一样。 我要重点关注的是，使用服务器端工具包可能会被认为与另一种哲学背道而驰，即新Web上开发的真正乐趣来自干净的jQuery JavaScript和干净，清晰的标记ala Razor或HAML。 一切都取决于您选择使用哪种抽象级别。
Semantic markup will still be buried in there and things like http://schema.org are still very important, just don't expect the source of your favorite website to read like a well indented haiku anymore.
语义标记仍将埋藏在那里，并且http://schema.org之类的内容仍然非常重要，只是不要指望您喜欢的网站的源代码会像缩进的hai句那样读起来。
To be clear, minification and compression are orthogonal optimizations. I'm talking about simply not caring if the markup and script emitted to the client are pretty. If you don't care about the markup sent to the browser, only the result, how can this free us to develop in new ways that aren't confined to slinging markup and JS. Ultimately, if it works great, who cares?
显然，最小化和压缩是正交优化。 我说的是根本不在乎发送给客户端的标记和脚本是否漂亮。 如果您不关心发送到浏览器的标记，而只关心结果，那么这如何使我们腾出空间来开发新的方式，而这种方式不仅仅局限于标记和JS。 最终，如果效果很好，谁在乎呢？
My question to you, Dear Reader, is why do you care what View Source looks like? Is HTML5 and JavaScript the new assembly language for the Web?
亲爱的读者，我要问的问题是，为什么您要关注View Source的外观？ HTML5和JavaScript是Web的新汇编语言吗？
UPDATE for clarity:
为清楚起见，更新：
The point is, of course, that no analogy is perfect. Of course JavaScript as a language doesn't look or act like ASM. But as an analogy, it holds up.
重点当然是没有比喻是完美的。 当然，JavaScript作为一种语言并不像ASM那样看起来或不像ASM。 但以此类推，它成立了。
- JavaScript is ubiquitous. JavaScript无处不在。
- It's fast and getting faster. 它越来越快。
- Javascript is as low-level as a web programming language goes. Javascript就像Web编程语言一样底层。
- You can craft it manually or you can target it by compiling from another language. 您可以手动制作它，也可以通过其他语言进行编译来定位它。
If the tools - as a developer OR a designer - give you the control and the results you want, what do you care? I propose that neither Rails, nor ASP.NET nor GWT is 100% there. Each has their issues, but I think the future of the web is a diminished focus on clean markup and instead a focus on on compelling user experiences combined with languages and tools that make the developers work enjoyable and productive.
如果工具(作为开发人员或设计师)为您提供了所需的控件和结果，那么您关心什么？ 我建议Rails，ASP.NET或GWT都不是100％。 每个问题都有各自的问题，但是我认为网络的未来不再是对纯净标记的关注，而是对引人注目的用户体验以及与使开发人员感到愉快和高效的语言和工具相结合的关注。
What do you think, Dear Reader...Do you want your HTML and JavaScript abstracted away more? Or less?
亲爱的读者，您如何看待...您是否想进一步提取HTML和JavaScript？ 或更少？
UPDATE: I want to say this again to make sure folks really understand. There's two separate issues here. There's minification and general obfuscation of source, sure. But that's just the first. The real issue is JavaScript as a target language for other languages. GWT is a framework for writing Web Applications in *JAVA* where the resulting bytecode is *JAVASCRIPT.* GWT chooses a high level designed language (Java) over an organicaly grown one (HTML+JS) and treats the whole browser as a VM. The question - do we write assembly language or something higher level? Also, I realize now that Google+ was written with Closure, but the point remains valid.
更新：我想再说一遍，以确保人们真正理解。 这里有两个独立的问题。 当然，有最小化和一般混淆的来源。 但这仅仅是第一。 真正的问题是JavaScript作为其他语言的目标语言。 GWT是一个用* JAVA *编写Web应用程序的框架，其中生成的字节码是* JAVASCRIPT。* GWT选择了高级设计的语言(Java)而不是有机增长的语言(HTML + JS)，并将整个浏览器都视为VM。 问题-我们编写汇编语言还是更高层次的语言？ 另外，我现在知道Google+是用Closure编写的，但是这一点仍然有效。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
