mvc获取客户端浏览器
Over the past year I conducted performance audits on a handful of sites that all used client-side MVC’s, typically Angular but not always. Each site had their own optimizations that needed to take place to improve performance. Yet a pattern emerged: client-side MVC’s were the major bottleneck for each. It slowed down the initial rendering of the page (particularly on mobile) and it limited our ability to optimize the critical path.
在过去的一年中，我对少数几个都使用了客户端MVC的站点进行了性能审计，这些站点通常是Angular，但并非总是如此。 每个站点都需要进行自己的优化以提高性能。 但是出现了一种模式：客户端MVC是每个服务器的主要瓶颈。 这减慢了页面(尤其是在移动设备上)的初始呈现速度，并且限制了我们优化关键路径的能力。
So I get a great deal of happiness from reading posts from much smarter folks than I who are rallying against this all-to-common mistake.
因此，与那些反对这种常见错误的人相比，我从比我聪明得多的人那里读文章而获得了极大的幸福。
Back in December, The Filament Group analyzed a bunch of client -side MVC frameworks to see their impact on the initial load time of a page. The results to render a simple To-Do app were disappointing:
早在12月， The Filament Group就分析了一堆客户端MVC框架，以了解它们对页面初始加载时间的影响。 呈现一个简单的To-Do应用程序的结果令人失望：
- Ember: 5s on a Nexus 5, 3G connection 灰烬：在Nexus 5、3G连接上5秒钟
- Angular: 4s on a Nexus 5, 3G connection 角度：Nexus 5、3G连接时为4s
- Backbone: 1s on a Nexus 5, 3G connection 骨干网：在Nexus 5、3G连接上为1s
Only Backbone scores in a way that is at all acceptable, particularly in a world where people are trying to break the 1000 SpeedIndex barrier.
只有骨干网的分数完全可以接受，尤其是在人们试图突破1000 SpeedIndex障碍的世界中。
And just last month PPK wrote up his thoughts on client-side templating. The full post is well worth your time, but for those of you who would like to cut to the chase:
就在上个月，PPK写下了他对客户端模板的想法 。 完整的帖子非常值得您花时间，但是对于那些想要追逐的人来说：
I think it is wasteful to have a framework parse the DOM and figure out which bits of default data to put where while it is also initialising itself and its data bindings.
我认为，拥有一个框架来解析DOM并找出默认数据的哪些位(同时还要初始化自身及其数据绑定)会很浪费。
and:
和：
Populating an HTML page with default data is a server-side job because there is no reason to do it on the client, and every reason for not doing it on the client.
用默认数据填充HTML页面是服务器端的工作，因为没有理由在客户端上进行操作，也没有理由不在客户端上进行处理。
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
我之前已经说过 ：如果您的客户端MVC框架不支持服务器端呈现，那是一个错误。 它削弱了性能。
It also limits reach and reduces stability. When you rely on client-side templating you create a single point of failure, something so commonly accepted as a bad idea that we’ve all been taught to avoid them even in our day-to-day lives.
它还限制了范围并降低了稳定性。 当您依赖于客户端模板时，您会创建一个单点故障，这是一个公认的坏主意，以至于我们所有人都被教导要避免这种情况，即使在我们的日常生活中也是如此。
“Don’t put all your eggs in one basket.”
“不要把所有鸡蛋都放在一个篮子里。”
It’s pretty good advice in general, and it’s excellent advise when you’re wading through an environment as unpredictable as the web with it’s broad spectrum of browsers, user settings, devices and connectivity.
通常，这是一个很好的建议，当您在各种各样的浏览器，用户设置，设备和连接性的环境中无法像Web那样难以预测时，它是极好的建议。
This might sound like I’m against these tools altogether. I’m not. I love the idea of a RESTful API serving up content that gets consumed by a JavaScript based templating system. I love the performance benefits that can be gained for subsequent page loads. It’s a smart stack of technology. But if that stack doesn’t also consist of a middle layer that generates the data—in full and on the server—for the first page load, then it’s incomplete.
听起来好像我完全反对这些工具。 我不是。 我喜欢RESTful API提供可被基于JavaScript的模板系统使用的内容的想法。 我喜欢后续页面加载可以获得的性能优势。 这是技术的智能堆栈。 但是，如果该堆栈也不由中间层组成，该中间层在第一页加载时完整地在服务器上生成数据，则它是不完整的。
This isn’t idealism. Not only have I seen this on the sites I’ve been involved with, but companies like Twitter, AirBnB, Wal-Mart and Trulia have all espoused the benefits of server-side rendering. In at least the case of the latter three, they’ve found that they don’t have to necessarily give up those JS-based templating systems that everyone loves. Instead, they’re able to take advantage of what Nicholas Zakas coined “the new web front-end” by introducing a layer of Node.js into their stack and sharing their templates between Node and the client.
这不是理想主义。 我不仅在参与过的网站上看到了这一点，而且Twitter ， AirBnB ， 沃尔玛和Trulia等公司都拥护服务器端渲染的好处。 至少在后三个案例中，他们发现他们不必放弃每个人都喜欢的基于JS的模板系统。 相反，他们可以通过在堆栈中引入Node.js层并在Node和客户端之间共享模板来利用Nicholas Zakas创造的“新的Web前端” 。
This is where it gets interesting and where we can see the real benefits: when we stop with the stubborn insistence that everything has to be done entirely on the client-side and start to take advantage of the strengths of each of the layers of the web stack. Right now most of the progress in this area is coming from everyday developers who are addressing this issue for their own sites. Ember is aggressively pursuing this with FastBoot and making exciting progress. React.js emphasizes this as well. But most of the other popular tools haven’t made a ton of progress here.
在这里，它变得很有趣，并且可以看到真正的好处：当我们顽固地坚持认为一切都必须完全在客户端上完成并开始利用Web各个层的优势时，就会停止工作。堆栈。 目前，该领域的大多数进展来自日常开发人员，他们正在为自己的网站解决此问题。 Ember正在FastBoot积极追求这一目标，并取得了令人兴奋的进展 。 React.js也强调了这一点。 但是大多数其他流行工具在这里都没有取得很大进步。
I sincerely hope that this starts to change, sooner rather than later. Despite what is commonly stated, this isn’t a “web app” (whatever that is) vs “website” issue.
我衷心希望这种情况早日有所改变。 不管怎么说，这都不是“ Web应用程序”(无论是什么)还是“网站”问题。
It’s a performance issue.
这是性能问题。
It’s a stability issue.
这是一个稳定性问题。
It’s a reach issue.
这是触及率问题。
It’s a “building responsibly for the web” issue.
这是“负责任地为网络建设”的问题。
翻译自: https://timkadlec.com/2015/02/client-side-templatings-major-bug/
mvc获取客户端浏览器