superopengl 发表于 5-7-2014 05:08 static/image/common/back.gif
最近在公司里做了一个小项目的prototype，MongoDB + Node.js/Express as REST APIs + AngularJS。
优点 ...
如果觉得第一次load各种库费时间的话，可以试试AMD，比如RequireJS
DDD888 发表于 6-7-2014 18:37 static/image/common/back.gif
我感觉light client/heavy server可以处理web browser, android, ios, mac os非常方便
heavy client/lig ...
这也正是JavaScript的无人能替代的作用——Logic code既可以在Client端运行也可以在Server端运行。现在只有JavaScript能够做到这一点。
出于安全考虑，logic code可以在Client端跑一遍，发到Server端的时候还可以再跑一遍。
DDD888 发表于 6-7-2014 18:34 static/image/common/back.gif
你如何处理security?business logic 在 client side很危险,你不怕被hack?
1. 任何新概念都是先处理理想case，然后再考虑安全性的。所以有安全漏洞不应该是拒绝一种新东西的理由。
2. Server端要保证数据逻辑的安全性即可。因为新architecture中，server端只负责数据逻辑的validation。其实所有的biz logic最终都要转化成data logic然后存储。只要保证data logic security就可以了。biz logic实际上是根据user input计算出data，然后发送data到server端做存储。只要data logic security保证好了，即使biz logic被hack可，hacked data也会被server端拒绝。当然这都是理性状况下。
simpledream 发表于 6-7-2014 20:53 static/image/common/back.gif
如果觉得第一次load各种库费时间的话，可以试试AMD，比如RequireJS
无论如何，Browser end首次load大量JavaScript代码是避免不了的。可以通过一些技术手段回避第二次以后的load。第一次访问相当于下载整个程序的code到browser end。
也许这并不是一个大问题，可以通过UX设计（进度条等）解决掉。
superopengl 发表于 7-7-2014 02:31 static/image/common/back.gif
1. 任何新概念都是先处理理想case，然后再考虑安全性的。所以有安全漏洞不应该是拒绝一种新东西的理由。
...
假设使用100mb数据生成1 byte数据，根据你的设计，100mb数据需要被带到browser端， 如果在fat server中处理，只需要1 byte数据被带到browser端
DDD888 发表于 7-7-2014 05:37 static/image/common/back.gif
假设使用100mb数据生成1 byte数据，根据你的设计，100mb数据需要被带到browser端， 如果在fat server中处 ...
是的。但好处就是server端CPU和Memory不再负担那100mb代码所需的计算量。server端做更少的事情，从而实现更多并发并降低成本。毕竟server宝贵的资源不是免费的，而network传输是免费的。
Web Application UX的瓶颈已经不是带宽，而是response等待和JavaScript执行速度。
而且100mb的code，理想状态下只下载一次，之后就不再下载了。我觉得brwoser作为cloud上的一个计算节点，有个发展趋势就是永久存储server端下载的JavaScript，而不是现在作为temp file存储。比如在public CDN上的jQuery.js、AngularJS.js其实就是一种供Browser使用的dll的概念。
superopengl 发表于 7-7-2014 08:13 static/image/common/back.gif
是的。但好处就是server端CPU和Memory不再负担那100mb代码所需的计算量。server端做更少的事情，从而实现 ...
传送100mb的数据到client browser 要花多少时间？:)
server端资源向来被认为是免费的:)
实现并发，并不是通过你所说的将计算移到client browser来实现的
JavaScript执行速度所花时间相比传送100mb的数据到client browser应该ignore啦
本帖最后由 woodheadz 于 7-7-2014 10:32 编辑
Javascript loading处理好了不会是太大的问题。
我现在的项目javascript压缩后接近2mb，采取的做法就是先按逻辑模块和大小分为几个包压缩，然后将每个包的文件名改为这个包的md5。http header缓存策略设置为缓存1年。这样连上服务器检查时间都不用，也不会出现不同的javascript文件版本错误搭配之类的问题，效果很不错。
现在浏览器端能力已经非常强大了，完全离线都能做到。所以这方面的应用也越做越复杂，前端框架作用也越来越大。
我自己做得框架Knot.js已经基本经过我们项目的检验，最近有空就做点包装啥的，做好了开源。一个人做开源很累啊，会犯严重的拖延症。 有没有同学有兴趣一起来？
black_zerg 发表于 7-7-2014 11:19 static/image/common/back.gif
Features I like in angular: route, validation,repeat (filter), utility tools (battery included, so y ...
所谓的软件设计，本质上就是一门取舍的艺术。
既然有取有舍，就不可能面面俱到，就不可能在所有情况下做到最适。
所以尽管有angularjs的存在，还是有不少人在用knockoutjs。不一定要竞争，补充也是可以得嘛。
我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于client browser i.e. ie, firefox, chrome, 或android,iphone, ipad应用程序如果只要能重新写十行代码，那工作量就大幅度减低，真这样的话，服务器写五万行C#代码也是值得的:victory:
反正现在大多数专家级别的人都会同时写C#,javascript, java，多种语言开发网站应该不是啥问题啦:loveliness:
DDD888 发表于 7-7-2014 12:17 static/image/common/back.gif
我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于clien ...
这年头都讲究用户体验，你说的这种情况越来越不现实了。
woodheadz 发表于 7-7-2014 13:19 static/image/common/back.gif
这年头都讲究用户体验，你说的这种情况越来越不现实了。
我就用thin client/fat server设计,运行在client browser ie 8+, chrome, firefx和android native application上,客户非常满意:loveliness:
DDD888 发表于 7-7-2014 13:26 static/image/common/back.gif
我就用thin client/fat server设计,运行在client browser ie 8+, chrome, firefx和android native applic ...
呃，你们的应用客户端交互应该不会特别复杂吧，我估计。然后也没有离线需求是吧？
本帖最后由 DDD888 于 7-7-2014 13:47 编辑
woodheadz 发表于 7-7-2014 13:40 static/image/common/back.gif
呃，你们的应用客户端交互应该不会特别复杂吧，我估计。然后也没有离线需求是吧？
我感觉挺复杂的，不是CRUD简单应用，背后是ERP(SAP) :)
我实现了离线功能:victory:速度飞快，数据加密，比在线快许多
DDD888 发表于 7-7-2014 13:43 static/image/common/back.gif
我感觉挺复杂的，不是CRUD简单应用
我实现了离线功能
十几行客户端代码实现离线功能和复杂交互？挺牛的啊... 详细分享下？
woodheadz 发表于 7-7-2014 13:46 static/image/common/back.gif
十几行客户端代码实现离线功能和复杂交互？挺牛的啊... 详细分享下？
可能是我没有表达好，误会啦
我举例啦，我没有说我写的应用是用十几行客户端代码，我说的是thin client/fat server理想情况啦:loveliness:
相对后台，我的JAVASCRIPT代码量是后台的20%,应该是thin client/fat server啦
DDD888 发表于 7-7-2014 13:49 static/image/common/back.gif
我举例啦，我没有说我写的应用是用十几行客户端代码，我说的是thin client/fat server理想情况啦:lovelin ...
哦，一般的系统20%的js代码量那也很正常啦。
当年用ASP.net做企业行业软件开发几乎可以不写js代码。我的意思是现在越来越讲究客户端体验，这种几乎可以不理会客户端的“理想状况”是越来越少了。
本帖最后由 karl.lee.2004 于 7-7-2014 20:15 编辑
DDD888 发表于 7-7-2014 12:17 static/image/common/back.gif
我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于clien ...
我倒是觉得，随着网络速度的提升以及Browser功能（主要指js engine）的日益强大，客户端应该从以前的thin向fat发展。
网络速度的提升，意味着clinet端更新带来的客户等待时间可以极大减少，用户体验不会受到影响。而browser的js engine强大，意味着很多原本必须在server端跑的功能，现在可以放到client端跑了，节约了server的资源（或者更积极的说法，是充分利用了client富余的计算能力）。
另外，之前不同的browser对js的解释不尽相同，所以client端的代码要同时维护多个版本，对开发团队是很大的消耗。但随着一些framework和lib的日益发展，跨browser实现技术已经相当成熟了。因此client端的开发，应该在web开发中占越来越大的比重。
所以我打算在当前的项目中，多使用点js技术，当练手吧。
superopengl 发表于 5-7-2014 05:08 static/image/common/back.gif
最近在公司里做了一个小项目的prototype，MongoDB + Node.js/Express as REST APIs + AngularJS。
优点 ...
谢谢superopengl分享实战经验，javascript的代码在我看来，确实比较抽象难懂（相对于C++、Java、Python等语言来说），如果项目比较大的时候，前后端都用javascript，如何保证代码可读性、可维护性，是个问题。
还有确保客户端的代码和数据的安全性，也会是一个需要认真考虑的问题，相信业界一定也考虑过类似问题，不知道有没有现成的解决方案。
superopengl 发表于 5-7-2014 05:08 static/image/common/back.gif
最近在公司里做了一个小项目的prototype，MongoDB + Node.js/Express as REST APIs + AngularJS。
优点 ...
谢谢superopengl分享实战经验，javascript的代码在我看来，确实比较抽象难懂（相对于C++、Java、Python等语言来说），如果项目比较大的时候，前后端都用javascript，如何保证代码可读性、可维护性，是个问题。
还有确保客户端的代码和数据的安全性，也会是一个需要认真考虑的问题，相信业界一定也考虑过类似问题，不知道有没有现成的解决方案。
superopengl 发表于 7-7-2014 02:27 static/image/common/back.gif
这也正是JavaScript的无人能替代的作用——Logic code既可以在Client端运行也可以在Server端运行。现在只 ...
有点疑问，如果在client端和server端各跑一遍，为什么不索性放到server端跑？
superopengl 发表于 7-7-2014 02:31 static/image/common/back.gif
1. 任何新概念都是先处理理想case，然后再考虑安全性的。所以有安全漏洞不应该是拒绝一种新东西的理由。
...
“即使biz logic被hack可，hacked data也会被server端拒绝”
这样就要求server端要非常谨慎地处理每次传入的数据，感觉server端开发人员的（安全）压力也颇大。
本帖最后由 caoglish 于 8-7-2014 00:14 编辑
现在的一个流行趋势就是WEB API的设计方式，这个好处有
1. 用一种语言编写，然后几乎所有语言都可以调用。
2. 面向WEB API编程，如果觉得原来WEB API的语言出现了瓶颈，可以换个语言，然后只要WEB API没变，所有依赖程序就可以继续使用
坏处：
1.必须有服务器端，一旦断开，所有依赖的程序全部不能用了。
2.公开的WEB API基本上无法改动，不然大批服务会受到影响。
3.web通信耗时耗资源
针对坏处2，一般的解决方案，是web api的版本控制，在设计的时候，url上预留一个版本字段表示版本，如果API有变化，就使用新版本，同时老版API本不变。
还有个关键就是API的设计一定要好。
这个有个很好的例子就是selenium Server，用java编写，但是所有语言基本上都有相应的框架去控制selenium服务器
woodheadz 发表于 7-7-2014 10:11 static/image/common/back.gif
Javascript loading处理好了不会是太大的问题。
我现在的项目javascript压缩后接近2mb，采取的做法就是先按 ...
我看到github上也有一个knot.js，应该不是你写得吧？
https://github.com/keyle/knot.js/
你单独开个帖子介绍一下你的knot.js吧，我现在还是javascript菜鸟，要不然也挺有兴趣参与一下你的项目。
DDD888 发表于 7-7-2014 12:17 static/image/common/back.gif
我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于clien ...
你这个例子有点太极端了，其实现在很多框架能做到跨浏览器兼容，即节省服务器代码也节省客户端代码，岂不是更好？
ubuntuhk 发表于 7-7-2014 23:04 static/image/common/back.gif
“即使biz logic被hack可，hacked data也会被server端拒绝”
这样就要求server端要非常谨慎地处理每 ...
我的经验是这样的：现在大部分server端的code把biz logic和data logic混在一起，也就是做了很多
[*]data binding/unbinding
[*]data serilization/deserilization
[*]data type conversion
[*]controller
[*]routing
[*]message string rendering, like "User {0} got an error as {1}"
[*]dynamic page rendering, e.g. aspx -> html
现在这些都可以放到browser端做。
至于增加server端代码质量的要求，这个其实剥离了biz logic，只处理data logic（或者说biz data logic），反而会使设计更清晰，代码安全。
本帖最后由 superopengl 于 8-7-2014 04:46 编辑
woodheadz 发表于 7-7-2014 09:11 static/image/common/back.gif
Javascript loading处理好了不会是太大的问题。
我现在的项目javascript压缩后接近2mb，采取的做法就是先按 ...
[*]缓存过期设为“永不过期”
[*]js的URL带version或hash信息，like "http://.../v1/blah.js" or "http://.../2a09b162cff/blah.js"。要保证只要有代码修改就升版本或变hash。
这就保证只要代码不改变，就只load一次（用户自己强制删除缓存的情况就管不了了）