散分讨论一个关于客户端的老问题

为轮子而生 2016-03-25 08:27:16
公司团队的一个项目在策划阶段引发了一个讨论:究竟是客户端程序好,还是基于浏览器好。虽然说“选择要依赖于需求”,但作为一个开发客户端程序很多年的程序员来说,我在主观上不太承认所谓的“客户端能做的浏览器都能做”、“bs比cs安全、方便”等说法,我觉得,浏览器对于计算机领域来说,只能作为数据展示的工具,而其他功能会受到诸多限制,现在所谓的“都能做”,也不过是通过各种牵强的方法间接实现而已,其实过程仍然复杂;而客户端程序的开发就相对直接一些,可控性强。我没有见过哪个股票交易终端或行情软件是用浏览器做的(即便有,用户也不会习惯),QQ网页版仍然没有用户,VisualStudio也不会有bs版…… 发此贴,是想听听大家在开发时遇到的有哪些“客户端能做而浏览器不能做”的事情,也就是两种方式绝对不同、无法跨越的地方。

ps:我是一个在铁路局工作的工程师,开发项目多是面向特定功能,比如环境监控终端、远程控制、文件系统、语音系统、分布式数据采集等等,所以在开发经验上会更倾向于客户端,BS粉勿喷。
顺便说一嘴,对于我们这种类似于政府部门的办公方式,不存在程序部署不方便的问题,统一部署程序反而显得更为正规。

以下是我罗列的一些:
1、没有兼容性问题
2、可直接管理内存、进程及操作本地资源,实现对终端的深度控制,比如视频会议、桌面演示、绘图工具等
3、可直接面向外部设备,如语音输入、指纹仪、人脸识别、手写板、数位板,以及具有特定接口的单片机、监控设备等
4、可以作为系统服务,不受用户关闭、刷新等操作的影响,可重复利用应用程序域
5、可直接操作本地文件输入输出过程,对于一些需要客户端大量存储数据(有时是离线数据)的情况有帮助
6、可实现客户端独立的数据库连接、网关、身份验证等过程,便于管理。同时支持面向底层通信协议的开发
7、开发成本低、开发周期短、UI设计直接方便(无需依赖任何第三方框架),如果使用WPF,这一部分特点将更为凸显


不为引发争吵,也不对任何方式存有偏见,仅讨论具体性能及开发成本,重新审视一下信仰。

以下人员请回避:
①开发纯粹数据展示、电商应用、直接套用各种框架实现简单bs数据管理的程序员
②以及没有主见盲目追随表象的新手
...全文
373 22 打赏 收藏 转发到动态 举报
写回复
用AI写文章
22 条回复
切换为时间正序
请发表友善的回复…
发表回复
蓝天里的白云 2016-04-05
  • 打赏
  • 举报
回复
引用 11 楼 starfd 的回复:
只有合适的应用场景,脱离场景谈技术有啥好谈的 你的都已经是符合cs的应用场景了 但不能否认的是,越多越多原来认为只能cs能做的事情,现在bs也能做到了
这是一种必然的趋势
  • 打赏
  • 举报
回复
一些大型企业仍然在用XP系统,浏览器甚至仍在用IE6,而很多好的框架和产品都宣布不再支持IE8了。这种情况下部署B/S架构的信息化系统不得不设置一个一线运维团队负责解决用户的各种幺蛾子问题。虽然C/S在这么老的系统上也会有问题,总体来说幺的程度要轻很多。 一个大一点的软件公司,一定会有各种团队项目组,做C/S的,做B/S的,做App的,像楼上大神所说,给用户做一个项目一定要占领用户的桌面。实际情况也是这样,一个大型的信息化项目一定会包含各种架构,不仅仅是因为用户的需求。 在MES行业主要也是以C/S架构居多,但是近年来也逐渐走向这种混搭模式:车间用户要求在仓库要用手持机扫码,查询库位;用户的领导要求移动办公(实际上只做一些查询、看一些报表)。 一个大一点的软件公司在经过多年的发展后,一定会有一些拳头产品,在营销的时候也会主动渲染这些产品在架构设计上的优势。 抛开所有的应用场景,C/S在开发学习的成本上确实要更低一些。 而说到安全性,有些项目会要求国家安全等级,这需要第三方来评估。如果是C/S的系统,只要你的传输是加密的,基本上测不出什么问题,如果是B/S的,这帮人会拿出各种工具来侦听、拿出各种工具来测试。。。。。当然,也一定会评出一些不符或部分符合的项(体现工作量嘛)。
为轮子而生 2016-04-05
  • 打赏
  • 举报
回复
who is 陈老师
  • 打赏
  • 举报
回复
引用 18 楼 rocmemory 的回复:
who is 陈老师
冠希
BitCoffee 2016-04-05
  • 打赏
  • 举报
回复
cs客户端比较容易采集用户的硬盘存货,不知道陈老师出新作品了没,恩,我想给他发个我开发的小游戏玩玩。
为轮子而生 2016-04-05
  • 打赏
  • 举报
回复
引用 10楼君之飞云 的回复:
代价与成本 股票交易,不是他们不能做或者做不出WEB版本,至少当前很多财经站是有WEB版本的,如网易新浪。假如一个项目的本身,是经过很长时间的经营得到的市场,如果要用户接受新的方式,确实是有一定苦难。再者如果重构它,并不能给企业带来任何新的效益,那又有什么意义呢?股票软件,就是这么个存在。并不是说WEB做不出来,而是用户习惯、重构成本以及换方式带来的代价之间的公式不符合效益。 市场与需求 WEB做不了的事情,自然就要交给软件。比如某宝,一直都是WEB的方式。为什么要开发个旺旺出来?就是WEB的局限所致。当WEB满足不了的时候,自然就需要新的产品出来。你说QQ网页聊天,能够比软件强大吗?QQ网页聊天,其实用户很小众。
我是做股票软件出身的,可以很直白地告知你,股票软件作为分布式数据管理和计算的实例,是不可能做出BS版的,你所说的那种仅仅是作为数据和信息展示,而真正的股票软件,必须具备自定义模型、用户公式、触发器、同步信号交易等高级功能,所有这些功能,都要依赖本地的数据分布式存储和同步微调,一个公式,可能要依赖上亿条区间数据的协作运算才能完成,而这些数据可能是基于用户微调后的参数,你不可能把用户这种不确定的、庞大乃至巨大的数据链在服务器上存储和运算,而且还要实现订阅,起码现今得技术达不到。还是那句话,BS不是万能的,间接的、以及刻意避开限制实现的功能和技术,总不如直接的好,起码对于功能性的专业软件来说。
zbdzjx 2016-04-05
  • 打赏
  • 举报
回复
一直在工厂写软件,说一下自己的想法: 1、B/S与C/S的对比,大家应该也有一定了解了,除了少数不得不之外,应该已经倾向于先用B/S,不行再用C/S。 2、还有个习惯问题。像我们公司,MES是C/S的,所以,和MES相关的基本上都是C/S的。而办公流,是B/S的,所以,相关的都是B/S的。 3、如上面某位说的,代价与成本。某些功能,用一种实现可能是很简单的,而用另一种去实现,就会多花一些精力与时间。在没有限定必须用哪种的情况下,会倾向于容易实现的。
software_artisan 2016-04-05
  • 打赏
  • 举报
回复
引用 19 楼 davinciyxw 的回复:
一些大型企业仍然在用XP系统,浏览器甚至仍在用IE6,而很多好的框架和产品都宣布不再支持IE8了。这种情况下部署B/S架构的信息化系统不得不设置一个一线运维团队负责解决用户的各种幺蛾子问题。虽然C/S在这么老的系统上也会有问题,总体来说幺的程度要轻很多。 一个大一点的软件公司,一定会有各种团队项目组,做C/S的,做B/S的,做App的,像楼上大神所说,给用户做一个项目一定要占领用户的桌面。实际情况也是这样,一个大型的信息化项目一定会包含各种架构,不仅仅是因为用户的需求。 在MES行业主要也是以C/S架构居多,但是近年来也逐渐走向这种混搭模式:车间用户要求在仓库要用手持机扫码,查询库位;用户的领导要求移动办公(实际上只做一些查询、看一些报表)。 一个大一点的软件公司在经过多年的发展后,一定会有一些拳头产品,在营销的时候也会主动渲染这些产品在架构设计上的优势。 抛开所有的应用场景,C/S在开发学习的成本上确实要更低一些。 而说到安全性,有些项目会要求国家安全等级,这需要第三方来评估。如果是C/S的系统,只要你的传输是加密的,基本上测不出什么问题,如果是B/S的,这帮人会拿出各种工具来侦听、拿出各种工具来测试。。。。。当然,也一定会评出一些不符或部分符合的项(体现工作量嘛)。
桌面客户端唯一的妖蛾子是:用户安装的是阉割过的系统,安装.net framework不能。。。唯一的解决方案是重装正规的系统
Poopaye 2016-03-26
  • 打赏
  • 举报
回复
我看到散分进来凑个数的
software_artisan 2016-03-26
  • 打赏
  • 举报
回复
BS怎么可能做到比CS更安全?除非是那种没有服务端只有远程数据库的那种假CS。桌面客户端好处很多,楼主也都明白得很,就不多说了。但不可否认,现在BS可以做到的事情越来越多,某些方面比CS更容易做得更出色。 对我来说,内部应用大多是选择桌面客户端,社会化应用则首选移动App。
江南小鱼 2016-03-26
  • 打赏
  • 举报
回复
撸主帖子很长,个个回复有很长,这会儿没心思看,Mark一下,等有心情了长长姿势~
来自故乡的风 2016-03-25
  • 打赏
  • 举报
回复
引用 6 楼 sp1234 的回复:
看起来,你的目的首先是要找到一种“气势上杀气对手的武器”。这个放在最后再说。 首先来看,我建议从心理上先接受一点,目前的基于浏览器的前端架构确实已经达到了相当高的水平。浏览器全都支持websocket,实时双向通讯不成问题。javascript引擎执行效率并不比native的程序慢多少(慢20%,对于前端,根本看不出来),相反地,传统上的浏览器端 css/javascript 异步渲染的技术积累,比大多数桌面软件平台的底层机制都更多、更好用、更精炼、更性感。基于浏览器的前端应用,如果用于 hybride 模式开发(结合客户端插件的开发)可能会取代传统的桌面应用开发模式。 然后,其次,我们要看到,现在大多数 js 开发人员的层次还很低。它们看到一些技术牛人分享的东西,就觉得“好像很厉害似地”,但是他们自己能写上万行 javascript 代码而不乱吗?我们的 js 开发人员的最基本的水平,是编写 http://v.6.cn/999997 而不用再纠结主要技术问题的哪些程序员的水平,绝不是那些只会哪找入门书而做简单网页的程序员。当你跟别人争论中,因为你不懂现代的流行的web前端开发技术,你就无法戳穿对方到底在这方面的水平是否够高、是否真正能做这类开发,或者还只是为了打击你而打击你。这就是你的技术上的一个“死穴”。 回到你的主要问题,其实就是一个相对竞争的结果。你要用数据、案例说明对方最近实际开发的产品的用户体验不好,用事实来说话。不要纠结“是什么”。要知道一切真理都有被推翻的那一天,而眼前,就用简单的、无需论证的事实来达到目的,就够了。 最后,所有的人都需要提高技术水平,所有的人都需要能顺应潮流。
看sp1234的帖子是一种享受。如果整理一下,说不定能像“老罗语录”一样火呢!
为轮子而生 2016-03-25
  • 打赏
  • 举报
回复
引用 6 楼 sp1234 的回复:
看起来,你的目的首先是要找到一种“气势上杀气对手的武器”。这个放在最后再说。 首先来看,我建议从心理上先接受一点,目前的基于浏览器的前端架构确实已经达到了相当高的水平。浏览器全都支持websocket,实时双向通讯不成问题。javascript引擎执行效率并不比native的程序慢多少(慢20%,对于前端,根本看不出来),相反地,传统上的浏览器端 css/javascript 异步渲染的技术积累,比大多数桌面软件平台的底层机制都更多、更好用、更精炼、更性感。基于浏览器的前端应用,如果用于 hybride 模式开发(结合客户端插件的开发)可能会取代传统的桌面应用开发模式。 然后,其次,我们要看到,现在大多数 js 开发人员的层次还很低。它们看到一些技术牛人分享的东西,就觉得“好像很厉害似地”,但是他们自己能写上万行 javascript 代码而不乱吗?我们的 js 开发人员的最基本的水平,是编写 http://v.6.cn/999997 而不用再纠结主要技术问题的哪些程序员的水平,绝不是那些只会哪找入门书而做简单网页的程序员。当你跟别人争论中,因为你不懂现代的流行的web前端开发技术,你就无法戳穿对方到底在这方面的水平是否够高、是否真正能做这类开发,或者还只是为了打击你而打击你。这就是你的技术上的一个“死穴”。 回到你的主要问题,其实就是一个相对竞争的结果。你要用数据、案例说明对方最近实际开发的产品的用户体验不好,用事实来说话。不要纠结“是什么”。要知道一切真理都有被推翻的那一天,而眼前,就用简单的、无需论证的事实来达到目的,就够了。 最后,所有的人都需要提高技术水平,所有的人都需要能顺应潮流。
老大哥给我上了一课,其实发这个帖子就是在等你回复,其实“要用数据、案例说明对方最近实际开发的产品的用户体验不好,用事实来说话”这一句就足够点醒我了,如何实现确实不重要,结果优劣才是主要的。
  • 打赏
  • 举报
回复
例如,当我能把我一个产品(甚至一个公司)的技术方向的时候,尽管有许多web应用,我也会部署一个类似QQ那样的简单应用给企业用户。因为我要“占领用户桌面”,选择最为有利的方式,用这个为基础来不断更新自己的一些“附加能力”。表面上看这是用户需要的应用,其实底层是用来干一些接近操作系统的事情的。而那些 web 应用已经做到的东西我是不需要硬要用桌面软件替代它的。如果你或者你们的公司有这个意识,当然好。但是如果你有,而你的公司没有,那么就等下跳槽到一个公司再说吧。
  • 打赏
  • 举报
回复
看起来,你的目的首先是要找到一种“气势上杀气对手的武器”。这个放在最后再说。 首先来看,我建议从心理上先接受一点,目前的基于浏览器的前端架构确实已经达到了相当高的水平。浏览器全都支持websocket,实时双向通讯不成问题。javascript引擎执行效率并不比native的程序慢多少(慢20%,对于前端,根本看不出来),相反地,传统上的浏览器端 css/javascript 异步渲染的技术积累,比大多数桌面软件平台的底层机制都更多、更好用、更精炼、更性感。基于浏览器的前端应用,如果用于 hybride 模式开发(结合客户端插件的开发)可能会取代传统的桌面应用开发模式。 然后,其次,我们要看到,现在大多数 js 开发人员的层次还很低。它们看到一些技术牛人分享的东西,就觉得“好像很厉害似地”,但是他们自己能写上万行 javascript 代码而不乱吗?我们的 js 开发人员的最基本的水平,是编写 http://v.6.cn/999997 而不用再纠结主要技术问题的哪些程序员的水平,绝不是那些只会哪找入门书而做简单网页的程序员。当你跟别人争论中,因为你不懂现代的流行的web前端开发技术,你就无法戳穿对方到底在这方面的水平是否够高、是否真正能做这类开发,或者还只是为了打击你而打击你。这就是你的技术上的一个“死穴”。 回到你的主要问题,其实就是一个相对竞争的结果。你要用数据、案例说明对方最近实际开发的产品的用户体验不好,用事实来说话。不要纠结“是什么”。要知道一切真理都有被推翻的那一天,而眼前,就用简单的、无需论证的事实来达到目的,就够了。 最后,所有的人都需要提高技术水平,所有的人都需要能顺应潮流。
changjiangzhibin 2016-03-25
  • 打赏
  • 举报
回复
各有适用的地方,也可互通,不必过于纠结,源于客户需求
xdashewan 2016-03-25
  • 打赏
  • 举报
回复
先说关于“客户端能做的浏览器都能做”这一点,拿上传下载作为例子,客户端和浏览器在实现上是有区别的,客户端可以用代码控制选取指定路径下的文件上传,而浏览器需要用户利用file标签手动指定。下载时,由于html没有多文件下载协议,所以是按单个文件下载,浏览器的一般实现为弹出保存对话框,手动保存,有多少下载就弹出多少个,但客户端可以做到多文件连续传输和自动保存。当然你可以自己开发浏览器,因为浏览器本身就是一种客户端,是用来解析html协议并呈现给用户的客户端,因为该客户端多为微软或第三方开发,很多人在开发bs的时候往往都忽略了这点而已。 由于同为客户端,那么“bs比cs安全”这个说法也是不成立的。但话又说回来,由于浏览器这东西的普及性和对各个平台的支持率,使得bs更容易被用户接受倒是真的,所以bs在这方面有很大的优势。 用bs还是cs还是要在于需求和用户群,而不在于bs/cs自身
X-i-n 2016-03-25
  • 打赏
  • 举报
回复
BS的优势是跨平台(不过前端兼容的问题太容易被喂屎了,还是要看具体用户环境),免部署(说得太绝对了) 开发OA你会用CS还是BS?
X-i-n 2016-03-25
  • 打赏
  • 举报
回复
你都已经预设好各种需求场景了,浏览器实在打不动哇
xuzuning 2016-03-25
  • 打赏
  • 举报
回复
B/S 是 C/S 的特例 只不过 C/S 得自己开发客户端(还有协议),B/S 使用成品的浏览器作为客户端 各有各的用途,似乎没有纠结的必要 另外近几年异军突起的 移动App 您把他归于哪一类?
加载更多回复(2)

110,534

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧