We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
今年难得的4天五一假期,放假当天就去下馆子吃饭,发现餐馆的叫餐系统很奇特,在前台点餐后,每桌领取块塑料牌子。餐馆前台在饭菜做好的时候,就做操作让食客的塑料牌子响动和发亮,引导食客交回塑料牌子然后去取餐。
当时点餐的我觉得这套系统很高大上,最后回家上网一查,发现这种系统叫“无线取号寻呼系统”,换句通俗的话来讲,就是局域网的“寻呼机”或者“BB机”。这就涨知识了,我的惯性常识认为二十多年前主流通信工具的“BB机”,应该早就退出历史的舞台,尘封在日新月异智能手机的浪潮底下,没想到此类技术还能在餐饮行业的信息化发展中继续发挥着余热。
当我抱着好奇心在网上继续搜索时候,发现当年的“BB机”无线寻呼技术除了应用在餐饮行业,还应用在医院的局域通信中。说到这里,也许读者很奇怪我会这么大的反应,因为我是信息工程专业出身的,虽然毕业后从事了互联网前端开发工作,但是大学4年耳濡墨染的通信技术还是有一定的技术敏感度的。
这次假期吃饭发现的“BB机”技术的新时代应用,在处于互联网前端技术的频繁更替的大环境下,给了我很大的思考,因为我的开发工作时间中,基本每周有那么一两次和同事对所谓前端“新旧技术”的友好(si)交流(bi)。因为我负责的是基础功能的前端应用,接受的锅很多都是近十年的陈年代码,基础应用99%都是基于jQuery的技术去实现的。日常重构和升级,最大的交流是对jQuery是否已经落伍淘汰的讨论和分析。
作为一个电子信息相关专业出身的开发者,先从卖弄一下自己了解到的“寻呼机”技术历史
注: 图片来自于网络
上述说了一大通“寻呼机”的前世今生,以及在特定场景仍旧发挥着余热,那我们来说说jQuery的前世今生以及是否已经过时了。以下我们来先聊聊jQuery的主要发展历程。
从上述的jQuery的发展历程看,jQuery的从诞生开始,发展没有停止过。jQuery在1.x阶段是处理PC端操作的兼容,在2.x阶段是为了摈弃低版本IE的兼容和提高性能,在3.x阶段则是与时俱进,吸收了很多ES和HTML5新特性。
近几年来,前端的框架和工具库层出不穷,大浪淘沙后,目前呼声较高的框架有 React.js、Vue.js和Angular。同时,在2018年GitHub宣布放弃使用jQuery的时候,前端社区对摈弃jQuery的声音层出不穷。因为我工作中可以说50%的开发是跟jQuery有关的,在这种背景下,我就在想jQuery真的有那么落后么?
我换了一种思考角度,我为啥还使用jQuery?是在什么情况下我选择使用了jQuery?
我开发过程中,遇到的场景是服务端是Java,主要提供服务端渲染,前端用jQuery绑定对应的操作事件和DOM变化。 我的业务需求,遇到的是SEO强需求,需要在服务端渲染模板上动态渲染好数据,等待爬虫来抓取数据。 我的维护中。同时还要最低要兼容到IE8,保证在IE8上基本能正常使用。
那么第一个就面临着IE8的兼容性问题,这个是无解的,即使引用一堆 polyfill 库也不能彻底解决问题。 再次就是服务端模板渲染的问题,如果是以服务端Java的模板为主呢,那么React本身的JSX模板就需要重写一套,前端页面渲染时候,覆盖在服务端渲染的DOM上面。如果是以React模板为主呢,就得需要人力和机器投入去整一套SSR系统专门做服务端渲染。
其实会发现遇到的困难和 React类似的。
从上述很浅显的应用选择层面就可以知道,其实jQuery还是有一定的应用场景的,React/Vue/Angular虽然流行且提高开发效率但是也有一定的场景短板的。就像刚开始的“BB机”的历史和如今的应用场景一样,总结一句话,没有落后的技术,只有不适应场景的技术。
其实如果只是考虑Chrome和IE11+的浏览器,普通的DOM操作和事件直接用原生浏览器WebAPI就可以满足要求,但是如果考虑到兼容性和API统一性,用jQuery其实也是个不错的选择。React/Vue/Angular的方便性就是抹平了操作DOM的方式,让开发者可以更关注于组件的组合和业务的实现,而jQuery核心就是操作DOM,所以很多DOM操作的注意事项要关注的。
jQuery的使用注意点其实就只有一点,就是操作DOM事件和数据生命周期控制,保证DOM在销毁时候,对应有事件和数据也一并清除,避免事件注册太多和数据残留导致的内存溢出。
$('div').on('click')
$('div').off('click')
$('div').data({a:123})
我们从“寻呼机的前世今生”讲到“jQuery的是否过时”,其实核心的一点就是在讨论一个技术是否有过时落伍一说。
一门技术的诞生肯定是有其应用场景,所谓的“过时”,是应该相关的应用场景有更加高效低成本的技术代替了。
一门技术其实就是一种工具,工具的诞生是为了解决实际问题,脱离了实际问题的本身,技术的价值很难说清楚。所以这里面对技术选型,我的建议是参考STAR法则。
套用上述的内容我们可以这么说
问题圆满解决
我为啥选择jQuery技术呢
熵,通常作为一个物理名词,用来描述一个系统的混乱程度,失序程度的指标。在我大学信息工程专业学习的信息导论中,信息熵是接受的每条消息里包含信息的数量和不确定性的综合度量。也就是消息里包含的信息数量、不确定性和随机性越大,就代表着信源的熵就越大。
近几年互联网的技术发展飞快,各种技术框架爆炸性增长,带来的是眼花缭乱的技术选型困难症。对比原来比较中规中矩的前端技术体系,在2012年前,jQuery + jQuery衍生框架是主流前端技术体系,主要的理念是如何更加兼容地操作DOM和渲染页面。
但是大概2012年以后,各种前端技术理念开始普及,例如MVVM, Virtual-Dom等,对原有有序的前端技术体系带来冲击,极大提高了前端技术体系的信息熵,这带来利的一面是技术选择面广了,弊的一面是需要更多时间去衡量和选择技术。
到现在,一提到前端技术体系,充斥着眼花缭乱的技术框架和衍生框架。信息熵的增大,有序变无序并不可怕,最重要的是,要怎么学会在庞杂的前端信息中学会选择技术,学会应用到实际的场景中。
对于技术优劣的讨论,一切脱离了实际问题场景讨论技术优劣的都是耍流氓。没有的绝对的银弹,只有合适场景的解决方案。
watch
大海码
DeepSeaCode
The text was updated successfully, but these errors were encountered:
Vue 也是有SSR功能的,不需要楼主们再进行额外的开发 哈哈
Sorry, something went wrong.
Vue/React 都有社区提供的SSR能力,但是有些企业里,会遇到古老的jQuery项目,所以该文章主要的问题是围绕 古老的jQuery 前端项目的来探讨的哈
SSR
古老的jQuery
如果围绕的是 古老的JQuery 来讨论,那问题只剩下一个了:改动太难。而没有后面的 ABC 原因(比如SEO问题)。 并且,楼主你举的例子是 “BB机的新应用”,在我看来是 “旧技术新用途”。反而不适合来对比 “古老的JQuery项目” 哈~
No branches or pull requests
前言
今年难得的4天五一假期,放假当天就去下馆子吃饭,发现餐馆的叫餐系统很奇特,在前台点餐后,每桌领取块塑料牌子。餐馆前台在饭菜做好的时候,就做操作让食客的塑料牌子响动和发亮,引导食客交回塑料牌子然后去取餐。
当时点餐的我觉得这套系统很高大上,最后回家上网一查,发现这种系统叫“无线取号寻呼系统”,换句通俗的话来讲,就是局域网的“寻呼机”或者“BB机”。这就涨知识了,我的惯性常识认为二十多年前主流通信工具的“BB机”,应该早就退出历史的舞台,尘封在日新月异智能手机的浪潮底下,没想到此类技术还能在餐饮行业的信息化发展中继续发挥着余热。
当我抱着好奇心在网上继续搜索时候,发现当年的“BB机”无线寻呼技术除了应用在餐饮行业,还应用在医院的局域通信中。说到这里,也许读者很奇怪我会这么大的反应,因为我是信息工程专业出身的,虽然毕业后从事了互联网前端开发工作,但是大学4年耳濡墨染的通信技术还是有一定的技术敏感度的。
这次假期吃饭发现的“BB机”技术的新时代应用,在处于互联网前端技术的频繁更替的大环境下,给了我很大的思考,因为我的开发工作时间中,基本每周有那么一两次和同事对所谓前端“新旧技术”的友好(si)交流(bi)。因为我负责的是基础功能的前端应用,接受的锅很多都是近十年的陈年代码,基础应用99%都是基于jQuery的技术去实现的。日常重构和升级,最大的交流是对jQuery是否已经落伍淘汰的讨论和分析。
寻呼机的前世今生
作为一个电子信息相关专业出身的开发者,先从卖弄一下自己了解到的“寻呼机”技术历史
jQuery真的过时了么?
先聊聊jQuery的历史
上述说了一大通“寻呼机”的前世今生,以及在特定场景仍旧发挥着余热,那我们来说说jQuery的前世今生以及是否已经过时了。以下我们来先聊聊jQuery的主要发展历程。
从上述的jQuery的发展历程看,jQuery的从诞生开始,发展没有停止过。jQuery在1.x阶段是处理PC端操作的兼容,在2.x阶段是为了摈弃低版本IE的兼容和提高性能,在3.x阶段则是与时俱进,吸收了很多ES和HTML5新特性。
再聊聊主流前端框架的实际应用对比
近几年来,前端的框架和工具库层出不穷,大浪淘沙后,目前呼声较高的框架有 React.js、Vue.js和Angular。同时,在2018年GitHub宣布放弃使用jQuery的时候,前端社区对摈弃jQuery的声音层出不穷。因为我工作中可以说50%的开发是跟jQuery有关的,在这种背景下,我就在想jQuery真的有那么落后么?
我换了一种思考角度,我为啥还使用jQuery?是在什么情况下我选择使用了jQuery?
我开发过程中,遇到的场景是服务端是Java,主要提供服务端渲染,前端用jQuery绑定对应的操作事件和DOM变化。
我的业务需求,遇到的是SEO强需求,需要在服务端渲染模板上动态渲染好数据,等待爬虫来抓取数据。
我的维护中。同时还要最低要兼容到IE8,保证在IE8上基本能正常使用。
那么第一个就面临着IE8的兼容性问题,这个是无解的,即使引用一堆 polyfill 库也不能彻底解决问题。
再次就是服务端模板渲染的问题,如果是以服务端Java的模板为主呢,那么React本身的JSX模板就需要重写一套,前端页面渲染时候,覆盖在服务端渲染的DOM上面。如果是以React模板为主呢,就得需要人力和机器投入去整一套SSR系统专门做服务端渲染。
其实会发现遇到的困难和 React类似的。
从上述很浅显的应用选择层面就可以知道,其实jQuery还是有一定的应用场景的,React/Vue/Angular虽然流行且提高开发效率但是也有一定的场景短板的。就像刚开始的“BB机”的历史和如今的应用场景一样,总结一句话,没有落后的技术,只有不适应场景的技术。
我们使用jQuery要注意什么?
其实如果只是考虑Chrome和IE11+的浏览器,普通的DOM操作和事件直接用原生浏览器WebAPI就可以满足要求,但是如果考虑到兼容性和API统一性,用jQuery其实也是个不错的选择。React/Vue/Angular的方便性就是抹平了操作DOM的方式,让开发者可以更关注于组件的组合和业务的实现,而jQuery核心就是操作DOM,所以很多DOM操作的注意事项要关注的。
jQuery的使用注意点其实就只有一点,就是操作DOM事件和数据生命周期控制,保证DOM在销毁时候,对应有事件和数据也一并清除,避免事件注册太多和数据残留导致的内存溢出。
$('div').on('click')
事件,如果DOM有销毁的步骤,那么在销毁前就要一并把事件给删除掉$('div').off('click')
$('div').data({a:123})
,如果DOM有销毁的步骤,那么在销毁前就要一并把数据给清除掉技术选型的STAR法则
我们从“寻呼机的前世今生”讲到“jQuery的是否过时”,其实核心的一点就是在讨论一个技术是否有过时落伍一说。
一门技术的诞生肯定是有其应用场景,所谓的“过时”,是应该相关的应用场景有更加高效低成本的技术代替了。
一门技术其实就是一种工具,工具的诞生是为了解决实际问题,脱离了实际问题的本身,技术的价值很难说清楚。所以这里面对技术选型,我的建议是参考STAR法则。
套用上述的内容我们可以这么说
问题圆满解决
我为啥选择jQuery技术呢
前端技术的信息熵
近几年互联网的技术发展飞快,各种技术框架爆炸性增长,带来的是眼花缭乱的技术选型困难症。对比原来比较中规中矩的前端技术体系,在2012年前,jQuery + jQuery衍生框架是主流前端技术体系,主要的理念是如何更加兼容地操作DOM和渲染页面。
但是大概2012年以后,各种前端技术理念开始普及,例如MVVM, Virtual-Dom等,对原有有序的前端技术体系带来冲击,极大提高了前端技术体系的信息熵,这带来利的一面是技术选择面广了,弊的一面是需要更多时间去衡量和选择技术。
到现在,一提到前端技术体系,充斥着眼花缭乱的技术框架和衍生框架。信息熵的增大,有序变无序并不可怕,最重要的是,要怎么学会在庞杂的前端信息中学会选择技术,学会应用到实际的场景中。
后记
对于技术优劣的讨论,一切脱离了实际问题场景讨论技术优劣的都是耍流氓。没有的绝对的银弹,只有合适场景的解决方案。
watch
本项目 或者 关注我公众号大海码
DeepSeaCode
The text was updated successfully, but these errors were encountered: