内容（博客、文章）修订：服务器端还是 JS？
计算文本的两个版本之间的差异（并添加相应的“已删除”和“已添加”CSS 类）的最佳位置是什么？
这应该在服务器上完成还是让客户端 JS 处理这个更好？
What is the best place to calculate differences between two versions of a text (and add corresponding "removed" and "added" css classes)?
Should this be done at the server or is it better to have client-side JS handle this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非您做了一些疯狂的事情，否则如果您正在查看简单的 DOM 内容，则不可能仅使用 JS 来确定修订版本。
您将需要使用服务器端代码和 JS 的组合来处理修订检查以创建这样的系统，但是像
removed和added这样的类可能应该是创建服务器端。Unless you do something crazy, it shouldn't be possible to determine the revisions with just JS if you're looking at simple DOM content.
You'll want to use a combination of server-side code and JS to handle the revision checking to create a system like this, but classes like
removedandaddedshould probably be created server-side.我认为这可能是一个规模问题。如果您的服务器可以处理负载，请在服务器端进行比较。这减轻了用户（硬件）进行计算的负担，并且应该会带来更好（阅读：更快）的体验。但是，如果您同时进行的操作太多而无法及时处理所有这些操作，或者您的服务器端环境崩溃和/或内存不足，请务必将其推送到用户。如果您有理由期望将来会出现这种情况，那么这是现在就实施它的一个非常令人信服的理由 - 如果您将处理外包给用户，您的服务将会更好地扩展。现在我已经写完了，我倾向于将其作为客户端计算 - 您将负载分配出去而不是合并它。
I think this may be a question of scaling. If your server can handle the load, make the comparison server side. This relieves your users (hardware) of the burden of doing the calculation, and should result in a better (read: faster) experience. However, if you've got too many of these going on at once to handle them all in a timely manner, or else you're crashing and/or running out of memory in your server side environment, by all means push it to the users. If you have reason to expect this in the future, then that's a pretty compelling reason to implement it now - your service will scale a lot better if you're farming out your processing to your users. Now that I am done writing, I am leaning to making this a client-side calculation - you distribute the load out instead of consolidating it in.