有了Web Manager和Designer，我们就可以高枕无忧了吗？如果用户的需求只是简单地显示和查询地图信息，这两个快速生成工具当然完全能够满足需要，但如果用户的要求更多一点，更复杂一些，就必须想办法进行自定义开发了。
我们一般可以将自定义开发的方式分为三种：
Ø 使用Web ADF提供的Web控件和API进行自定义开发；
Ø 在HTML或Java浏览器基础上进行自定义开发；
Ø 完全从头开始进行服务器端应用程序或浏览器端应用程序开发。
ArcIMS提供了一个统一且完整的开发框架，即Web ADF，旨在实现一个统一管理且支持多用户的企业级GIS解决方案，开发人员能在服务器端和客户端应用程序环境中使用这些解决方案。
使用Web ADF来开发自定义ArcIMS客户端的好处是显而易见的，首先，它提供了丰富的，并且已经包装好的WebGIS控件，如Map控件、TOC控件、MapTips控件、ZoomLevel控件等，极大地简化了我们的开发过程，降低了开发的难度，更重要的是，在9.2版本以后，Web ADF已经能够支持多种数据源。但基于Web ADF开发的不足之处也存在，它将整个地图交互过程严密地进行了封装，使得我们试图一窥门径的可能性降低了许多。
在Designer工具生成的HTML/JavaScript类型浏览器客户端上定制又如何呢？我们知道，单凭HTML是不会出现什么地图的效果，只有使用JavaScript配合，才能出现“动态”地图。当我们在一个WebGIS站点上缩放地图的时候，绝不是有一个特殊的控件使得地图产生缩放，而是前后出现了两张不同的地图图片，由于间隔时间短，使我们产生了“动态”的感觉。
但使用HTML/JavaScript类型客户端定义的难度颇高，一方面，编写JavaScript代码并不是许多Web程序员的专长；另一方面，该客户端大量的JS文件和函数着实让人头痛不已，其学习曲线非常陡峭。
第三种方法是从头开始编写完全属于自己的WebGIS客户端程序，这种方法复杂的地方只在于如何与一个HTML的DIV进行交互，这种方法适合大部分程序员，具有不同背景的开发人员都可以根据自己的需求进行完全开发。他们只需将这种交互产生的ArcXML请求使用自己最擅长的服务器端技术或客户端提交技术发送给GIS服务，并解析从GIS服务返回的ArcXML响应即可。
小知识：服务器端的Web程序和基于浏览器的Web程序
“城头变换大王旗”，曾几何时，Web开发人员的目光几乎全部集中在服务器端，在ASP、JSP、JSF和ASP.NET等技术的飞速替代和迅猛发展中，似乎很少有人愿意停下来瞥一眼浏览器端的Web程序。
产生这一现象的原因并非不能理解，首先，在浏览器端运行的脚本语言主要是JavaScript，虽然它也挂着一个“Java”的名头，但长期以来Web程序员只将它看作是一种玩具语言，除了在HTML页面上制造几个无伤大雅的动态效果外，很长一段时间内并未受到充分的重视；第二，JavaScript的开发工具始终不太完善，远不及一些商业IDE，而且许多开发人员长期认为它的调试过于困难；第三，由于目前流行的多款Web浏览器在JavaScript的标准支持上并未统一，使得开发人员可能需要针对不同浏览器编写不同的JavaScript，更加增加了Web开发人员对其的反感。
虽然Web程序员也知道，基于表单的“完全刷新”式数据提交方式并不理想，但也想到了一些规避的方法，如Frame或IFrame页面等。直到Jesse James Garrett在其博士论文中发明了Ajax这一词语，并由Google率先在Gmail等应用中首先加以应用后，恍然大悟的Web程序员才发现，使用浏览器端的脚本语言JavaScript，DOM和XMLHttpRequest对象居然能创造出如此绚丽的UI和交互效果。
目前，纯浏览器端的框架和类库已经有多种，如ExtJS、YUI、Dojo、JQuery等，有些已经使用在大规模的商业程序之中，如ESRI ArcGIS Server的 JavaScript API，就是基于Dojo[1]开发的。
[1] Dojo的官方网站http://dojotoolkit.org/