微信小程序这一套解决方案框架，确实和前端（frontend）的那一套比较像。在大约20年前，前端确实比较主要地是针对一个叫做浏览器（browser）的运行环境进行程序设计的。但是，随着时间的推移，前端现在已经将工作范围大大地拓展了。不过，如果就微信小程序这么一个话题来说，微信所处的地位，确实有点儿像浏览器，既然是针对零基础在讨论，那么了解到这个程度也就可以说是个能够继续学习的开端了。

WXS属于微信小程序框架的一部分，这个框架可以简单地看作是一种带交互的排版系统（浏览器也可以）。可以把任何小程序都看作是由一系列的页面（page）所组成，而在每个页面上，会放置若干种元素（element）或组件（component）。而任何一种元素或组件，都在页面上会有特定的外观和位置。而系统和用户都可能会针对这些元素或组件完成一些交互（interaction），而在交互完成以后，遵循着一些特定的逻辑（logic），这些元素和组件的外观和位置，会发生一些状态的变化（有些状态的变化是不可见的）。

高度抽象地说，这就是全部内容了。

在WXS出现以前，微信小程序框架提供了两个子系统：WXML，决定了页面上会有哪些元素或组件。WXSS，决定了页面上的元素和组件的外观和位置。这两个子系统统称为视图层（view layer），但是，如果要实现交互，光有视图层是不够的。因而，微信小程序框架原先是通过逻辑层（logic layer）来实现交互的，而逻辑层使用的，就是JavaScript。

熟悉前端的人可能会发现，其实微信小程序就对应于浏览器，WXML就对应于HTML，WXSS就对应于CSS。上面说的那些框架中的概念，都可以套用。

其实没有WXS，也已经够用了。视图层和逻辑层都有了，那为什么还要引入WXS呢？这主要是因为原先在WXML中，只能通过简单的数据绑定，来实现交互。交互的目的，从根本上说也就是能够动态地根据系统和用户的操作事件（event），来给出动态的响应。但是，原先要实现这一点，必须把视图层和逻辑层完全分开，在视图层中放置一些数据变量，然后一切事件响应都只能在逻辑层完成。逻辑层中的数据变了，视图层中的数据才能发生变化。这样的设计，有的时候会让人感觉不太方便。在针对浏览器的编程中，视图层和逻辑层就并不一定要分开，可以直接在视图层中完成很多事件响应等逻辑。这样对于开发者来说，有些时候比较直观一点。

那么，是不是可以允许直接把WXML和JavaScript混写呢？其实理论上是完全可以的。但是，微信小程序还是引入了WXS，这样，如同HTML和JavaScript可以混写一样，WXML也可以和WXS混写，但是WXML是不允许和JavaScript混写的，并且，在逻辑层中还是只能用JavaScript而非WXS，至少目前是这样设计的。

小结一下，看看WXS在整个微信小程序框架中的作用，和浏览器框架作一个对比。

<img src="https://pic2.zhimg.com/50/v2-5c86c1e0d030cb48d8fab461d7344cef_hd.jpg" data-rawwidth="496" data-rawheight="95" class="origin_image zh-lightbox-thumb" width="496" data-original="https://pic2.zhimg.com/v2-5c86c1e0d030cb48d8fab461d7344cef_r.jpg">

如果要对未来作一些预测，我感觉迟早在微信小程序开发框架中，WXS是要取代JavaScript的。

那么，零基础需要掌握的基础：

1. 程序设计基础：什么是变量？什么是函数？什么是控制结构？……等等，这些基础是要有的。

2. 掌握ECMAScript语言，因为JavaScript和WXS都是ECMAScript语言的子集，所以这也是一个比较重要的基础。ECMAScript可以从对象式语言的角度来理解，也可以从函数式语言的角度来理解，它和普通的所谓面向对象的语言有一些不同，比如它并没有类（class）的概念，却有原型（prototype）的概念……等等，这些都要学习。

3. 掌握小程序框架，包括视图层和逻辑层分别是具体由什么内容构成。在掌握了ECMAScript语言的基础上，这不会非常困难。

4. 掌握软件开发的一些流程，如：设计、编码、测试、上线等。刚才主要说的东西都属于编码（coding）这个环节，但整个流程远不止这一个环节。每个环节，对于软件开发来说，都很重要。对于现代软件开发来说，人们发明了各种各样的模型来使得流程尽可能地高效，并降低软件缺陷的发生率。对于这些模型有所了解，并找到自己在软件开发整个流程中的定位，对于一个软件工程师的成长是很关键的。