大家好,我卡颂。

这么多年大家习惯了应用JSX形容UIReact。甚至局部场景下应用Vue时也会抉择JSX而不是模版语法

如同所有就这么自然而然产生了。

然而,如果梳理历史的走向,模版语法才是更天然的抉择。接下来让咱们看看React抉择JSX背地的逻辑是什么?这是React现在生态凋敝的关键因素么?

本文参考HTML模板语言纵览

模版语言简史

前端在有足够复杂度之前都是作为后端MVC框架的V(view,即视图层)存在的,操作view的支流办法是模版语法

虽说PHP是最好的语言,但在晚期PHP更多是作为HTML模版语言呈现的,这也能从他的全称Hypertext Preprocessor(超文本预处理器)中窥探出一丝端倪。

当浏览器申请网页时,服务端会执行模版中的PHP代码,将填充了变量值的HTML会作为数据返回。

比方如下模版,name会被填充为变量值:

<h1>  <?php echo "My name is {$name}"; ?></h1>

很多服务端语言都实现了PHP格调的模版语法,比方:

  • 基于JavaJSP
  • 基于PHP二次封装的smarty
  • 基于EcmascriptEJS

这类模版语法尽管性能全面,然而当页面结构复杂时,逻辑(PHP代码)会不可避免的和UIHTML)混淆在一起。

为了更好的展现UIGithub的联结创始人Chris Wanstrath开发了Mustache

这是一款重UI而轻逻辑的模版解析引擎,支流编程语言简直都有各自的Mustache实现。

对于下面的例子,Mustache语法为:

<h1>  My name is {{name}}</h1>

Mustache能直观的表白UI,然而缺失对逻辑的表达能力。更多模版语法则尝试在UI与逻辑之间寻找均衡。

比方DjangoDTL(Django Template Language)除了应用与Mustache雷同的 {{}} 语法表白UI中的变量,还蕴含大量的常见逻辑,比方:

  • if else等流程管制逻辑

    {% if condition %}  ... display{% endif %}
  • for in迭代逻辑

    <ul>{% for user in userList %}  <li>{{ user.name }}</li>{% endfor %}</ul>
  • 过滤器
/* 将name转化为小写模式 */<p>{{ name | lower }}</p>

现如今,前端框架的模版语法中能够看到很多服务端曾应用的模版语法的影子。

如果你是个服务端工程师,看到如下Vue模版语法时想必会很亲切:

<h1>my name is {{name | lower}}</h1>

所以,从后端view层拆散并逐步倒退的前端框架,最合乎直觉的形式就是采纳模版语法形容视图,比方09年呈现的景象级前端框架angular

然而,React并不这么认为。

用逆向思维思考

前端框架须要形容两样货色 —— UI与逻辑。

模版语言的底层逻辑是:即然前端应用HTML形容UI,那么咱们就扩大HTML语法,让他能形容逻辑。

即:从UI登程,扩大UI,形容逻辑。

那咱们换个思路,在前端用什么形容逻辑呢?JS

那咱们能不能从逻辑(即JS)登程,扩大逻辑,让他能形容UI,不就达到同样的成果吗?

这,就是JSX —— 一种JS语法糖。

后记

因为JSX以逻辑为终点,所以能轻松形容简单的UI变动。这使得React社区的晚期参与者能够疾速实现各种简单的根底库,丰盛社区生态。

对于前端框架的选型,一个重要的考量是:社区生态是否凋敝?

换言之,对于日常业务开发遇到的需要,是否很疾速在社区中找到成熟的解决方案?

我的项目一旦确定了技术选型,中途再切换其余技术栈会付出极高老本。这进一步推动更多开发者参加社区建设,最终造成源源不断的正反馈。使得React长期霸榜工程师最违心应用的前端框架

这所有,从另辟蹊径创造JSX那一刻就埋下了伏笔。

欢送退出人类高质量前端框架钻研群,带飞