浏览器是更强大的IDE

版权声明:所有博客文章除特殊声明外均为原创,允许转载,但要求注明出处。

虽然我很多时间都在做和 Web 网站相关的开发工作,但很少有机会从另一个角度去看待这件领域。直到有一天,我和设计师沟通需求时,看着他在浏览器里打开开发工具,直接修改线上的网页样式,然后观察效果,这样反复几次,最后效果满意了,再把完成的样式复制到自己的设计稿里。

那一刻我被深深触动了。尽管从技术上说这并不是多么稀奇的事情,甚至我自己也做过好多次类似的事情,但是从旁观者的视角,却让我意识到自己过去一直不太注重的一个事实:浏览器实际上是一个非常强大的IDE,甚至比某些人喜欢挂在嘴边的“宇宙最强”,在某些方面更加强大。

我这里并不想具体比较哪些功能,那不重要。重要的是,浏览器颠覆了典型的IDE的标准工作流程(编辑-编译-运行-调试)。这里不需要编译,而且所有代码,包括 HTML/CSS/Javascript,全部可以在运行时修改,修改后立即可以看到效果。你可以在 Web 开发工具中进行任意调整,并马上看到最终效果,即便改错了,大不了 Undo 或者刷新一下页面就好了。

那些沉迷于静态语言的程序员可能还没有意识到这种开发模式带来了多么惊人的开发生产力。在主要基于静态语言的庞大的IDE中,为了让开发者看到界面修改的效果,需要通过 IDE 提供的 Visual Editor,但是这种模式存在显著的弊端:

  • 哪怕最强大的 Visual Editor,和最终运行的效果往往也存在细节上的差异,越是动态的程序,这些差别越明显;
  • Visual Editor 通常极其耗费资源,且容易出现问题(我已经看过无数次WPF编辑器抛出各种莫名其妙的异常了);
  • Visual Editor 是个复杂的工程,现实中往往需要很长的开发周期,不能满足程序员的要求。比如 Visual Studio 的 WPF 编辑器在3.0的时代烂到几乎没法用,到4.0以后才算踏上合格线;
  • 因为 Visual Editor 的效果不完整,所以程序员往往还是要跳过编辑器,运行程序来查看最终效果。但这时哪怕只改动一行代码,也要经过完整的编译/重新运行的循环。现代语言已经改善了这个循环,但反复执行这个过程仍然是个烦人和拖累速度的工作。

这同时可以解释另一个问题:为什么曾经风行一时的 HTML 编辑器,包括 Adobe Dreamweaver,微软的 FrontPage 和后来的 Expression Web,现在都没落了。因为这些编辑器受从前的设计风潮影响,将编辑网页的过程设计成一种所见即所得(WYSIWYG)的工作模式,然而Web浏览器本身已经成为极其强大的工作平台,且直接能看到最终结果,这种情况下在编辑器里再实现一个不完整的 Visual Editor,实在是没有必要。从现代IDE的发展我们也可以看到这种趋势。过去微软还把 WebForm 的拖放式开发作为卖点来宣传,现在这种模式也已经没落了。几乎所有的 IDE 都是从浏览器运行网页,而很少有哪种再去自己设计一个 HTML Visual Editor。

我还记得几年前 CSDN 杂志曾经有一篇文章讲到“可视化”是有害的思维。可惜但当时没有把文章保存下来。我并不认为“可视化”的思想一无是处,但是在今天还看到许多程序员在宣传可视化拖拉界面才是高效的开发方式,这就不太正常了。Web 开发不需要可视化,却构建了一个无比庞大的生态和先进的开发效率,领先的网站甚至可以做到一天之内更新几十次。这是那些陷入客户端开发思维的小伙伴们值得好好思考的。