有谁能告诉我们CEF和Electron的区别是什么？关于Electron，既然Electron是基于 chrome 的，为什么要使用NodeJS而不是直接使用 chrome 中的V8引擎
qlfbtfca1#
CEF是第一批 Package Chromium功能并提供可供第三方应用程序使用的API的解决方案之一。Chromium是一个独立的桌面应用程序。CEF将其表示为一个框架。由于Chromium是使用C编写的，因此CEF表示C开发人员的框架，但有许多用于Java、.NET和Python的端口。CEF的主要目的是让C开发人员将Chromium嵌入到他们的C跨桌面应用中并访问Chromium功能，如渲染（包括离屏）、DOM、V8、PDF Viewer、打印、网络请求/响应、Cookie等。这类应用程序的例子有Steam、Spotify、Adoby Brakets等。电子考虑到CEF和Electron源代码非常相似，我可以假设：
电子== CEF +节点js
Electron的主要目的是**让JavaScript开发人员在Chromium之上构建跨平台桌面应用程序。Electron应用程序中的每个窗口都代表一个Chromium窗口，用于呈现特定的网页或HTML。Electron应用程序的GUI使用HTML、CSS和JavaScript构建。逻辑（后端）使用Node.js编写。
如果你是一个C开发人员，CEF是适合你的，它允许你将Chromium嵌入到现有的C桌面应用程序中，并创建电子C++跨桌面应用程序。如果你是一个JavaScript开发人员，想要用HTML、CSS、JavaScript GUI创建一个跨桌面的应用程序，并且不想学习Qt、Gtk、可可、Java Swing/JavaFX/SWT、Flutter等更高效的技术和框架，那么Electron就适合你。
ztigrdn82#
回答第二个问题-- NodeJs是Chromium引擎的补充，而不是在Electron中替代它。请浏览this great article以了解框架内的进程通信。简而言之-a有两个主要参与者：
*主（或“主机”）进程-在NodeJ上运行，可以访问操作系统功能，负责Windows编排并提供对本机功能的访问*渲染器进程-实际Chromium示例，带有额外绑定，允许与主进程“对话”
关于框架之间的差异-这是一个广泛的问题，一般来说，它们涵盖了相同的需求，大多数差异都在技术方面：
没有明确的“赢家”或“输家”，上面的每一项（以及最上面的一些）都需要额外的研究，记住你的用户群、开发团队在相关技术堆栈方面的经验、应用程序的复杂性等
00jrzges3#
我对给出的两个答案都不完全满意。无论您使用的是CEF还是Electron，其思想都是使用浏览器技术构建桌面应用程序的“前端”/“客户端（HTML、CSS、JavaScript）。这允许您编写（大部分）前端一次，并在不同平台上运行（Chrome可以运行的任何平台）。此外，这些框架允许您通过更高级的API使用Chromium代码库，而不是必须从源代码构建 chrome 并处理其所有的复杂性（回答OP中的第二个问题）。[@弗拉基米尔说得对，CEF还有其他“嵌入式”用例，比如在应用程序中显示PDF。在这个答案中，我假设大多数使用这两种平台的人都对编写跨平台桌面应用程序感兴趣，其中“前端”是用HTML、CSS和JavaScript编写的。此外，现在或将来可能会有以类似方式嵌入Electron的可能性。]对于应用程序的“后端”/“服务器”部分，您可以选择任一框架。如果您的后端是C++，使用CEF确实有一些好处，其中之一是您可以将后端代码放在与CEF构建相同的流程/项目中，并且后端可以在流程中直接与前端对话，而不必使用IPC（如localhost HTTP）。类似地，如果你的后端是在节点，它将与电子工作，而不必使用IPC在客户端和服务器之间交谈。然而，在这两种情况下，你都可以用任何你想要的语言/框架来编写你的后端/服务器。客户端/UI/应用程序启动，启动服务器进程，并与之通信。使用localhost HTTP是一个不错的选择，因为它与真正的基于Web的设置（网页与远程服务器对话）并行。我使用CEF很长一段时间了，最近换用了Electron。尽管我的后端是C++，但我发现Electron是一个更好的工具，因为通过Node可以获得额外的跨平台功能。例如，Node具有显示标准的打开和保存文件对话框以及截图的功能。当使用Electron时，可以使用Node函数。当使用CEF时，我不得不分别为Macintosh和Windows编写这些函数。更一般地说，CEF是更低级的。例如，在使用CEF时，您提供自己的WNDPROC，而使用Electron时，您不必考虑该级别。此外，Electron被打包为一个npm模块，与CEF相比，您可以将Electron作为dev依赖项添加到package.json文件中，这非常神奇。整个业务都在node_modules的子目录中进行管理，您无需担心。为了调试，我可以在VisualStudio中运行我的C服务器代码。然后，当我的电子应用程序启动时（通过运行“npm start”），它将检查服务器是否已在运行，如果已在运行，则使用它（否则将其作为子进程派生）。这些程序通过localhost HTTP进行通信。因此，在同一进程中运行服务器与在其他进程中运行服务器之间的差别非常小（使用C和CEF，或Node和Electron），而不是将服务器作为一个单独的进程运行，这样你就可以用你想要的任何语言编写服务器。一位同事用Python做了她的服务器，工作方式都是一样的。就我而言，这确实意味着有三个领域需要考虑：客户端代码（HTML、CSS、JavaScript）、节点层（Node/JavaScript）和C后端/服务器进程。对我来说，Node/JavaScript层在客户端和C服务器之间传递消息，还处理一些常见的UI功能，如上所述。最后，Electron有许多开发人员和一个大的社区。据我所知，CEF仍然是由一个非常小的团队开发的，所以有较少的教程，堆栈溢出问题，等等。而且，使用Node提供通用函数，如上面描述的对话框，是一个更安全的选择，因为有一个更大的社区和更完善的API比使用C++跨平台库，如POCO。
3条答案
按热度按时间qlfbtfca1#
CEF
CEF是第一批 Package Chromium功能并提供可供第三方应用程序使用的API的解决方案之一。Chromium是一个独立的桌面应用程序。CEF将其表示为一个框架。由于Chromium是使用C编写的，因此CEF表示C开发人员的框架，但有许多用于Java、.NET和Python的端口。
CEF的主要目的是让C开发人员将Chromium嵌入到他们的C跨桌面应用中并访问Chromium功能，如渲染（包括离屏）、DOM、V8、PDF Viewer、打印、网络请求/响应、Cookie等。
这类应用程序的例子有Steam、Spotify、Adoby Brakets等。
电子
考虑到CEF和Electron源代码非常相似，我可以假设：
电子== CEF +节点js
Electron的主要目的是**让JavaScript开发人员在Chromium之上构建跨平台桌面应用程序。Electron应用程序中的每个窗口都代表一个Chromium窗口，用于呈现特定的网页或HTML。Electron应用程序的GUI使用HTML、CSS和JavaScript构建。逻辑（后端）使用Node.js编写。
使用哪一个？
如果你是一个C开发人员，CEF是适合你的，它允许你将Chromium嵌入到现有的C桌面应用程序中，并创建电子C++跨桌面应用程序。
如果你是一个JavaScript开发人员，想要用HTML、CSS、JavaScript GUI创建一个跨桌面的应用程序，并且不想学习Qt、Gtk、可可、Java Swing/JavaFX/SWT、Flutter等更高效的技术和框架，那么Electron就适合你。
ztigrdn82#
回答第二个问题-- NodeJs是Chromium引擎的补充，而不是在Electron中替代它。请浏览this great article以了解框架内的进程通信。简而言之-a有两个主要参与者：
*主（或“主机”）进程-在NodeJ上运行，可以访问操作系统功能，负责Windows编排并提供对本机功能的访问
*渲染器进程-实际Chromium示例，带有额外绑定，允许与主进程“对话”
关于框架之间的差异-这是一个广泛的问题，一般来说，它们涵盖了相同的需求，大多数差异都在技术方面：
没有明确的“赢家”或“输家”，上面的每一项（以及最上面的一些）都需要额外的研究，记住你的用户群、开发团队在相关技术堆栈方面的经验、应用程序的复杂性等
00jrzges3#
我对给出的两个答案都不完全满意。
无论您使用的是CEF还是Electron，其思想都是使用浏览器技术构建桌面应用程序的“前端”/“客户端（HTML、CSS、JavaScript）。这允许您编写（大部分）前端一次，并在不同平台上运行（Chrome可以运行的任何平台）。此外，这些框架允许您通过更高级的API使用Chromium代码库，而不是必须从源代码构建 chrome 并处理其所有的复杂性（回答OP中的第二个问题）。
[@弗拉基米尔说得对，CEF还有其他“嵌入式”用例，比如在应用程序中显示PDF。在这个答案中，我假设大多数使用这两种平台的人都对编写跨平台桌面应用程序感兴趣，其中“前端”是用HTML、CSS和JavaScript编写的。此外，现在或将来可能会有以类似方式嵌入Electron的可能性。]
对于应用程序的“后端”/“服务器”部分，您可以选择任一框架。如果您的后端是C++，使用CEF确实有一些好处，其中之一是您可以将后端代码放在与CEF构建相同的流程/项目中，并且后端可以在流程中直接与前端对话，而不必使用IPC（如localhost HTTP）。类似地，如果你的后端是在节点，它将与电子工作，而不必使用IPC在客户端和服务器之间交谈。
然而，在这两种情况下，你都可以用任何你想要的语言/框架来编写你的后端/服务器。客户端/UI/应用程序启动，启动服务器进程，并与之通信。使用localhost HTTP是一个不错的选择，因为它与真正的基于Web的设置（网页与远程服务器对话）并行。
我使用CEF很长一段时间了，最近换用了Electron。尽管我的后端是C++，但我发现Electron是一个更好的工具，因为通过Node可以获得额外的跨平台功能。例如，Node具有显示标准的打开和保存文件对话框以及截图的功能。当使用Electron时，可以使用Node函数。当使用CEF时，我不得不分别为Macintosh和Windows编写这些函数。更一般地说，CEF是更低级的。例如，在使用CEF时，您提供自己的WNDPROC，而使用Electron时，您不必考虑该级别。此外，Electron被打包为一个npm模块，与CEF相比，您可以将Electron作为dev依赖项添加到package.json文件中，这非常神奇。整个业务都在node_modules的子目录中进行管理，您无需担心。
为了调试，我可以在VisualStudio中运行我的C服务器代码。然后，当我的电子应用程序启动时（通过运行“npm start”），它将检查服务器是否已在运行，如果已在运行，则使用它（否则将其作为子进程派生）。这些程序通过localhost HTTP进行通信。因此，在同一进程中运行服务器与在其他进程中运行服务器之间的差别非常小（使用C和CEF，或Node和Electron），而不是将服务器作为一个单独的进程运行，这样你就可以用你想要的任何语言编写服务器。一位同事用Python做了她的服务器，工作方式都是一样的。
就我而言，这确实意味着有三个领域需要考虑：客户端代码（HTML、CSS、JavaScript）、节点层（Node/JavaScript）和C后端/服务器进程。对我来说，Node/JavaScript层在客户端和C服务器之间传递消息，还处理一些常见的UI功能，如上所述。
最后，Electron有许多开发人员和一个大的社区。据我所知，CEF仍然是由一个非常小的团队开发的，所以有较少的教程，堆栈溢出问题，等等。而且，使用Node提供通用函数，如上面描述的对话框，是一个更安全的选择，因为有一个更大的社区和更完善的API比使用C++跨平台库，如POCO。