为什么我不使用Javascript和Javascript HTML模板构建整个Web应用程序？ [英] Why don't I just build the whole web app in Javascript and Javascript HTML Templates?
问题描述
-
>在应用程序的某些部分，通过抓取纯JSON并通过类似Mustache，jquery.tmpl等来渲染表格行（jqGrid，slickgrid等）或花哨的div行（如在New Twitter中） / li>
- 在应用程序的其他部分，我只是在纯HTML（服务器端HAML模板）中呈现信息，并且如果搜索/分页，我只需转到一个新URL并加载新的HTML页面。
现在问题在于缓存和可维护性。
一方面，我在想，如果所有东西都是使用Javascript HTML模板构建的，那么我的应用程序只能提供HTML布局/外壳和一堆JSON。如果你看Facebook和Twitter的HTML源代码，那基本上就是他们在做什么（95％json / javascript，5％html）。这将使得我的应用程序只需要缓存JSON（页面，操作和/或记录）。这意味着无论你是一些远程api开发者访问JSON api还是海峡网络应用程序，都会触发缓存。也就是说，我不需要2个缓存，一个用于JSON，一个用于HTML。这似乎是它将我的缓存存储减少了一半，并简化了一些事情。另一方面，我在想，从我看来，已经看过/有经验，生成静态HTML服务器端和缓存，似乎是更好的性能明智的跨浏览器;您可以即时获取图形，而无需等待JavaScript的时间以呈现它。 StackOverflow似乎在纯HTML中做了所有事情，Google也是如此，你可以告诉......一切都会一次出现。请注意，尽管在 twitter.com 上，该页面在.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，没有什么简洁的。
- SEO 。我知道谷歌处理ajax
/＃！/路径，但没有掌握这将如何影响其他搜索引擎以及旧版浏览器如何处理它。似乎需要进行重大设置。 p> - 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.
- 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.
您需要一台服务器来存储具有各种公共/私人访问级别的数据。您还需要安全的封闭源信息的服务器。您需要一台服务器来完成您不想在客户端执行的繁重工作。复杂的数据查询最好留给您的数据库引擎。索引和搜索功能尚未针对JavaScript进行优化。
另外，您还遇到旧版浏览器速度较慢的问题。如果你没有运行FF4 / Chrome或IE9，那么在客户端和服务器上的数据操作和页面构建之间会有很大的区别。
我自己会尝试构建完全使用MVC框架和模板制作的Web应用程序，但仍然使用服务器连接到安全和优化的数据库。
但通常情况下，应用程序确实可以完全使用JavaScript构建并使用模板。各种结构和JavaScript引擎已经足够先进的做到这一点。有足够的流行框架来做到这一点。纯JavaScript Web应用程序不再是实验和原型。
哦，如果是为此推荐框架，请查看 backbone.js 。
安全
我们不要忘记我们不信任客户端。我们需要服务器端验证。 JavaScript是被解释的，动态的并且可以在运行时被操纵。我们从不相信客户的意见。
I'm getting to the point on an app where I need to start caching things, and it got me thinking...
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:
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和Javascript HTML模板构建整个Web应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
