这是一个创建于 2506 天前的主题，其中的信息可能已经有所发展或是发生改变。
Ajax 直接根据业务实体生成并返回 html 片段是否一定是糟糕的设计？
 | 1 Vegetable 2019-01-24 00:08:54 +08:00 via iPhone 想洗一下发现功力不够，我觉得肯定有合适的场景，不比其他方案差，但是我想不出来… |
 | 2 qq292382270 2019-01-24 00:12:10 +08:00 要么服务端返回 html, 要么 js 通过返回的 data 拼接成 html,并未有多大的区别吧 . |
 | 3 CODEWEA 2019-01-24 00:15:06 +08:00  1 技术方案一定要符合业务实际需求 直接返回 HTML 片段的优势有：减少客户端负载，减少维护成本，客户端体验更流畅。 劣势：逻辑拼接增加服务器负载，技术人员会看起来很 low，不符合潮流，不利于接口重用（要考虑是否真的需要重用，已经重用成本） |
| 4 CODEWEA 2019-01-24 00:15:33 +08:00 以及重用成本 |
 | 5 akatquas 2019-01-24 00:16:36 +08:00 via iPhone 1 ajax 原名就是 XMLHttpRequest 啊... 返回 xml 没毛病，只不过现实场景不多用了，http 请求中大多都用字符串如 json 了而已。 我这个洗的还好吗？ |
 | 6 saulshao 2019-01-24 00:17:46 +08:00 返回 HTML 片段绝大多数是糟糕的设计。 需要用到 Ajax 的时候，都是将结果作为某个整体 HTML 页面的一部分。 大多数的设计都是返回 Json/XML 甚至是自定义的字符串。 对比返回 HTML 片段的设计，如果返回的 HTML 片段不能作为整体页面的一部分来显示，典型的例子是 Ajax 返回一个 HTML 表格，以 Table 开头，有的时候需要把这个表格的某列显示为一个链接，有的时候则不需要。那么就是要么设计 2 个不同的 Ajax API，要么就分析 HTML 片段，显然这都不是什么很好的办法。 |
 | 8 580a388da131 2019-01-24 00:23:42 +08:00 via iPhone 你把数据和样式分开，最后送到客户端 html，这样应该凑合吧。 |
 | 9 akira 2019-01-24 00:23:49 +08:00 如果前端和后台都是你一个人在做，以后也一直是你一个人在维护，那没关系 |
 | 10 szx237560 2019-01-24 00:25:35 +08:00 |
 | 11 KasuganoSoras 2019-01-24 00:26:36 +08:00 并不觉得有什么不好，有时候直接返回 html 还是挺方便的 比如： https://mirror.ssr.wine/ 评论区 AJAX 轮询、选择服务端分类 还有： https://www.zerobbs.net/ 帖子列表翻页，评论区 WebSocket 怎么方便怎么来，看自己喜欢。除非你是在帮别人做项目，那就按照别人的要求来做吧 就我个人而言，因为我并不擅长前端的 Js 那些的，我觉得直接在服务端写 HTML 更方便点，自然我会选择在 AJAX 里返回 HTML。 我这个洗的还好吗？ |
 | 12 FEDT 2019-01-24 00:32:45 +08:00 via iPhone Pjax，看看 gayhub |
 | 13 yunye 2019-01-24 00:47:06 +08:00 turbolinks 岂不是 low 翻天了 |
 | 14 azh7138m 2019-01-24 00:53:17 +08:00 via Android gitlab 也这么操作，问题不大 |
 | 15 byis 2019-01-24 01:01:52 +08:00 via Android pjax 喵喵喵? |
| 16 byis 2019-01-24 01:02:33 +08:00 via Android 虎嗅网就是这样的 |
 | 17 masker 2019-01-24 01:12:22 +08:00 via Android 不都是字符串咩？ |
 | 18 msg7086 2019-01-24 01:59:20 +08:00 都可以，根据实际需要返回数据就行了。 |
 | 19 Archeb 2019-01-24 02:20:08 +08:00 一般应用在 pjax |
 | 20 hundan 2019-01-24 07:26:53 +08:00 via Android 我知道新浪微博的评论加载是这样的 |
 | 21 ChefIsAwesome 2019-01-24 08:39:55 +08:00 跟套模板一个道理。前端写好 html 给后端套，之后再要改了就费劲。 |
 | 22 66beta 2019-01-24 08:46:42 +08:00 via Android 1 你这是模块化服务端渲染，简称 mssr，说不定成为今年流行！ 可还行？ |
 | 23 yinqi025 2019-01-24 08:59:32 +08:00 这样直接返回 Html 不说性能什么的, 维护工作就很麻烦!!!!谁知道你后台组装了多少 html |
 | 24 ebingtel 2019-01-24 09:03:59 +08:00 脱离应用场景和需求讨论这个有啥意义…… |
 | 25 hasbug 2019-01-24 09:08:06 +08:00 比较难配合工作，后期维护成本也高，反正 |
| 26 hasbug 2019-01-24 09:09:05 +08:00 6 年前都这么干，然后天天页面布局错乱，找了半天，后端自己拼的 html 少各种结束标签 |
 | 27 zwb9412 2019-01-24 09:11:51 +08:00 via Android 1 遇到过返回 html 的 里面还带 js 脚本，js 脚本有 bug 极难调试。。 |
 | 28 brofen 2019-01-24 09:15:24 +08:00 微博好像是这么干的 |
 | 29 keelii 2019-01-24 09:21:32 +08:00 恰恰相反，很多时候返回 html 其实更方便，也更具有跨应用的复用性。唯一问题就是 HTML 代码比较冗余，需要考虑 HTTP 请求传输数据量的问题。 |
![fkdog](https://cdn.v2ex.com/gravatar/0701801586b1b3ba02b392ac42bce60e?s=48&d=retro") | 30 fkdog 2019-01-24 09:29:41 +08:00 微博、apple 官网各种这么干。 根据自己实际来。 |
 | 31 vinsony 2019-01-24 09:32:28 +08:00 没毛病，10 年前我就是这么干的 |
 | 32 qinxi 2019-01-24 09:33:23 +08:00 微博翻页就是这样啊 |
 | 33 carlclone 2019-01-24 09:34:35 +08:00 pjax , 没毛病 |
 | 34 guanhui07 2019-01-24 09:38:12 +08:00 区别不大 看那一层套上模板。 |
 | 35 sambawy 2019-01-24 09:39:13 +08:00 脱离现实场景聊这个就是耍流氓 |
 | 36 lymi2771 2019-01-24 09:45:30 +08:00 via iPhone 我觉得没有任何问题 有人说不利于接口复用 我觉得这个 route 就是需要返回一个 view 也没什么问题吧？ 不然普通的页面怎么访问的呢 服务端渲染这样的场景我觉得还是很多的 |
 | 37 zst 2019-01-24 09:46:40 +08:00 via Android twitter 也这么干的 23333 |
 | 38 BOYPT 2019-01-24 09:48:39 +08:00 没问题呀，而且这个技术还有专门的名词：服务器端渲染 |
 | 39 ioven 2019-01-24 09:50:28 +08:00 很 low，可自己用的很爽 |
 | 40 Yiki 2019-01-24 09:59:45 +08:00 传 svg 算不算 html 片段 前端也省事儿，不能太片面吧 |
 | 41 mostkia 2019-01-24 10:08:24 +08:00 只要前后台不打起来，用什么交换数据都是 ok 吧。。我是前后台都做，感觉无所谓，但一般使用 json 吧，数据和表现分离，后期好维护一些，有时候想改改版面也更方便，但又需要的情况下，直接返回 html 我感觉并无什么不妥。 |
 | 42 FakeLeung 2019-01-24 10:10:48 +08:00 low 咋滴啦？用的爽就好了。 |
 | 43 doodlewind 2019-01-24 10:24:45 +08:00 我是搞前端编辑器的，简单来说，假如我的业务场景（编辑器）动态性非常强，那么一些插件就需要依赖后端的能力来生成 html 返回给前端，这时候接口里包含 html 片段也是可能的呀，至少据我所知 confluence 的富文本编辑器就是这么干的。 当然了 confluence 这个编辑器的架构设计是前后端不分离的，编辑器插件都是 jar 包，现在的前端架构设计应该可以杜绝这样的实践了吧。 |
 | 44 SakuraKuma 2019-01-24 10:27:44 +08:00 很多都这么干好嘛.. |
 | 45 tao1991123 2019-01-24 10:31:49 +08:00 pjax 没毛病 |
 | 46 miniwade514 2019-01-24 10:40:27 +08:00 简单地理解，这个方案只是把 HTML 放到服务端渲染了。 应该也不存在接口不好复用的问题，你在服务端把渲染 HTML 的服务和数据服务拆分成两层，数据服务也是可复用的。 适合前端交互不复杂的场景。 |
 | 47 litbear 2019-01-24 13:55:11 +08:00 pjax 啊 |
 | 48 meepo3927 2019-01-24 14:54:58 +08:00 后端写 HTML 体验很差吧 ， 字符串拼接？ |
 | 49 Dogergo 2019-01-24 14:59:53 +08:00 有一个场景，新旧产品都需要我点击名称的时候弹出一个弹窗，但是根据新旧产品的不同，弹窗样式包括数据个数发生了很大变化，我弹窗层用的是 layer，我放在前端 js 里去判断是不是不太好，而我如果放在服务端，我之需要一个接口，拼接好 html，分配变量进去，返回，很完美，代码复用性更好。 |
Select Language