为什么说前后端分离不利于seo

seo本质是一个向另一个发起请求，解析请求内容。但一般来说搜索引擎是不回去执行请求到的js的。也就是说，如果一个单页应用，html在端还没有渲染部分数据数据，在浏览器才渲染出数据，而搜索引擎请求到的html是没有渲染数据的。这样就很不利于内容被搜索引擎搜索到。所以服务端渲染就是尽量在发送到浏览器前页面上就是有数据的。

为什么电商不需要后端 为什么电商不赚钱还要做

为什么电商不需要后端 为什么电商不赚钱还要做

第二个问题，一般的数据逻辑作是放在后端的。排序这个如果仅仅是几条数据，前后端排序开起来是一样的，如果是有1000条数据，前端要排序就要都请求过来。这样显然是不合理的。

网站开发中的前后端分离的问题

对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。

这个说法是不合适的，打个比方，别人问的是“如何解决家禽把蛋生在水草边的问题？”，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答“不让去水边就行了”，这显然不在点子上。

这两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了

少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。

那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：

- 性能优化（尤其是外部资源的管理与发布，请求合并等等）

- 协作的顺畅性（已形成模板的界面片段的返工等问题）

那么，模板到底应该在什么地方跟数据结合？

这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，距很明显。

所以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就

是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。

所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。

至于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node

做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。

这时候回头看你问题中的这句：

> 前后端分离的意思是，前后端只通过 JSON 来交流，组件化、工程化不需要依赖后端去实现。

我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。

组件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗？是数据吗？是数据和模板的结合体吗？没法回答。在此，我说一

句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不

带逻辑的界面模板。

近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问

题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改

变，用这个方案去解决的话，有些牛刀杀鸡的感觉。

关于B类项目的组件化，我之前那个没写完的系列是关于它的，但经过近一年多的思考，我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我，这就写。

电子商务的后端指的是什么啊？能用名词解释更好！

电子商务后端就是，现在就是利用大型的后端进行数据的采集与分析，然后得到大数据，在以后的网络就就有了庞大的数据支持了。希望我的回答能帮到您。

后台？ 一般是上运行的后台程序+数据库

前端开发和后端开发有什么区别

1.前端框架一般指用于简化网页设计的框架，比如，jquery，extjs，bootstrap等等，这些框架封装了一些功能，比如html文档作，漂亮的各种控件(按钮，表单等等)。

2.使用前段框架可以降低界面开发周期和提高界面的美观性。

3.有些框架比较轻量，比如jquery，有些框架比较重量，比如extjs。一般来说重量的框架会封装更多的功能，比如extjs，封装的grid控件有很强的数据展示和作功能。

1.对用户的价值：

大部分产品对用户的核心价值是功能和内容提供的，而不是由表现层和交互。譬如支付、电商、、交友。

后端解决有还是无的问题，开天辟地。

前端解决有了以后好用的问题，锦上添花，在竞争激烈的领域确实至关重要。

2.技术广度和难度：

广度上后端工作在领域，能控制的硬件基本没有极限，CPU、存储、网络、集群等等，因此技术领域极广。一个的后端需要掌握或了解大量技术如：并发、业务架构、数据库、几打流行框架、性能调优、分布式计算、集群架构、容灾、安全、运维等等，一层挖透了还有下一层。几十年计算机发展历史中大量的技术沉淀在端。

Web前端一直工作在一个浏览器盒子里，先天不足，能承载的可能性太小，技术广度不足。

深度上，现代计算机领域的难题如大规模负载，海量数据处理，实时计算也是后端的，前端集中在表示层，这一层虽然也很复杂，但能称之为难题的技术几乎没有，也很容易。

前端要说深度也不是没有，但这一步需要跨到图形领域(如网页游戏)，不是常见场景。

说到底前端代码能控制的硬件确实不如后端，因此在技术上，前端更容易。现在为什么说前端会比后端更值钱呢?那是因为前端对硬件的控制能力提升了(html5odejobile)，而后端分化得比较厉害，有一批后端专门只写业务逻辑，框架是别人写的，系统架构是别人搭的，跑在云里，连机器物理地址都不知道。世人眼里可能觉得这种写MVC代码的人才是后端，这种被限制在一个“虚拟盒子”里的后端确实不怎么难上手。

一般而言网上说的互联网行业的技术含量排名大概是这样：

产品<设计师<前端<后端<其他更高级职位，比如算法工程师等等。

在广大中小公司，很多产品都是不会代码，不会设计。很多技校学艺术设计的毕业生，当上了美工。这些都是真，所以能力低，干的人多，自然就低。然而，你问Google设计师挣多少了嘛?

门槛低不等于技术含量低。

电商前后端类目分离设计

类目，即商品分类树，如下图所示，即为前端分类树。

次设计电商前后端的产品，在参考主流电商分类时，都会发现商品分类并不是严格按照商品的属性去呈现，而是带有强烈的运营属性。对，没错，前端的分类是强运营属性的产品设计思路。那后端类目是否应该与前端使用同一套呢？是前后端类目分离设计。

我们首先思考一下，前后端类目的使用人群是谁，他们的使用场景是什么，他们使用这个功能要实现什么价值。

前端类目

使用人群：消费者

使用场景：想找商场同款衣服；想找吃鸡不卡的手机；……

实现价值：快速找到自己心目中的商品。

后端类目

使用人群：商家或者供应链人员

使用场景：商品发布，仓库库存管理。

实现价值：快速发布商品，仓库库位区分管理等。

通过对比前后端类目，很容易就发现前后端类目有着完全不一样的设计方向。

后端类目。后端类目的人群主要是商家，主要用于商品管理，有以下设计要求：

1. 后端类目相对固定，不宜经常修改或者删除。有商品时，更不能删除。

2. 后端类目在四层之内，过多层级分类反而会造成管理上的不便。

3. 赠品放在其他-赠品类目下，可以避免消费者误解。

4. 当商品较多时，商品属性、销售属性等与基础类目进行关联，在商品发布时会更简单快捷。

前端类目。前端类目主要用户为消费者，目的是方便消费者找到商品。

1. 不同平台有不同的类目。这是不同渠道用户群异造成的，如果异很小，可以一致。

2. 对于B2B2C的电商，需要提供买家自定义类目的功能。

3. 前端类目可以支持对应后端某子类目和某些属性的组合，如手机这个子类目与8GB内存属性这样的组合，前端显示为畅快吃鸡手机分类。