js在图形方面只能算九等公民了。

javascript作为一种依附于浏览器的脚本语言，似乎天生就没得到过亲娘的疼爱。

最开始同志们都只知道用它在html上搞点儿滚动的文字，鼠标后面拖一长串的(*&$W(%*&，或者是状态栏上不断跳跃的xxx欢迎您。那时候的javascript做出的效果，大多属于画蛇添足，喧宾夺主型的，只是教给一些小孩子玩玩所谓的技术效果，没有其他实际意义。

后来很长一段时间里，js的最大作用就是浏览器这边的预先数据校验，什么document.formName.fieldName.value == ''就focus()alert()，即便这样很多人也不会用里边的regex。

等到了ajax这个新瓶旧酒的东西蹦出来了，一开始也是缓慢发展，经历了漫长的prototypejs一统江湖的时候，通过它足以看到垄断者的脾气，它完全不提供api文档，还记得当时所有人的建议都是直接去看源代码，汗啊。幸好人民的力量是伟大的，jquery，mootools，yui一个一个追了上来，prototypejs为形式所迫，不得不加上api，为广大劳苦大众提供更为优秀的服务了。还是竞争力量大啊，公平的市场造就完美的服务。

前言介绍到此为止，咱们就看看在这个号称ajax百花齐放的年代里，为什么javascript还是不能挺起腰杆，也许在页面控制上很多组件库，比如extjs，yui,jqueryui都迈出了辉煌的一步，但是在其他的方面，比如图形处理上，javascript依然步履维艰。

最简单的一个问题就是，javascript到现在也没有自己的内置ui库，想想学c，学java，学python什么的，入门教材里中会有一章会讲讲可视化开发。但是javascript没有。
是因为c的第一个hello world是printf在console里的，javascript的第一个hello world是alert在window里的吗？

这就是明显的歧视，从来就没人把javascript当作编程语言里的公民来看待，如果是个作坊，它最多就算个学徒打杂的。很多工作都不屑于让它去做。

如果我们想用javascript画图，当前可以通过什么途径实现呢？首先咱们先说好，jfreechart那种后台生成图片发送到前台的方法就不要包括进来了，我们就排列一下html+js进行画图的方式。
1.使用浏览器支持的图形引擎，比如ie下的vml，firefox,opera,safari支持的svg或者canvas。
2.http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm，这是一个相当纯正的js图形库，它特立独行的地方就是：“完全使用div来画图。”
3.http://excanvas.sourceforge.net/，google提供的工具库，可以在ie下使用vml模拟其他浏览器上canvas的api。
4.http://dojotoolkit.org/，宣传火暴的dojo提供一套2d和3d的图形api，会自动根据浏览器在vml,svg,canvas之间进行切换。
5.http://prototype-graphic.xilinus.com/这也是一套根据浏览器自动切换实现方式的图形api。
6.http://www.lutanho.net/svgvml3d/index.html还有这个，是专门用svg和vml实现3d效果的。

其他一些基于excanvas，jsgraphics的组件库咱们就不列了，基本这几年看到的底层图形库也就只有这些，有一些还常年累月没有更新了。如果你想只使用javascript光是前期的抉择就是死掉亿万个脑细胞。如果选择jsgraphics会不会因为使用那么多div造成效率下降啊，而且它是模拟图形，缩放旋转这些图形变换能保证吗？如果使用vml,svg,canvas的话，ie和其他浏览器完全不对付，就连google出的excanvas都没有实现全部的功能，网上说为什么现在很多基于excanvas的报表工具都没有饼图，就是因为excanvas用vml实现不了arcTo和clipTo。好几兆的dojo就用来画几张图似乎有些不划算。prototype-graphic只有svn，连发布的下载包都没有。svgvml3d自从06年就再没更新过了。也许有的同学又开始不屑支持ie以外的浏览器，那么我偷偷告诉你一件事情，vml在不同版本的ie下面都是有差矣的。

想想就知道，依靠这些薄弱的图形库javascript能敌得过flash吗？更别提以后出现的什么wwf了。

从某种角度上讲，svg其实蛮适合做javascript的外套的，可adobe收购了macromedia，svgviewer从此流产，flash成了主旋律。即便是ie8宣称会原生支持svg也不知道要等到何年何月了，到时候谁知道ms会不会又搞出一套不兼容w3c的新标准？即便是现在支持svg的浏览器都没有完全实现了svg标准的，opera实现的估计最全了，safari和firefox都没有实现amination动画标签，但是safari的渲染效果更漂亮，挺符合apple一贯作风的。现在想想firefox也就只有调试方便的优点了，pattern,filter好多都没有实现，图形一多还会发顿，估计只能等firefox3了。不知道现在浏览器厂商是如何规划的？如果想支持svg为什么不能实现好标准，半成品用起来实在有够不爽。

退一万步讲，就各个浏览器都实现了标准，js图形组件也还完全达不到要求，不可能指望普通开发者拿着文本编辑器从line,rect,cycle开始画起，因为现在各自实现的差矣太大，ide完全没办法下手，而且大多数人需要能拿来就用button,menu,各式各样的window,panel这些svg，vml,canvas也都还不支持，等到满足条件的时候，市场份额怕早被其他的产品瓜分的一干二净了。

同志们，现在你们不觉得“用js画图是一种自虐行为”吗？

ie用vml
firefox用svg

问题是，为什么非要“用js画图”不可？

硬要抬杠的话，可以列出无数多的“js在xxxx方面只能算九等公民”...

对于“为什么要用js画图”，我给出几个自己的理由，大家看一下是否适合。

1.如果js可以画图，我不需要再去多装几百M的flash去专门制作flash。不需要再去花钱买flash的ide，不需要另请flash高手来实现图形，不需要在需要修改flash的时候再去为找不到人发愁。

2.如果js可以画图，我们可以不用去学习flash和js的接口，掌握dom和js语法的人就可以绘画简单的图形，如果以后提供了js图形库，那么js原生调用起来，肯定比js中调用flash简单吧？

3.js是用于浏览器中与客户交互的，绘图应该算是它的本职工作，如果js主要是用来做科学计算的话，估计我也不会去埋怨它的图形问题了。图形功能确实是因为实际应用的需要。

暂时想到这三点，无论是反对还是赞同意见，都希望朋友们不吝指教。

前端开发就是在浏览器的夹缝中生存。

不是JS没有图形库，是浏览器没有。期待web来一次大变革吧,而不仅仅是那换汤不换药的HTML5。搞来搞去，还是偏向“展示”，而不是交互。

目前复杂的图形还是搞搞flash/flex吧，js方面只能慢慢等了。

楼主标题党，实在有点离谱了。

画不了图不是js的错。没图形库不是。就算有很好的图形库，90%的程序员是不会画画的，最多画画线段、弧线、色块、渐变之类的。

用svg/vml，也不关js的事，你写的是markup不是js。



画图跟组件本来就是两码事，楼主不要混在一起了。

还有，用程序来画复杂图形本来就是自虐行为（行为艺术家和超级黑客那不是常人不做讨论），跟是不是js没有关系。

hax老大可能理解错我的意思了，我不想要什么复杂图形，只是想要报表里的折线图，柱状图，饼图。或者一个在线的流程编辑器，可以拖拖拽拽设计一个workflow就可以。或者是uml，er图一类的在线设计工具。

hax老大比我们更清楚js,css,html这些东西，到底用js画图是不是一个不该讨论的领域，是不是应该全部用flash解决，看svg和vml这些东西是不是就是在浪费时间？

PS:怕被说成标题党，这个标题已经是改过一次的，可是自己还是喜欢张扬，唉。

web图形flash是主流，adobe收购了MM后SVG也不怎么积极了

M$也想用sliverlight来分享市场，并且silverlight不像flash那样只支持一种脚本语言

就像js成为事实浏览器标准一样，浏览器图形还是看各个厂商的实力占据的市场份额了

靠w3c是靠不住的