請問一下，跨平台解決方案中，Qt 和 Electron 孰優孰劣？

01-03

如果你需要開發一個大型的，會用到底層庫的，多線程的，網路庫的，各種字元編碼編解碼的，資料庫的程序，還有一些我想不到，但是如果做一個較為複雜的程序可能會用到的程序。你會選擇什麼方案？ QT還是Electron？或者還有其他？
為了使回答更有效率，我先做一個不成熟的回答，然後請回答的人給於反駁。
個人認為Qt的優勢更明顯，因為qt擁有成熟的natvie控制項庫，qml的動畫效果非常逆天，寫起來也和html差不多。性能上肯定也是qt更好。qt庫已經包含了我上樹所提到的所有基本庫供開發者使用，Electron沒用過不知道。
之於有些人說用Electron是避免重複造輪子，但是我覺得你既然用來開發桌面應用了，以前的東西應該是不適合的，一個桌面應用從布局到具體的功能實現都不可能和一個web應用相同，所以你還是得重新設計一遍。

另外，qt還支持安卓和ios，Electron不支持。
綜上所述，我覺得qt更勝一籌。
最近微信發布了個各個平台的桌面版，想請問一下，是否是基於qt的？我看了一下，微信的安裝目錄裡面有libGLESv2.dll libEGL.dll 這些庫，還有一個 qbcore.dll 看著很像qtcore。

看場景，不能一概而論說哪個更好。

Qt適合一些性能要求高的桌面應用，如果你只打算做桌面端的話。或者是一些特殊的場景，比如你要做個類似繪聲繪影的視頻編輯器，做個類似word之類的桌面應用，那你用electron要麼是沒法做，要不就是體驗非常爛。實際應用上，比如wps，yy語音，VirtualBox，以及部分adobe的桌面工具都是Qt做的。

Electron適合一些偏業務的應用，對性能沒有很多要求，主要是業務邏輯和UI展示，比較輕量級的應用。因為Electron可以一份代碼同時得到網頁版和桌面版，所以如果你的應用還需要網頁版，那麼Electron可以極大地節省你的開發和維護成本。比如釘釘，slack，現在越來越多的偏業務型（並不是需要高性能的專業工具）應用開始使用Electron來做了。

當然了，native還是web只是一種權衡，並不是有唯一答案的。

比如微信桌面版是native（當然不是Qt，是騰訊自己的UI庫）而定位類似的釘釘則是web。豌豆莢這個不需要網頁版的應用居然也是web方案（不是Electron，不過方案類似），wunderlist的win32版本也使用了web方案和網頁版共用一套代碼。

總的來說，native方案（Qt，WPF等）適合於高性能的專業應用，Electron適合想要把網頁版和桌面端共享代碼，同時對性能沒有苛刻要求的場景。如果不在乎成本，native一定是體驗更好的（微信），但是如果認為桌面端復用網頁版的體驗也能接受，那Electron成本會更低一些。

PS：其他回答說到了移動端。無論是Qt還是Electron都不應該考慮移動端，Qt支持很爛，Electron並不支持（官方已經表態不會考慮支持移動端）。這個問題顯然只是考慮桌面端的。

PPS：手機淘寶/手機京東並不是web app，不要想當然了。

PPPS：如果想用web方案，就用Electron，不要考慮用Qt去包一個QWebkit（或者任何其他讓你自己去包webkit的方案）。做當然是可以做的，不過這等於把Electron又實現了一遍（基本實現倒是簡單，但是細節上完善起來需要成噸的工作），同時還不能使用Electron社區已有的大量支持，何必呢。微軟都沒有選擇再造一個而是直接用Electron。

Qt在傳統的嵌入式領域無可替代，在跨平台桌面應用UI開發上也是為數不多的好選擇（相比於WxWidgets更成熟，同時能夠和各個平台自己的本身UI風格基本一致，畢竟實際上都是自己模擬繪製的，有些細微地方還是有差異），electron更多的是前端的一種延伸，前端本身在UI上的開發效率和輪子都是比較多的。完全是兩個都很完整的開發生態，各有優缺點，沒必要爭執一下哪個好。

技術選型更多還是考慮你的團隊人員技術積累（C++或者PyQt也行，跟前端，差異還是比較大的）和具體場景。

之前用過 Qt4，後來基於 Atom Editor寫過一些插件自己玩（不知道算不算用了 Electron？），現在天天在用釘釘，雲音樂之類的。

實在要比較的話，你可以類比用 Html5 開發的遊戲（比如神經貓之類）和 Native遊戲之間的區別。簡短點說，Electron開發項目是不錯，但也給你畫了一條紅線，讓你在享受它便利性和簡單性的同時，不能越雷池半步。

不知道你們有沒有沒發現，不管是網易雲音樂，釘釘，Atom Editor，Slack，這些基於 Chrome的桌面Web解決方案做出來的UI都是一大坨的么？就是一個 WebView控制項扔那裡，所有東西有且只能顯示在這個 WebView裡面，所有控制項都是由這個 WebView控制項自己繪製在裡面，你不能彈任何超越這個 WebView的對話框，多窗口，否則會麻煩死你，你想做wps，yy這類軟體，且不說性能問題，基本上是很難解的。

這種 App一般需要一個唯一的大窗口，要佔據屏幕比較大的空間，現成控制項雖然多，但用多了以後，所有這類app看起來都是黑雷同的。性能嘛，用過上面那些軟體的，各位應該有比較直觀的體驗，它比較擅長做控制項數量少的，每個控制項都是大拓大拓那種。

如果你的應用屬於上面這些類型，那麼挺好的，Electron 適合你。

再者，界面和 C++原生渲染的結合，Electron中，C++可以給後端的 nodejs寫一些 module，但要再前端 Chrome的 WebView裡面用 C++實現一些界面邏輯，目前我還沒看到比較好的方法（反過來Qt 的 Native窗體下嵌入一個 WebView卻很容易）。這就是說，你得完全基於 js/coffee 來完成你的界面邏輯，方便的同時，也給你畫了一條紅線，讓你不能越雷池半步，比如你想實現個 YY的房間，裡面有一個自己開發的播放器，用自己私有協議傳輸數據，或者用自己改過的編碼格式來解碼視頻，或者你有個效果（如3D翻頁）用 html很難以平滑的模擬，又或者某個控制項變化多端，html做起來太難了（比如一個 Excel的單元格，狀態實在太多了），你想用C++實現一下，那麼對不起，紅線畫那裡了。

最後，Electron對 Windows的支持太差了，bug不斷啊，簡直是，你們用用Atom Editor的windows版本，比如 One Light風格用了 Electron裡面 Native的滾動條，這個滾動條我提了至少三個bug，無數人抱怨，Mac/ Ubuntu下都沒問題。

如果你對這些都無所謂，就是個輕量級消費類 APP，產品經理不會有一天說給主窗口的列表控制項里加 2000個 ITEM，同時以後也不需要去接觸紅線外的東西，那麼 Electron挺適合的。

Electron 是個好東西，當然，對於紅線內的特定應用來說。

我選擇第三種路線：

QtWidgets + libcef + 若干 C++ 第三方庫。

理由：

1，為何不整體 web/js 化？

因為並非所有 UI 都適合用 web 做，比如基於 OpenGL 的模塊。另外，當業務層使用大量非 web 技術（比如 udp）甚至非標技術時，以 C++ 環境作為底層環境更方便。

2，為何不整體 native 化？

因為 web 內嵌帶來的開發效率和部署優勢（可以很方便地隨時更新甚至熱補丁）很吸引人。用 web 開發各種列表頁和增刪改查頁，實在太方便了。

3，為何不用 QML 而是 web？

因為對 QML 熟悉的開發人員並不那麼好找，QML 也沒有那麼豐富的前端框架可用。

4，為何不用 QWebEngine？

太新，沒見過案例（現在見過了）不是很信任。而且 blink 多進程模型潛在的問題不可控，libcef 老版本有單進程模型可用。

竟然有人拿Qt在macOS下達不到60FPS來說話，說是因為不支持Metal。我沒有用過Metal，我一直是原生Qt做開發，我不清楚Metal真的是開發macOS程序必須直接接觸的東西嗎？難道不用Metal就不能開發macOS程序了（黑人問號臉）

退一步說，答主貌似是在說基於QtWidgets的程序在R屏的macOS下達不到60FPS。我沒有做過具體的測試。但是我知道QtQuick在macOS下輕鬆就可以到60FPS，我寫了一個簡單的Demo，藉助Qt的profiler，我們可以看到如下結果：

第一個結果是我在iMac，27寸，13款非R屏，GTX 775M下跑出來的結果

如圖，幀間間隔不到16ms，剛好是60FPS的要求。

第二個結果是我在MacBookPro，15寸，15款R屏，Radeon R9 M370X下跑出來的結果

如圖，差不多的結果，不到16ms。

結論，60FPS，輕鬆到達。

另外據我所知，Qt早就已經對高分屏做了很多優化，尤其是5.6這個版本，這都已經不是一個平台的了，而是跨平台級別的優化。具體的不多描述，請移步

https://wiki.qt.io/New_Features_in_Qt_5.6

對了，關於QtWidgets，這個模塊Qt官方基本不維護了，已經交給第三方在打補丁，更別說加入Metal的支持什麼的。Qt的精力目前都在QtQuick這塊。而QtWidgets已屬遠古老物，如果不是有特殊需要，我也不建議各位Qt的開發者去使用。包括桌面端，移動端和嵌入式端。

謝邀

沒用過Electron，去看了下，大體思路就是把WebApp的開發模式遷移到桌面應用上。

其實針對app而言，是可以不用重複造輪子的，比如你看這個Cmd Markdown 編輯閱讀器 - 作業部落出品

這個的客戶端就是用WebApp模式做的，和web端一模一樣。並且放在桌面應用角度上也很和諧。

或者可以看看手機上的淘寶/京東，那個其實就是典型的WebApp。把它原模原樣遷移到桌面，也並不突兀，最多就是豎著的界面不好看。如果拉全屏怎麼辦？可以看UWP或者iPad上的應用，他們採用左右雙欄方式，除此之外和web並無區別。

所以Electron從界面開發角度上，比Qt是有優勢的，畢竟它背後站著整個Web技術體系，可用資源無比龐大。

當然，如果不考慮用別人輪子的話，Qt Qml開發效率和性能都比html5好，但缺點就是沒有龐大的各種輪子，並且需要額外學習，還是和這個框架綁死的超小眾語言。

雖然Qml不難學就是了，對於前端工程師應該毫無難度……

Electron在Android和IOS的支持么，就它的架構思路而言，其實並不難，還不支持只能說是尚未支持。

就像Qt尚未支持UWP一樣，做下封裝和API映射，其實也可以支持的。

當然，不能這麼簡單的把Qt和Electron等同掉。畢竟一個是純粹的Native Framework，只是套了一層Web-Style的GUI開發模式；而另一個是純粹的Web Framework，對native的支持反而不如Qt。

所以還是老樣子，Qt是用來開發Software的，Electron是用來開發Application的。

或者說，Electron是精於前端，而Qt是為後端打造了一個擬-Web前端的框架。

最後，Qt最有統治力的領域還是嵌入式平台的複雜應用軟體開發，包括帶界面和不帶界面的。受硬體平台限制，Electron在那些領域很難有所建樹。

——————————————————

鑒於Qt其實支持和JS直接對接（可以把QObject和信號槽直接和JS對接……），所以我們可以考慮把Electron和Qt融合起來用，一個寫界面，一個用來寫後台，其中Qt在後台主要負責通過事件系統和多線程統合各種類庫，這樣可以享受Web開發的便捷和C++的性能優勢了

如果跨平台的要求中包括誇移動平台，那麼 Electron 就已經排除再外了，再比較其他就沒意義了。

我認為都不是好選擇。我始終認為跨平台是偽需求。

尤其是gui

各個OS從內核到應用層完全不一樣。追求代碼一致。就必須忍受龐大臃腫，出錯不容易掌控。而且我基本上找不到任何一個不需要一點代碼修改就能在不同平台表現完美一致的UI代碼。

實際上如果你真的有跨平台的需求造多套輪子的代價不一定比只用一套高。比如我寫的qt基本有一半代碼是各個系統的API和彌合平台差距的代碼。出現各種bug調試起來非常困難。因為我很難確定是庫還是編譯器還是我的代碼的問題。

我認為搞個webkit是跨平台的好做法而且更適合移動端。

最後問一下。做什麼產品非得要Linux Windows mac加上手機全通呢?如果沒有這個需求還想這種事還不如早點下班回家陪陪老婆孩子(逃

我覺得也應該考慮開發成本吧，利用現在豐富的前端框架+css框架+h5+js庫做出一個好看且有動畫效果的軟體的成本比qt不知道小到哪裡去了好伐？

一切最終能用javascript搞定的應用最終都會用javascript

如果你的程序需要涉及一些底層的操作（例如取硬碟序列號，CPUID），那就不要用 Electron

其它答案都很有道理，然後我選擇了qmlweb。

開玩笑而已，我很喜歡qml，個人覺得簡直碾壓HTML CSS。所以一直關注qmlweb這個項目，雖然能穩定適用的版本還沒出來，各種功能也都還在開發中～

不過我覺得從開發調試方面，我覺得qt做得不是很好，畢竟社區力量不夠。

Qt Widgets 對 macOS 拒絕進行徹底的顯示加速優化，導致其效能瓶頸很難被突破。

可以看我在這樓貼的圖，Cubase 8.5 在 macOS 系統下根本無法突破 40fps（GTX 950）：

https://forum.qt.io/topic/59578/rendering-performance-problems-on-imac-with-retina-5k/8

FPS 就是 Apple 用來衡量 macOS 應用的介面顯示效能的單位，這不是 PC 電玩的專利。

（看評論區的詳細解釋）

我建議改用 Xamarin（Visual Studio .net for Mac），畢竟有 Metal 的支持；而 Qt Widgets 迄今為止仍舊拒絕、拒絕、拒絕支持 Metal＊（哪怕 Apple 即將淘汰全部的非 Retina 熒幕的 Mac 產品）。// 更新：Qt 改用 QML 也可以。

＊參考上述網址討論串內的討論，他們居然拿 PC Windows 用戶的高清熒幕使用比例統計數據來決定是否對 macOS 提供 4K 支持，荒謬透頂。

# EOF.

本質上是GUI程序的解決方案的比較，c++方案 vs html+css+js的web方案。三個問題：

1.就GUI而言兩個能力上是否等同？(c++能實現的界面操作效果，web方案是否都能實現)

2.哪個使用起來更方便？

3.web方案在一些場景下性能是否跟的上，是否有機制調用c/c++的介面（驅動）？

最後結合Qt也引入了類似的qml方案，並且揚言qml方案要逐步代替c++方案可以看出來第一和第二個問題的答案，能力等同，並且web的GUI解決方案使用起來更加方便，也可以說是這種DSL比c++更適合用來描述GUI。剩下的就是第三個問題，如果第三個問題能夠解決的話，全世界統一成一種GUI解決方案，我舉雙手贊同，共享控制項是多麼美妙的事情，現在這麼多種GUI框架，互相之間不能共享，重複造輪子，浪費時間。

這裡有一些比較

QML vs. HTML5 - Qt Blog

Qt vs. HTML5 for Cross-Platform Apps

今天拿qt在macOS上寫界面，類中聲明了一個QLabel的指針，我沒有用到這個指針，只是聲明了它，結果編譯成功，但執行的時候直接segment11，刪除這個指針後就好了。聲明一個指針都不行嗎？心中一萬個cnm奔騰，不知道是系統問題還是qt的問題，很絕望

跨平台首先考慮web一類的B/S解決方案，如果不是需要和本地硬體打交道，基本上應用效果都能用網頁實現。只有web才做到比較好的跨平台。沒有任何包袱，平台相關的東西交給瀏覽器解決。如果程序需要操作本地特殊的硬體，比如串口USB什麼的，才會考慮Qt。

LibEGL.dll, 是 OpenGL ES 和底層 Native 平台視窗系統之間的介面，和Qt本身是沒有關係的，qbcore.dll,也並非是Qt的，個人認為並不是Qt所開發的。來自①號程序員 Ps:假如能夠提供好的建議/意見給我，找到活，有獎勵哈！

還可以用java，參見jetbrains的產品，跨平台而且基本體驗都一致。