零基础的人能学好HTML5开发技术吗
前端HTML5编程相对来说比较简单，初次接触的话，建议还是以熟悉标签和属性为主，一个简单的记事本就行，后期熟悉后，可以使用一些专业的开发工具，了解一些常用的前端框架，提高开发效率，下面我大概介绍一下：
HTML5学习资料
1.这个网上的资料非常多，几乎牵扯到编程的网站，都会有前端HTML5教程，像菜鸟教程、慕课网、w3cschool等，都可以，当然，你也可以找一本专业的HTML5书籍，一边学习一边练习：
2.初级接触HTML5的话，建议还是以掌握好基本功为准，像常见的标签、属性等，不需要自动补全、智能提示等功能，一个简单的记事本就行，如下，编写完成后，保存为html文件，然后用浏览器打开查看效果：
3.这里你也可以选择一些在线编程的网站，前面那几个编程网站都有这个功能，直接编程，查看效果，也很方便：
HTML5编程软件
这个就很多了，几乎所有的编程软件都支持HTML5开发，下面我介绍几个不错的前端软件，感兴趣的朋友可以自己尝试下载一下：
1.VS Code：这个软件在前端开发中应该使用的比较广泛了，微软开发的一个开源、免费、跨平台的轻量级代码编辑器，支持代码高亮、自动补全、语法提示、Git等常见功能，插件扩展丰富，生态环境良好，是一个很不错的前端开发软件：
2.Atom：这个软件基本功能和VS Code差不多，也是一个非常不错的代码编辑器，由GitHub专门为广大程序员开发，免费开源、跨平台，插件扩展也很丰富，自动补全、语法检查等非常功能，对于前端编程来说，也是一个不错的选择：
3.WebStorm：这是一个专业的Web开发工具，Jetbrains公司开发的产品，相对于前面两个软件来说，比较复杂，当然，功能也更强大，除了常见的自动补全、Git等功能外，这个软件还支持代码重构、代码分析、单元测试等功能，只不过不是免费的，试用期过后就需要付费：
当然，还有许多其他前端编程软件，像Sublime Text，HBuilder，Notepad++等，都可以，选择适合自己的一个就行。
前端框架
为了提高项目开发效率，许多项目在开发的过程中，都会用到一些前端框架，像Vue，React，Angular *** 等，后期的学习中，可以了解一下这些框架，它们的有哪些异同，以及优缺点等，这个网上的资料也很丰富，感兴趣的话，可以搜一下：
就分享这么多吧，初学HTML5编程的话，建议还是以熟悉标签和属性为准，掌握好基本功，后期可以学习一下相关框架，做一些简单项目，积累一下经验，希望以上分享的内容能对你有所帮助吧，也欢迎大家评论、留言。
一个小程序的实施技术方案
微信小程序上线大半年，大部分技术原理也有文章介绍了，本文尝试从需求出发探讨微信小程序技术方案的来源，以及最近公测的支付宝小程序技术方案的考量。
微信小程序
微信小程序的需求是让第三方开发者可以接入，可以使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求，最简单的实现方案是：让外部开发者开发纯H5应用，在微信的 H5 容器里打开，容器提供微信 native 接口，就行了。在有小程序之前，已经有很多这样的业务接入，像京东购物，钱包里的各种友商大众点评/滴滴出行等，都可以认为是一个“小程序”，内嵌在微信里，能调用微信 native 接口，是不是沿着这种模式下去，把相应的接口开放给第三方，再提供个入口就行了？
实际上这种简单的方案不能满足需求，在产品上微信小程序有另外两个很重要的需求：
管控。作为一个平台必须对接入的应用有管控能力，必须能尽量精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，H5 的方式太过自由，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。另外H5开发质量参差不齐，平台也无法管控，这对于一向有洁癖的微信来说无法接受。
体验。作为一个“小程序”需要让体验接近原生，而上述像京东购物这些普通 H5 页面的体验不太行，包括启动速度/页面切换流畅度都有问题，跟原生体验没法比。
所有小程序的技术方案都是为了这两个需求服务。
管控
为了满足管控的需求，技术上微信做了两个事情：小程序框架和分离 *** 运行环境。
框架/DSL
H5太自由，首先要做的就是限制它的自由，怎样限制？自然是做个框架套住，让开发者只能按框架的规则去开发。那应该使用怎样的框架？
在 PC SNS 时代，Facebook 做开放平台时有类似的场景，为了第三方开发者能在 Facebook 平台上开发，同时又能限制住开发者的权限，Facebook 要求开发者使用自定义的一套 DSL(FBML)去开发，而这个 DSL 能怎么写，最终能转成什么，如何执行，都是平台说了算，同时也可以很方便做代码扫描和审查。
小程序正好能借鉴这样的设计思路，界面不使用 HTML 开发，而是自定义一套 DSL，这样就可以很容易配合审核/代码扫描/域名限制等系列措施去做管控，这就是小程序这一套框架的来源。这套框架通过 wxml 去描述界面，wxss 描述样式，js 去处理逻辑和数据，再通过工具一系列处理把这些转为 HTML/CSS/ *** 显示在 webview 上，并处理界面交互和数据更新。
这样用一套框架去限制开发方式，再造一层 DSL，除了管控外还有一个好处，就是容易进行针对性优化，DSL 最终转成什么，最终如何执行渲染都由框架决定，上层不感知，可以做成由 webview 渲染，有条件也可以用类似RN的方案自己实现渲染层。
*** 环境
通过框架限定开发方式后，管控上还有个问题，就是如何限制应用端类 *** 语言调用dom API？小程序跑在 webview 上，渲染时必然要通过 *** 操作 dom，如果小程序框架和应用 *** 代码都有权限操作 dom，应用可能会通过各种方式在上线后绕过检查，注入 *** 调用 dom 接口去修改页面结构和内容，变成跟审核时不一样的应用。怎样能限制应用的 *** 调用 dom 的权限？微信想了个比较创新的解决方案，就是： *** 运行环境与浏览器分离，运行在单独的 *** 引擎上。
脱离了浏览器， *** 自然没有 dom 的调用权限，任何跟 webview 界面相关的 API 都无法拿到。而小程序框架核心 *** 运行在webview上，可以自由操作dom，通过小程序框架定义的机制，应用端通过 wxml/wxss 定义固定的渲染样式， *** 端只管数据绑定，数据可以通过 native 桥梁从 *** 引擎传递到 webview， *** 端无法做任何渲染相关的操作，可以对渲染的内容有完整的管控权。
独立的 *** 运行环境除了满足管控需求外，也额外带来一些好处和一些坏处，好处在于：
多个页面可以共享一个 *** 运行环境，数据可以很方便地共享，整个小程序生命周期里共享同一个上下文，更接近 APP 的开发体验。
*** 与页面渲染分离并行执行，不会出现 *** 执行时卡住页面渲染的情况，提升渲染性能。
坏处在于：
多了数据序列化传输的开销，数据需要从 *** 传到 webview 给视图层渲染，需要序列化为字符串格式再进行传输。
iOS 上 WKWebview 的 *** 引擎比 JavaScriptCore 多了 JIT 优化，执行速度快很多倍，小程序的 *** 运行在 JavaScriptCore 上无法享受到这个优化。
由于管控需求过于刚需，这个方案带来坏处可以接受。
体验
小程序最主要的两个技术点 — 框架和 *** 运行分离 都是源自管控需求，而体验上的需求就是由各种细致的性能优化组成了，很多文章也分析过，这里简单说下，包括：
离线包：整个小程序打包下发，不需要打开每个页面都去请求，减少第二次打开时间以及页面切换时间。
预加载：预加载多一个wkwebview放后台，用户打开小程序时省去初始化wkwebview时间。另外对于一个小程序内的页面切换，得益于框架的设计，可以做到预渲染模板，切换时再填充数据，加快渲染速度。
缓存：退出小程序后不会立即销毁，会在后台继续跑5分钟，在这期间用户切回小程序时速度快。
视觉：小程序首次加载通过loading和动画的方式过渡，拒绝白屏，给人一种快的感觉，同时提升了小程序的标识度。
剩下的就是围绕小程序这个平台的周边建设了，像组件，native接口，IDE，后台管理，版本管理，权限控制等基础支持。
支付宝小程序
策略
微信小程序推出时主要面向的场景是线下，希望商家能开发小程序，做像点菜买票这样的即时性应用，提升线下商户体验，支付宝作为线下战场的主要竞争对手自然要跟进。
支付宝要做小程序应该怎么做？可以根据自身的情况，定义另一套技术体系，让第三方接入。但这样的话第三方如果要同时接入微信和支付宝，需要开发两套程序，成本很高，而微信有先发和平台优势，很可能变成只开发微信小程序而放弃接入支付宝小程序，所以更好的做法是降低这里的接入成本，让微信小程序的代码可以复用在支付宝小程序上。所以支付宝小程序对外的框架/API/组件必须是跟微信小程序接近或力求一致，技术上没得选择，所以可以看到支付宝小程序公测版的文档很多跟微信一致。
实现
支付宝小程序框架对外接口是跟微信一样，又因为同样有管控/安全和体验的需求，有些策略是类似的，像独立 *** 环境，离线包，缓存策略等，但在小程序框架的实现上就跟微信完全不一样。小程序框架作为一层屏蔽了实现细节的 DSL 层，最终通过什么技术手段实现都可以是由框架底层自由定制的，这边底层架构基于蚂蚁前端团队多年的积累，最终 web 版小程序是以 react 为基础实现。
React Native
除了对外的跟微信一致的 web 版小程序，内部一直在尝试 React Native 版小程序，渲染层不适用 webview，而是用 RN 去渲染，提升性能和体验，这也是小程序 DSL 层带来的好处，底层渲染引擎可以很方便地替换实现方案，甚至同时存在多套方案。
很多人问为什么不用 weex，按我理解首先是蚂蚁的前端技术栈基于 react，切换成本高，另一个 RN 相对 weex 成熟度高，社区支持度高，并保持着不间断的更新，相对友好。
RN 本身不跨平台，iOS/Android有各自的写法，在 RN 的使用上，业界很多人各自实现了基于 RN 的跨三端或两端的开发方式（例如JDReact），也就是一次开发，能同时支持 RN 在 iOS / Android 两端做原生渲染，也支持 fallback 到 webview 渲染。这里小程序也算是这样一套方案，上层通过自定义 DSL 开发业务，部署时通过工具分别转换成三个平台不同的代码，在三个平台运行。
内部应用
小程序是一套对外的方案，主要用于第三方应用接入，因为上文也说了，框架上很多技术方案都是为了满足对第三方管控和安全方面的需求，而小程序相关的很多体验优化其实用纯 H5 也可以做到，内部业务用 web 版小程序开发并没有带来什么好处，反而增加学习成本。但 RN 版小程序不一样，它有一些优势，包括：
RN 相对 webview 性能优势明显，秒开率高，交互也更流畅。
相对于单纯使用 RN 开发，使用小程序可以屏蔽平台差异，实现跨平台一次开发。
小程序有配套的开发环境/IDE/包管理等基础设施支持，无需再重复建设。
对于业务开发者，小程序不是全新的一套开发方式，在业界可复用，对于框架实现者，RN也是业界流行开源方案，有强大的社区支持。对内对外都避免了另外创建一套只能在内部使用的技术体系，极大降低技术成本。
基于这些原因，在蚂蚁财富这边一些内部原本应该使用 H5 实现的业务，也正尝试更多地使用小程序实现，以提升用户体验，目前部分基于小程序 RN 版开发的业务已在线上稳定运行，后续也会继续尝试把小程序 RN 版持续打造成高性能稳定的三端统一动态化方案。