[转文章] 关于浏览器端我们的开发工具
发布于 12 年前 作者 jiyinyiyong 3478 次浏览 最后一次编辑是 9 年前

[Our web development workflow is completely broken.][blog] [blog]: http://blog.kenneth.io/blog/2013/05/21/our-web-development-workflow-is-completely-broken/

旧的开发模式

文章作者回顾了从 IE 到 Firebug 到 Chrome 这段时间调试工具的改变 得出结论来, 调试工具其实没有实质的变化, 当然, 功能上丰富了很多很多 现在 Chrome 若干 panel 的功能调试脚本调试 frame, 测试性能等等, 非常地强大 然而 Web 开发的本质流程依然是:

do build = (fronter) ->
  edit 'a.html'
  save 'a.html'
  focus 'Chrome'
  if this.status is ok
    console.log 'done'
   else
    do build

开发工具越来越完善了, 调试的手法越发多了. 加上了 LiveReload 之类自动刷新功能. 可实际上还是原来的套路, 改代码, 运行, 效果, 再改, 再运行…

更快的编辑

从 LiveReload 看, 开发主要就是为了让编辑代码更快更直接 JS 代码相对其他的语言, 代码短小更方便不断刷新来调整开发, 比如 node-dev

到了最新的 Chrome 当中, 这个想法被进一步加入到 DevTools 当中 Workspace 功能, 可以将本地代码加入到 DevTools 的 Source Panel 里编辑 DevTools 里内置了 CodeMirror 方便编辑代码, CSS 也有 Map, 从 Element Panel 直接编辑, 可以直接保存到本地的文件中 于是, 渐渐地浏览器本身成为了代码的编辑器, 一个编程环境

但这存在着问题:

  1. 存在很多浏览器需要兼容, 因此并不是一个浏览器中编辑能搞定
  2. 并不是每个人都喜欢同一个编辑方式, 大家的编辑器都不一样
  3. 服务端的代码怎么办?

麻烦在于, 这样的结果是编辑器不断被重新发明, 不如把经历放到新的领域去

接着作者在讨论 Chrome 的远程调试协议, Firefox 也有类似的协议 甚至很早的 Visual Studio 都有有类似功能… 作者呼吁推出标准化的远程调试的方案, 以便带来更多的可能

有趣的

Adobe 的 Brackets, 还有前段时间的 Sublime Web Inspector 都是有趣的例子 代码当中的信息能够更清澈地呈现出来, 以后也会有更多便利

回到顶部