为什么我不在 Javascript 和 Javascript HTML 模板中构建整个 Web 应用程序？
我在一个应用程序上需要开始缓存东西，这让我思考......
- 在应用程序的某些部分，我渲染表格行（jqGrid、slickgrid 等）或花哨的 div 行（就像在 New Twitter 中一样）通过获取纯 JSON 并通过 Mustache、jquery.tmpl 等运行它。
- 在应用程序的其他部分，我只是以纯 HTML（服务器端 HAML 模板）呈现信息，如果有搜索/分页，我只需转到一个新的 URL 并加载一个新的 HTML 页面。
现在的问题在于缓存和可维护性。
一方面，我在想，如果一切都是使用 Javascript HTML 模板构建的，那么我的应用程序将只提供 HTML 布局/shell 和一堆 JSON。如果您查看 Facebook 和 Twitter HTML 源代码，您会发现这基本上就是他们正在做的事情（95% json/javascript，5% html）。这将使我的应用程序只需要缓存 JSON（页面、操作和/或记录）。这意味着无论您是访问 JSON api 还是海峡 Web 应用程序的远程 api 开发人员，您都会访问缓存。也就是说，我不需要 2 个缓存，一个用于 JSON，一个用于 HTML。这似乎会将我的缓存存储减少一半，并稍微简化一些事情。
另一方面，我在想，根据我所看到/经历的，生成静态 HTML 服务器端并缓存它，似乎是跨浏览器性能更好的方法；您可以立即获得图形，而不必等待 JavaScript 渲染它。 StackOverflow 似乎可以用纯 HTML 完成所有操作，Google 也是如此，而且您可以看出...所有内容都会立即出现。请注意，在 twitter.com 上，页面空白 0.5-1 秒，并且页面块位于： javascript必须渲染 json。这样做的缺点是，对于任何动态的东西（比如无休止的滚动或网格），我无论如何都必须创建 javascript 模板......所以现在我有服务器端 HAML 模板、客户端 javascript 模板等等更多缓存。
我的问题是，对于如何处理这个问题是否有共识？根据您的经验，将两者混合使用与 100% 使用其中一种相比，有哪些优点和缺点？
更新：
我尚未决定使用 100% javascript 模板的一些原因是：
- 性能。尚未正式测试，但从我所见，原始 html 比 javascript 生成的 html 跨浏览器渲染更快、更流畅。另外，我不确定移动设备如何处理动态 html 性能。
- 测试。我有很多与静态 HTML 配合良好的集成测试，因此切换到仅 javascript 需要 1) 更集中的纯 javascript 测试 (jasmine)，以及 2) 将 javascript 集成到水豚集成测试中。这只是时间和工作的问题，但可能意义重大。
- 维护。摆脱 HAML。我喜欢 HAML，它很容易编写，它可以打印漂亮的 HTML...它使代码干净，使维护变得容易。使用 javascript，没有什么比这更简洁的了。
- 搜索引擎优化。我知道谷歌处理ajax
/#!/path，但还没有掌握这将如何影响其他搜索引擎以及旧浏览器如何处理它。似乎需要进行重大设置。
I'm getting to the point on an app where I need to start caching things, and it got me thinking...
- In some parts of the app, I render table rows (jqGrid, slickgrid, etc.) or fancy div rows (like in the New Twitter) by grabbing pure JSON and running it through something like Mustache, jquery.tmpl, etc.
- In other parts of the app, I just render the info in pure HTML (server-side HAML templates), and if there's searching/paginating, I just go to a new URL and load a new HTML page.
Now the problem is in caching and maintainability.
On one hand I'm thinking, if everything was built using Javascript HTML Templates, then my app would serve just an HTML layout/shell, and a bunch of JSON. If you look at the Facebook and Twitter HTML source, that's basically what they're doing (95% json/javascript, 5% html). This would make it so my app only needed to cache JSON (pages, actions, and/or records). Which means you'd hit the cache no matter if you were some remote api developer accessing a JSON api, or the strait web app. That is, I don't need 2 caches, one for the JSON, one for the HTML. That seems like it'd cut my cache store down in half, and streamline things a little bit.
On the other hand, I'm thinking, from what I've seen/experienced, generating static HTML server-side, and caching that, seems to be much better performance wise cross-browser; you get the graphics instantly and don't have to wait that split-second for javascript to render it. StackOverflow seems to do everything in plain HTML, so does Google, and you can tell... everything appears at once. Notice how though on twitter.com, the page is blank for .5-1 seconds, and the page chunks in: the javascript has to render the json. The downside with this is that, for anything dynamic (like endless scrolling, or grids), I'd have to create javascript templates anyway... so now I have server-side HAML templates, client-side javascript templates, and a lot more to cache.
My question is, is there any consensus on how to approach this? What are the benefits and drawbacks from your experience of mixing the two versus going 100% with one over the other?
Update:
Some reasons that factor into why I haven't yet made the decision to go with 100% javascript templating are:
- Performance. Haven't formally tested, but from what I've seen, raw html renders faster and more fluidly than javascript-generated html cross-browser. Plus, I'm not sure how mobile devices handle dynamic html performance-wise.
- Testing. I have a lot of integration tests that work well with static HTML, so switching to javascript-only would require 1) more focused pure-javascript testing (jasmine), and 2) integrating javascript into capybara integration tests. This is just a matter of time and work, but it's probably significant.
- Maintenance. Getting rid of HAML. I love HAML, it's so easy to write, it prints pretty HTML... It makes code clean, it makes maintenance easy. Going with javascript, there's nothing as concise.
- SEO. I know google handles the ajax
/#!/path, but haven't grasped how this will affect other search engines and how older browsers handle it. Seems like it'd require a significant setup.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
持久的私有数据存储。
您需要一台服务器来存储具有不同级别的公共/私人访问权限的数据。您还需要一个用于安全闭源信息的服务器。您需要一台服务器来完成您不想在客户端上完成的繁重工作。复杂的数据查询最好留给您的数据库引擎。索引和搜索尚未针对 JavaScript 进行优化。
此外，旧浏览器还存在速度慢得多的问题。如果您没有运行 FF4/Chrome 或 IE9，那么客户端和服务器上的数据操作和页面构建之间存在很大差异。
我本人将尝试构建一个完全使用 MVC 框架和模板制作的 Web 应用程序，但仍使用服务器连接到安全且优化的数据库。
但一般来说，应用程序确实可以完全使用 JavaScript 并使用模板来构建。各种结构和 JavaScript 引擎已经足够先进来做到这一点。有足够多的流行框架可以做到这一点。纯 JavaScript Web 应用程序不再是实验和原型。
哦，如果我们为此推荐框架，请查看 backbone.js。
安全
我们不要忘记我们不信任客户端。我们需要服务器端验证。 JavaScript 是解释性的、动态的并且可以在运行时进行操作。我们从不相信客户的意见。
Persistant private data storage.
You need a server to store data with various levels of public/private access. You also need a server for secure closed source information. You need a server to do heavy lifting that you don't want to do on the client. Complex data querying is best left upto your database engine. Indexing and searching is not yet optimised for javascript.
Also you have the issues of older browsers being far slower. If your not running FF4/Chrome or IE9 then there is a big difference between data manipulation and page construction on the client and the server.
I myself am going to be trying to build a web application made entirely using a MVC framework and template's but still using the server to connect to secure and optimised database.
But in general the application can indeed be build entirely in javascript and using templates. The various constructs and javascript engines have advanced enough to do this. There are enough popular frameworks out there to do this. The Pure javascript web applications are no longer experiments and prototypes.
Oh, and if were recommending frameworks for this, then take a look at backbone.js.
Security
Let's not forget that we do not trust the client. We need serverside validation. JavaScript is interpreted, dynamic and can be manipulated at run time. We never trust client input.
我曾经混合使用这两种方法，但后来完全切换到客户端渲染，因为否则很难正确处理繁重的 JavaScript。作为完整的解决方案，可以推荐 JavaScriptMVC 框架的方法。
它有一个名为 EJS 的视图渲染引擎，可以将您的视图压缩为纯 JavaScript，以用于应用程序的生产构建。这使得它变得非常快（所有 HTML 都会预加载单个压缩的 JavaScript 文件，因此一旦您收到模型 JSON 数据，它就会被渲染）。我个人没有注意到 EJS 渲染和传输纯 HTML 之间的性能差异。
那么对于您的 API，遵循 REST 原则，缓存是关键约束之一。因此，如果您的应用程序正确支持 JSON 数据的 HTTP 缓存并使用压缩的客户端模板，您甚至可能会看到性能改进。
I used to mix these two approaches but then switched to client side rendering entirely because it was really hard to handle heavy JavaScript properly the otherwise. As a complete solution can recommend the approach of the JavaScriptMVC framework.
It has a view rendering engine called EJS which can compress your views into plain JavaScript for a production build of your application. That makes it extremely fast (all your HTML gets preloaded with your single compressed JavaScript file so it is rendered as soon as you receive your models JSON data). I personally couldn't notice a performance difference between EJS rendering and transferring plain HTML.
Then for your API, following the REST principles, caching is one of the key constraints. So if your application supports HTTP caching properly for JSON data and using your compressed client side templates you might even see a performance improvement.
我可能离这里很远，但是......
你看过 CouchDB 吗？ （顺便说一句，我与他们没有任何关系）我可能是错的，但你的情况听起来可能非常适合使用 Apache CouchDB 我自己还没有真正使用过它，但不久前我仔细研究了它，它是一个非常有趣的数据库。
它是一个基于文档的数据库，使用 REST API 进行连接（非常通用且易于使用）。它也非常以 JSON 为中心，速度非常快，占用空间也很小；他们说它也可以驻留在手机和其他嵌入式用途上，但同时应该具有极高的可扩展性（向上）。如果您是 JS 的大用户（听起来您就是这样），那么您可能会熟悉它。
我只是想它可能会以这里提出的多种方式派上用场，并认为我只是为了给您提供存储选项的想法:)
I could be way off here, but...
Have you ever looked at CouchDB? (I have no affiliation w/ them BTW) I could be way wrong, but your situation sounds like it may be a perfect fit for the use of the Apache CouchDB I haven't really used it yet myself but I took a good look at it a short while back and it is a very interesting database.
It is a document based database that uses a REST api for connections (very versatile and easy to use). It is also very JSON centric, very fast and a tiny footprint; they say it can reside on phones and other embedded uses too but at the same time is supposed to be extremely scalable (upwards that is). If your a big JS user (which you sound like you are) then you may be right at home with it.
I was just thinking that it may come in handy in any number of ways that have been proposed here and thought I'd chime in just to give you an idea for storage options :)