JavaScript框架发展的四个时代,你经历过其中几个阶段?( 三 )


另一方面 , 我们没有在JS中构建完整应用程序的经验 , 因此关于最佳方法上 , 很多开发者有许多不同的想法 。 大多数框架都试图模仿其他平台上的流行做法 , 所以几乎所有的框架最后都是「Model-View-*」的迭代方式 , 如Model-View-Controller、Model-View-Producer、Model-View-ViewModel等 。 从长远来看 , 其中的一些问题的确被解决了 , 但是解决方案往往不太直观 , 而且在应用过程中越来越复杂 。
这也是一个我们真正开始尝试如何编译JavaScript应用程序的时代 。
JavaScript框架发展的四个时代,你经历过其中几个阶段?
文章图片
Node.js在2009年发布 , NPM在2010年紧随其后 , 将包的概念引入(服务器端的)JavaScript中 。 CommonJS和AMD就如何定义最好的JS模块展开竞争 , 而像Grunt、Gulp和Broccoli这样的构建工具则争夺如何将这些模块组合成一个可交付的最终产品 。
在大多数情况下 , 这些都是非常通用的类似于任务运行器的工具 , 可以真正构建任何东西 , 只是碰巧与HTML、CSS/SASS/LESS等技术结合 , 基于JavaScript开发出很多适用于Web端的产品 。
从这个时代 , 我们学到了很多东西 , 收获了宝贵的经验 , 包括:
URL路由是基础 。 没有它的应用程序往往会出现Bug , 开发者需要从一开始就在框架中考虑它 。
通过模板语言扩展HTML是一个强大的抽象层 。 即使有时它可能有点笨拙 , 但它可以让你的UI与状态保持同步且更容易 。
SPA(单页面应用)的性能很差 , 而且Web开发有许多原生应用没有的额外限制 。 我们需要通过Web发布所有代码 , 让它即时编译(JIT) , 然后运行以启动我们所开发的应用程序 , 而原生应用程序已经下载和编译 。 这是一项艰巨的任务 。
JavaScript作为一种语言有很多问题 , 它确实需要改进以使事情变得更好——框架无法单独做到这一点 。
我们绝对需要更好的构建工具、模块和包装来编写大规模的应用程序 。
总的来说 , 这个时代硕果累累 。 尽管存在这些缺点 , 但随着应用程序复杂性的增加 , 将客户端与API分离的好处是巨大的 , 并且在许多情况下 , 让用户体验有了飞速提升 。 如果情况有所不同 , 这个时代可能还会继续 , 我们可能直到今天还在重复MV*的风格 。
但后来 , 一颗“小行星”的突然出现 , 把现有的范式砸得粉碎 , 造成了一个小的灭绝事件 , 把我们推进了下一个时代——这颗“小行星”名为React 。
以组件为中心的视图层
我不认为React发明了组件 , 但说实话 , 我不太确定它们最初是从哪里来的 。 我知道现有技术至少追溯到.NET中的XAML , 并且Web组件也在那时开始作为一种规范开始普及 。
现在每个主流的框架都使用了组件 。 事后看来 , 它的流行也完全是有道理的——扩展HTML , 减少长期存在的状态 , 将JS业务逻辑直接与模板联系起来(无论是JSX还是Handlebars还是Directives) 。 基于组件的应用程序消除了完成工作所需的大部分抽象概念 , 并且明显地简化了代码的生命周期 , 一切都与组件的生命周期而不是应用程序的生命周期联系在一起 , 这意味着作为一个开发人员 , 你要考虑的事情要少得多 。
然而 , 当时还有一变化:框架开始把自己吹嘘成"视图层" , 而不是完整的框架 。 他们不再解决前端应用所需的所有问题 , 而只是专注于解决渲染问题 , 其他问题如路由、API通信和状态管理 , 则由用户自己决定 。 这个时代著名的框架包括:
React.js
Vue.js
Svelte
Polymer.js
当然还有很多很多其他的框架 。 现在回头看 , 我认为这是第二代框架中流行的框架 , 因为它主要做了两件事情: