nodejs

这里主要针对node-webkit和atom-shell, nodejs下开发桌面应用也有其他可以选择(大体都是基于Chromium + nodejs), 主要这两个相对比较流行, 源码也一直保持更新. 目前node-webkit文档/例子可能多一些, atom-shell相对少一些.
详细区别什么的自己去搜吧, 自己使用中体验到的:

• node-webkit入口是html, atom-shell入口是JS;
• node-webkit功能相对多一些, 两者都可以把代码打包(一个是.nw,一个是.asar)放到应用里面;
• 即使自己写了几KB的代码, 但最终生成的程序都至少几十MB, node-webkit生成的应用比atom-shell相对小一些;
• 他们一些概念比较类似(可能方法不同), 熟悉一个后, 对熟悉另一个应该是有帮助的;

性能什么肯定没有原生的好了, 但是用一种语言就可以生成cross-platform的软件, 这好处也是显而易见的; 总之开发一些简单的小应用, 还是非常适合的, 至少不需要再去学2-3门编程语言了.

自己写了简单的例子, 源码放在: github.com/kairyou/create-desktop-app-with-nodejs
里面的脚本, 在Mac下面可以直接运行程序, 或者可以直接生成/OSX/windows/Linux三个平台的程序.

自己偏向atom-shell多一些, 不过目前两个还是都要熟悉下, 可能有些特殊的功能, 必须要使用其中一个才能满足~

这两个的源码和官方文档:
github.com/rogerwang/node-webkit
github.com/atom/atom-shell

Mac下编辑JS文件, 如果是中文字符的行会警告: This character may get silently deleted by one or more browsers.

SublimeLinter 的官方文档http://goo.gl/VYzZ0, 里面也说的含糊不清, 只是告诉要装nodejs或设置sublimelinter_executable_map.
On Mac OS X, you must install Node.js if you plan to edit Javascript or CSS files that use non-ASCII characters in strings or comments, because JavaScriptCore is not Unicode-aware.
OS X默认的JavaScriptCore(jsc)不支持非ASCII字符, 所以会报上面的警告, 使用nodejs才行.

debug了下SublimeLinter的源码, 发现把Package Settings->SublimeLinter->Settings - User加上:
"sublimelinter_executable_map":
{
"javascript": "/Users/leon/.nvm/v0.10.8/bin/node" // which node
},
就OK了, 开始还以为要设置"node":"node path", 原来是设置"javascript"..

没安装nodejs到/usr/local/bin, 如果使用其他编辑器里的jshint/jslint应该也会遇到这个警告, 可以尝试修改node路径来解决.

直接安装nvm(可以指定node版本, 切换不同版本)

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

# 编辑 ~/.bash_profile 或 ~/.zshrc, 加入下面3行:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion
# source ~/.bash_profile 或 source ~/.zshrc

nvm ls; # 版本列表
nvm install v8 # v8.xx 的最新版, nodejs.org/#download 查看最新版
nvm alias default 0.10 # 加到环境变量
node -v
# npm nodejs新版已经集成, 无需单独安装.
npm install uglify-js -gd #uglifyjs
    uglifyjs -V

Ps: 安装方式可能会有更新, 可以看下NVM的最新文档: https://git.io/fbpVf

以前弄scss只能在ruby下面, nodejs版less.js已经比较成熟, 而sass.js(1)不支持scss(后面作者又去开发Stylus了~), 后面出现的scss-js(2)已经错过时机(支持scss语法有限, 已很久没更新了).
这大概是导致目前less在国内爆发的一个原因吧. 排除环境依赖影响, 个人感觉sass比less好很多, 相信不少同学也这样认为~
对比了目前的4种css预处理语法: sass(scss)/less/stylus/closure-stylesheets, 还是更喜欢scss.

用nodejs写小工具蛮适合的, 但之前苦于sass在nodejs下没有比较好的package. 终于node-sass(3)出现, 目前npm里最好的sass package, 测试了一些scss文件基本都OK, 语法有误时也会返回错误信息.

基于node-sass写了个小工具, 监听项目目录, 当文件夹里的.scss文件被修改则立即编译成css文件, 使用:
1. sudo /path/scss.js # 载入已写好的配置, 侦听多个项目;
推荐这种方法, 把多个项目的配置信息写到 scssConfig.js中, 不需要额外的参数.
2. sudo /path/scss.js -build # 读取所有的.scss并编译成.css文件;
3. sudo /path/scss.js -clear # 清除错误日志(如果配置了 scssConfig.js里logDir的路径);
4. sudo /path/scss.js /path/project1/ /path/lib/ # 临时监听project1目录, lib为.scss里@import的path(无@import,可以省略);

源码放在: https://github.com/kairyou/f2e-tools/tree/master/scss

附送使用node-sass时遇到的问题以及解决方法:
1. error reading values after :
读取value出错, 可能是颜色错误不是6位或3位, 比如:color:#abcde;
2. .scss里面写: @charset "UTF-8"; 会报错: top-level blockless directive must be terminated by ';'
@see: https://github.com/andrew/node-sass/issues/23
3. error reading values after opacity / progid
使用: unquote("..."); @see: https://github.com/hcatlin/libsass/issues/72

文中提到的sass几个package的link:
1) sass: https://github.com/visionmedia/sass.js
2) scss: https://github.com/bmavity/scss-js
3) node-sass: https://github.com/andrew/node-sass

有了nodejs版, 其他语言(非ruby), 比如PHP的phpsass/scssphp等就可以忽略了~

对于压缩工具前端攻城师最常见的就是雅虎的Yui Compressor / Google的Closure Compiler了。
对比其他压缩工具相对在JS和CSS压缩领域比较成熟，压缩率也比较好.
一般会选择结合ANT实现压缩并合并，效果也不错，但是比较偏向个人，团队协作每个人都部署java/ant有些麻烦。
对于个人开发使用ANT的方案也是相对不错的选择。对于团队，最好的解决办法是在服务端压缩，大家只需要登录并执行一个统一的脚本。

下面分享下大致的测试结果，和改用nodejs压缩合并js/css的原因。

js部分采用UglifyJS

1. 压缩jquery 1.8，253 KB：使用UglifyJS(以下简称UJ): 90.5 KB；使用Closure Compiler(以下简称CC): 91.1 KB。

2. 如果在闭包(function($, window, undefined) {...})(jQuery, window); 内的 unused function/variables
CC会被删除没使用的；UJ 默认全部保留，加上 pro.ast_lift_variables(ast) 才会删除未使用的函数/变量 (对象/数组 不会被删除)。
如果直接暴漏在window下的，两个基本差不多。

3. function c(){2}， CC 会警告，UJ不会
4. function c(){e()2}，都会抛出异常，显示行数，错误原因。CC提示列错误，UJ不会。
5. function c(){e();2}，都保留了2，CC 警告，UglifyJS 无信息
6. CC 一次显示JS里的全部错误(有些是前面的错误引起的, 所以部分是误报)，UJ每次只显示一个错误。

7. 0 = {}; CC会报错，而UJ不会。
8. if语句都可很好的优化。

9. CC喜欢把变量/函数(结构简单的)内的语句，直接插入到使用它们的地方，UJ维持原样。
如果函数内的内容较少, CC会把函数的内容直接插入到调用它的地方，比如：
function c(){xxxxxxx('12345678901234567');}
function c(){xxxxxx.yyyyy('12345678901234');}
function c(){xxxxxx.yyyyy.zzzz('12345678901');}
function c(){if (X){alert('1234')};alert('12');}
当其他函数里调用c()时，会把c()方法删除，然后把c()内的内容移动到这里
(当里面的字符串长度+1后，就会直接使用原函数c()，所以CC这里是根据字符长度)。

查看全文 »