[转文章] Nodejs关于浏览器端我们的开发工具

[转文章] Nodejs关于浏览器端我们的开发工具

[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 都是有趣的例子 代码当中的信息能够更清澈地呈现出来, 以后也会有更多便利


2 回复

[转文章] Node.js 关于浏览器端我们的开发工具

在现代Web开发中，我们经常使用各种工具来提高开发效率。本文将探讨一些常用的开发工具，并展示如何利用它们改进我们的开发工作流。

旧的开发模式

传统的Web开发流程通常是这样的：

  1. 编辑HTML或JavaScript文件。
  2. 保存更改。
  3. 打开浏览器查看效果。
  4. 如果效果不理想，则重复上述步骤。

这种开发模式虽然简单，但效率低下。即使现在的浏览器提供了强大的调试工具，例如Chrome开发者工具，开发过程仍然遵循上述基本步骤。

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

更快的编辑

随着技术的发展，LiveReload等工具的出现极大地提高了开发效率。这些工具可以自动检测文件变化并刷新浏览器，使开发人员可以更专注于代码编写而不是手动刷新页面。

例如，node-dev是一个非常流行的Node.js开发工具，它可以在代码发生变化时自动重启服务器，从而提高开发效率。

// 使用 node-dev 启动服务器
node-dev server.js

浏览器中的编辑

最新的Chrome开发者工具引入了Workspace功能，允许开发人员直接在浏览器中编辑代码。通过将本地代码映射到浏览器中的Source Panel，开发人员可以直接在浏览器中进行代码修改，并实时看到效果。

// 在Chrome开发者工具中设置Workspace
1. 打开Chrome开发者工具（F12）。
2. 转到Sources面板。
3. 点击右上角的“Add folder to workspace”按钮。
4. 选择你的项目目录。

服务端代码的处理

虽然浏览器中的编辑功能很方便，但对于服务端代码（如Node.js代码），我们仍然需要使用专门的编辑器。例如，Sublime Text、Visual Studio Code等都是不错的选择。

# 使用VS Code编辑Node.js代码
code server.js

远程调试协议

为了更好地支持多浏览器调试和统一开发体验，Adobe的Brackets和Sublime Web Inspector等工具都引入了远程调试协议。这些协议使得开发人员可以在不同的环境中调试代码，而不需要频繁切换浏览器。

// 使用远程调试协议调试Node.js代码
// 例如，使用Chrome开发者工具连接到Node.js进程

总结

尽管现有的开发工具已经非常强大，但我们仍需继续探索新的工具和技术来提高开发效率。标准化的远程调试协议将为未来的Web开发带来更多可能性。希望本文对你理解现代Web开发工具有所帮助。

希望这篇文章对你有所帮助！如果你有任何疑问或需要进一步的信息，请随时提问。


这篇文章主要探讨了Web开发工具的演变及其存在的问题，并提出了对未来标准化远程调试的需求。以下是对其中一些关键点的总结及示例：

关键点总结

  1. 旧的开发模式：

    • 尽管调试工具（如Chrome DevTools）变得越来越强大，但开发的基本流程并没有发生根本变化：编写代码 -> 保存 -> 刷新 -> 再次测试。
    • 示例代码简化版：
      function build() {
  // 编辑文件
  edit('a.html');
  // 保存文件
  save('a.html');
  // 刷新浏览器
  refreshBrowser();
  // 如果成功，输出"done"
  if (status === 'ok') {
    console.log('done');
  } else {
    // 如果失败，递归调用build
    build();
  }
}

  2. 更快的编辑：

    • 使用LiveReload或node-dev等工具可以实现代码更改后的自动刷新，提高开发效率。
    • 在Chrome DevTools中引入Workspace功能，使得可以直接在浏览器中编辑本地代码并实时保存。

  3. 存在问题：

    • 兼容性问题：需要支持多种浏览器。
    • 用户偏好问题：每个人习惯的编辑器不同。
    • 服务端代码的管理：如何处理服务端代码的编辑和调试。

  4. 标准化远程调试：

    • 提出建立统一标准的远程调试方案，例如Chrome的远程调试协议、Firefox的类似协议等。

示例代码

// 使用node-dev进行开发
const nodeDev = require('node-dev');

// 启动node-dev服务器
nodeDev.run(['your-app.js']);

总结

尽管目前的工具已经非常强大，但在用户体验和多平台兼容性方面仍需改进。未来的发展方向可能是推动标准化的远程调试解决方案，从而为开发者提供更加高效便捷的开发体验。

回到顶部