工具開發閒聊：從AutoIT到Electron / DIY Tools: From AutoIT to Electron
最近在重灌電腦之後興起了使用AutoIT和Electron各種小工具的念頭。這篇並不是特別介紹或教學關於這些開發技術的方法，只是想要記錄一下我到底用AutoIT和Electron開發的過程，以及這些過程的想法。
這篇混雜了大量我的自言自語跟技術名詞，請不要勉強看懂，或著說，其實也沒什麼必要看吧？
起因：SSD硬碟壞了 / Beginning: My SSD is broken
(圖片來源：露天拍賣，非當事硬碟)
我想先來聊聊SSD壞掉的這件事情。
這是我用SSD固態硬碟以來，第一次遇到SSD整顆壞掉的情況。以前我也用過內裝SSD的筆電，可是在SSD壞掉之前，筆電就因爲內建電池完全無法運作，也無法拆開，就在電源都無法啓動的情況下壞掉了。
這次SSD壞掉的情況也蠻奇怪的。我的Google Chrome瀏覽器安裝在SSD硬碟上，大家都知道Google Chrome瀏覽器會用到大量暫存與設定檔，不斷讀寫硬碟檔案。我在遇到需要Chrome大量讀寫檔案的情況，例如開啓LINE擴充套件同步訊息時，或是開啓Google雲端硬碟用到離線備份時，電腦就會彷彿死當一樣停止任何運作長達數分鐘。在這期間，只有滑鼠鼠標正常運作，其他畫面完全靜止。
(圖片來源：阿榮福利味，數值非當時情況)
那時候我就覺得這是硬碟IO的問題。我試着找了幾個硬碟檢測的工具來測測看，各個工具都說我的SSD沒問題。又過了一陣子，隨着讀取IO卡住的情況越來越頻繁，後來終於在一次重開之後，整個硬碟都無法讀取，SSD也就壽終正寢了。
重灌電腦才會想到工具很難用 / Where is the ideal tools?
買了一顆新的SSD，重灌電腦的時候，又讓我想到另一個問題：軟體工具。
我習慣選擇可攜式版本的軟體。這些軟體放在跟SSD不同的另一個硬碟上，然後再到開始程式集建立捷徑。因此重灌電腦時，需要完全重新安裝與配置的程式其實不多。儘管如此，在整理這些程式的時候，我還是強烈地覺得很多工具都不盡人意，覺得非常難用。
(圖片來源：循序樣式探勘：以Python的PrefixSpan實作)
舉例來說，以前我在編輯CSV試算表的檔案時主要使用的是LibreOffice Calc，但其實我並不會用到LibreOffice Calc衆多的功能，主要只是需要檢視資料、排序、篩選而已。題外話，忽然想起以前有人問我怎麼用試算表插入圖片，作出像是產品型錄那樣子的檔案，這......爲什麼不要用Writer或Draw來做排版呢？
像這樣的例子非常多。大多時候我只想要個輕量工具來檢視檔案，但我卻得用大型編輯器來開啓它。在效能不錯的桌機上還比較不是問題，但是在小型筆電上，開啓大型編輯器可真的需要等上好一段時間。
(圖片來源：Travel with Leo)
另一方面，我一直很想要在桌面作業系統使用類似Android的桌面環境。以前我用過XLaunchpad，一個模仿Mac OX X的啓動器，也類似Android的桌面。但它似乎連Mac的精緻與動畫都模仿起來，大量的動畫讓我在遠端桌面操作時非常緩慢。它另一個問題是沒能跟開始程式集整合。我用滑鼠或觸控板的時候很需要啓動器，另一方面，我在用鍵盤的時候則仰賴開始程式集的搜尋功能，而這兩種方式我都會需要開啓同樣的應用程式。在Windows上，這類型的啓動器，不論是XLaunchpad還是WinLaunch，它們都需要獨立設定，跟Windows的開始程式集並無整合。
除了Windows之外，我在Chromebook上crouton裡面的Xfce環境下也會需要類似的啓動器。雖然Ubuntu是類似的Slingshot套件，但一直以來我都安裝失敗，不知道是什麼原因。
好吧，與其期待別人做好工具，不如自己動手作吧。
開發工具的選擇 / From AutoIT to Electron
(圖片來源：Windows圖片轉灰階工具)
我之前會用AutoIT做些跟檔案系統整合的小工具，像是「Windows圖片轉灰階工具」。用AutoIT撰寫並不算很困難，而且在Windows上運作良好。但如果應用程式要有使用者操作界面的話，比起AutoIT那種類似Visual Basic的介面，我還是比較喜歡以製作網頁的邏輯來開發。另一方面，AutoIT也只能在Windows環境下運作，並不能同時在Linux環境中使用。
剛好今年開始大量接觸Node.js的世界，比起以往粗淺的「試做Electron桌面應用程式：webapp-wrapper」，現在應該能夠更加掌握Electron。這段日子我除了製作撰寫Blogger的編輯器Blogger Editor之外，還做了將網址轉換成Chrome APP的捷徑產生工具Chrome WebAPP Shortcuts Creator、簡單的壓縮與解壓縮工具AutoIT Archive Util 、可以檢視與簡單編輯常見試算表檔案格式的Electron Simple Spreadsheet Editor、應用程式啓動面板Electron Launch Pad、便利貼兼建議剪貼簿、文件和圖片檢視器Electron Sticky Notes。
這些工具至今都還不算完成。我仍然在一邊使用、一邊修正Bug。另一個問題是，我使用Electron Builder打包成安裝檔的過程並不順利，目前沒有製作成發佈檔的打算。現在我主要是用指令來啓動這些Node.js的原始碼，對一般人來說用起來並不直覺，但對我來說，這樣倒是可以一邊使用一邊修正，反而便利的多。
Chrome APP產生器 Chrome WebAPP Shortcuts Creator
這是一個建立捷徑的工具。它可以讓你把網址加入Google Chrome的命令列後的--app參數中，這樣可以使Google Chrome以「APP」模式直接開啓指定網址，此時網址列、頁籤等介面不會出現，一個視窗就是一個網頁。詳細的說明我已經在「自製網頁應用程式！使用Chrome的命令列選項app來製作網頁應用程式捷徑」介紹過，在此就不深入講了。
我很常把網頁作爲應用程式使用。爲了這個目的，我做過很多不同的工具。一開始是以網頁呈現的「建立指令的網頁程式」，這是幫你寫好捷徑需要的參數，但其他建立捷徑、選擇圖示的細節則是要你自己來。
後來我覺得要抓圖示真是太麻煩了，於是就用Node.js寫了一個輸入網址就自己幫忙抓圖示、還會轉換成ico格式的工具。但那時候不熟悉Node.js的使用者介面，輸入網址的程式還是用AutoIT介接。雖然大部分時候這樣的程式能正常運作，但是一旦遇上了奇怪的網址，轉換出現問題的時候，我也很難去偵錯。久而久之就希望工具能具備更複雜的介面，能讓我有更多客製化。
最後我決定使用Electron以網頁來建立使用者介面，再搭配後面的Node.js截取網頁標題、敘述、以及圖示，就成了現在這個樣子。
Electron帶來的好處 / Benefits from Electron
(圖片來源：YouTube)
用了Electron之後還多了很多額外的好處，其中一個最有感的好處是能夠直接取得剪貼簿(clipboard)的內容。這樣我就能在開啓程式的時候自動偵測剪貼簿裡面是否有網址，有的話就自動輸入到網址的輸入框，就能讓程式直接去抓取標題和圖示等資訊。操作起來非常順手。
而做成Electron的另一個好處就是可以跨平臺使用。只要爲Node.js安裝了相對應的套件，我就能將能在Windows上運作的程式轉移到Linux上運作。當然，Windows的捷徑跟Linux的desktop應用程式捷徑並不相同，還需要搭配「process.platform」偵測不同作業系統環境。爲Linux環境做了小調整之後，程式就能順利運作，可喜可賀。
(圖片來源：something-about-javascript)
然而，當我想要繼續更進一步地把程式打包成發佈用的安裝檔時，問題就來了。
Electron只是一個串接Node.js跟Chromium網頁的框架，要把它打包成安裝檔或是可執行的應用程式，我們還需要其他工具的配合。我使用的是知名的打包工具Electron Builder。在Windows上，它可以產生安裝檔nsis、免安裝可攜式檔案、或是直接的壓縮檔；在Linux上則可以產生deb、rpm等因應不同套件管理工具的安裝檔。若要產生該平臺的發佈檔，則必須在該平臺上執行打包才行。也就是說，我確認程式在Windows上可以順利運作之後，就能用Electron Builder打包成Windows安裝檔。而在Linux上可以運作程式之後，也能在Linux上打包對應的安裝檔。
乍看之下各平臺都能使用，很符合Electron跨平臺的目標。不過實際使用的時候，才發現問題重重。
在Windows的環境中，我一開始想把它打包成可攜式的檔案，Electron Builder會把整個專案打包成一個exe檔案，只要開啓這個exe檔案就能執行。但這個可攜式檔案跟我想像中的運作方式不太一樣。我本來以爲它是真的獨立運作的檔案，不過實際上它是整個專案的壓縮檔。執行exe的時候，它會把程式碼解壓縮到系統暫存資料夾，然後再開啓真正的執行檔，這樣才能運作程式。而程式關閉時，它會把剛剛解壓縮到系統暫存資料中的檔案全部刪除，不留任何痕跡。如果解壓縮檔案不大，這樣的方式也許很不錯。但問題是Electron Builder打包的專案動輒200MB起跳，裡面數百的大小檔案。每次開啓程式就要在暫存區寫入這200MB以上的資料，然後關閉程式時又要刪除這200MB的資料，這怎麼叫人受得了。發現這個事實之後，我就改用單純的壓縮檔來打包。雖然最後會產生大量的檔案，但省下了開啓時解壓縮、關閉時刪除暫存檔的動作，運作起來比較簡單。
另一方面，在Linux環境中，因為我用的是Ubuntu環境，理論上用deb應該是比較合適，我就嘗試用Electron Builder打包成deb檔案。結果Chromebook的空間一瞬間就用完了，飛也似的爆炸。我花了點時間清出Chromebook的儲存空間，再來產生deb檔案，結果卻遇到了Electron執行權限的問題。雖然細節我有點忘了，但就是執行環境sandbox在權限設定上有問題，需要手動先修改權限，才能正常執行。經過一番苦鬥之後終於能夠安裝deb，但裝上去所佔用的大量空間，又讓我不得不立即把它移除。
最後，考慮到修改、同步更新程式碼的需求，加上每次打包都太過麻煩了。我後來就都只以指令開啓Electron應用程式。在Windows環境中，因爲只有exe才能建立捷徑並釘選固定的緣故，我還要再加上bat跟AutoIT編譯成的exe檔案才行。這一弄下來就變得不太友善，也不容易發佈。
我想想，算了，等那天真的很有心，我再來製作發佈檔並撰寫介紹吧。
Blogger編輯器 Blogger Editor
自從Open Live Writer無法正常運作之後，我就打算自行建立一個寫Blog的編輯器。這也成為了我現在寫Blogger的主要工具。
在製作Blogger Editor的時候，我是想要把它做成一個Web APP，能夠直接放在GitHub Page上讓大家直接使用。不過我自己在用的時候，通常是直接把它以Chrome WebAPP的形式開啓。有興趣的人也可以直接用GitHub Page開啓看看，剛剛試了一下，還好還可以正常運作沒問題。
爲什麼不是用Electron開啓呢？因爲Electron應用程式的右鍵選單跟直接在Google Chrome裡面開啓並不同，需要由開發者自行建立。如果沒有特別設定，基本上按右鍵就不會出現任何選單。
Webpack跟Vue.js的初探 / Start to Webpack and Vue.js
製作Blogger Editor的時候，我的主要目的是練習Webpack與Vue.js。關於Webpack的好處，我在「閒聊Blogger範本程式碼的管理」裡面已經有提到過。「布丁布丁吃什麼？」並沒有用到Vue.js，我在Blogger Editor裡面用同時使用Webpack跟Vue.js的時候，才強烈感受到兩者在一起的威力。特別是我很容易使用Vue.js的單文件組件(Single File Components)，將複雜的系統拆開成HTML樣板、LESS樣式、JS邏輯、JSON語系等多個檔案，非常好用。
不過那時候雖然有把Webpack摸熟，但是卻沒有熟練地掌握Vue.js。我沒有熟悉的掌握單文件組件的用法。現在回來看還真是慘不忍睹。直到我在做Electron Sticky Notes的時候，才算是比較能夠掌握Vue.js。
做到現在，加入了OCR之後，Blogger Editor的開發也告一段落了。我也不打算再變動它的架構，就這樣吧。
壓縮工具 AutoIT Archive Util
- GitHub儲存庫：https://github.com/pulipulichen/AutoIt-Archive-Util
- 下載：https://github.com/pulipulichen/AutoIt-Archive-Util/releases/tag/1.0.0
重灌電腦的時候，我時常需要整理電腦裡面的檔案。我會將不需要使用的檔案壓縮成一個資料夾，方便歸檔。很久以前我使用HaoZip，後來它改名為2345好壓，感覺好像藏了什麼奇怪的功能，所以後來我就不再使用。本來我是用PeaZip作為主要的壓縮與解壓縮工具，但PeaZip操作界面真的很難用。很多選項都很瑣碎，每次壓縮都要設定，太煩了。
於是我就在想，為何不要乾脆自己做呢？這就是AutoIT Archive Util的由來。
AutoIT的優勢 / Strengths of AutoIT
雖然之前已經逐漸採用Electron，但這次要做的壓縮工具，充其量只是將7 Zip的指令包裝起來的工具，應該不會做得很複雜。而且我比較熟悉AutoIT取得指令列參數的做法，相較之下我對Electron取得指令列參數的做法還沒研究，所以這次就先採用AutoIT來實作。
實際上做到最後，因為還要考慮到壓縮時的不同情境，有許多要檢查資料的功能，不得不把整個架構擴大。這也是我第一次把AutoIT的程式碼拆開來開發，但結論來說，我覺得很不順手。
現在AutoIT Archive Util已經完成了，不過畢竟它只能應用於Windows環境下，不太泛用。後來摸索過Electron之後再回來看看它，其實還是可以把它做成Electron應用，這樣子在Linux平臺也能有個簡單壓縮與解壓縮的工具，那就比較好了。
試算表編輯器 Electron Simple Spreadsheet Editor
我之前許多資料分析的教學都是使用CSV檔案，後來逐漸改用開放文件檔案格式ODS，這兩者大多都得要用LibreOffice Calc才能正常開啟。可是老實說，LibreOffice Calc很慢， 這種大型文件編輯器都是一樣慢。而且我大多時候並不需要編輯器的複雜功能，反而只需要篩選、搜尋等簡單的功能。為了查些資料而開啟大型編輯器，頗有殺雞焉用牛刀的困擾。
(圖片來源：Rons CSV Editor)
本來我是用一個免費的CSV編輯與檢視器Rons CSV Editor，先別說它免費版有諸多限制，它本身的功能就不太好用。我就在想，奇怪，怎麽大家都不會用免費又好用的表格工具呢？
(圖片來源：Handsontable)
我找了一下，果然有以網頁瀏覽器運作的試算表工具：Handsontable。這個套件不僅高度可客製化，而且操作邏輯相當接近LibreOffice Calc這種主流的編輯器環境。有興趣的人可以看看他的Demo網頁。如果你的網站有需要呈現大量表格資料，那使用像是Handsontable這種表格工具，絕對比你畫<table>標籤還要實在的多。
於是我就將Handsontable調整到自己最常用的功能，外圍再加入Semantic UI的選單列和按鈕等使用介面，做成了Electron Simple Spreadsheet Editor。接著再納入Node.js中對於不同試算表檔案格式的支援，使這個編輯器能夠載入以下各種格式：
- CSV：逗點分隔檔，使用SheetJS js-xlsx處理。
- ODS：開放文件檔案試算表，使用SheetJS js-xlsx處理。
- XLSX：Microsoft Excel，使用SheetJS js-xlsx處理。
- ARFF：Weka使用的屬性關聯檔案格式，使用node-arff跟arff-utils處理。
- Sav：SPSS跟PSPP使用的檔案格式，使用sav-reader讀取，但不能存成sav格式。
其中我覺得ARFF跟Sav兩種格式特別好用，這樣我就可以簡單地用Electron Simple Spreadsheet Editor檢視檔案內容，不需要花功夫地開啟Weka跟PSPP才能檢查檔案了。感謝NPM套件庫，總是能夠找到大家熱心分享的好用工具。
用了Electron跟Vue.js，卻不敢用Webpack / Use Electron and Vue.js without Webpack
Electron Simple Spreadsheet Editor的目標是作為作業系統上的編輯器。為了能夠開啟檔案、寫入檔案，我一開始就決定要以Electron的形式開發。但這時候問題就來了，Webpack雖然能夠打包Node.js套件裡面的檔案，但對於Electron裡面的許多套件內容，Webpack是沒有辦法處理的。
這下子我只好捨棄Wepback，直接用Vue.js跟less.js來建構版面，也就是做一個不編譯的網頁應用程式介面。因為Electron Simple Spreadsheet Editor的版面沒有很複雜，大部分時候都是處理Handsontable跟Electron在各種檔案格式、編碼之間的轉換，簡單地使用Vue.js跟less.js建構使用者介面倒也不是什麼問題。
結果下一個專案，我就發現這樣子問題可大了。
應用程式啓動面板 Electron Launch Pad
在桌面程式是主流的時候，大家對於啟動程式的做法是「開始」按鈕。在Windows 7的時候，微軟為「開始」加上了搜尋功能，而這個搜尋功能在Windows 10的Cortana加持之下更為強大。到了手機時代，大家開始習慣用一張大列表來列出程式。原本是按照字母順序排序，後來發展到可以自由拖曳決定位置、收合至資料夾，建構一個「符合自己思維模式」的應用程式啟動面板。
用過Android的啟動器之後，真的很難接受Windows缺乏啟動器的這個使用方式。特別是在使用了具備觸控螢幕的Chromebook之後，我也無法在Crouton裡面安裝類似啟動器的套件，觸控操作的優勢大打折扣。這使我一直很想要一個理想的應用程式啟動面板。
用網頁技術實作啟動器 / Implement launchpad with JavaScript
在開發Electron Simple Spreadsheet Editor的時候，我嚐到了網頁技術的甜頭，於是就想著能不能也可以兜一些JavaScript套件來打造啟動器。摸索了一陣子，呃，很難。要實作像是Nova Launcher這種精緻的啟動器，似乎並沒有那麼簡單。
好吧，退而求其次。只要幫我把指定資料夾的捷徑列成4x4的16格，然後讓我能用某種方法來排序就好了吧。
(圖片來源：Draggable JS)
於是我找來了Draggable JS，讓捷徑可以用拖曳來排序。再加上幾個透明的格子塞在一起，這樣就能讓捷徑拖曳到4x4的任意一格當中就好。
有了可拖曳之後，就想要做子資料夾的功能。這部分我是用Semantic UI的Popup來實作。
至於搜尋功能，這則是Vue.js的強項，使用計算屬性computed就可以根據搜尋條件快速重新產生符合條件的列表。
未能善用Vue.js / Failed to make good use of Vue.js
但問題來了，Vue.js會吃掉Draggable JS跟Semantic UI設定的事件。因為Vue.js會在資料變更時重新繪製DOM，這會導致外部函式庫需要重新為被重繪的元素一一套用，這樣拖曳和資料夾視窗才能正常生效。
另一方面，隨著應用程式啟動面板的元件逐一增加，全部都寫在一個Vue裡面的方式，實在是令人吃不消。我需要像Blogger Editor那時候用單文件組建的方式把功能拆開，這樣會重複使用的地方才能有效復用，不必重複撰寫。
最後一個是更麻煩的問題：引用函式庫會在全域環境下發生衝突。
網頁在瀏覽器裡面運作時，它們是以window物件為最上層，各個JavaScript檔案共享全域物件。在Node.js運作時，如果沒有特別做module.export，那各個JavaScript檔案是個別獨立運作，彼此互不干擾。
但是在Electron應用程式中，後端運作的Node.js是以個別獨立運作為主，而前端的畫面顯示則是會在全域之間彼此影響。當程式越寫越複雜的時候，在全域之間發生相互衝突的情況越來越常見，寫到後面真的是令人受不了。
我開始懷念起Webpack的美好了。
萬能便利貼 Electron Sticky Notes
就在這個時候，我忽然覺得我需要一個好用的便利貼工具。原本我是用Stickies，我還特別寫了一個可以讀取剪貼簿的AutoIt Stickies Opener，但是Stickies在中文的支援上還是有點問題，而且我不太喜歡它保留文件格式的這個功能。很多時候我只是要去除格式的純文字，這樣才能方便貼到其他文件編輯器裡面，不會汙染其他文件的格式。
我在開發Electron Launch Pad專案之後，還是深深覺得Webpack有其必要。但用Wepback打包Electron會出問題，這該怎麼處理好呢？後來在看Electron APP時，發現StickyNotes這個Electron APP竟然有用到Webpack打包編譯。雖然我並沒有弄清楚StickyNotes到底是如何整合Electron跟Webpack，不過這至少讓我知道，有方法可以把這兩者兜在一起。
Electron + Wepback + Vue.js
把Webpack跟Electron相互整合的最直覺做法，就是讓Electron套件獨立運作，而其他的程式碼全部都用Webpack打包。這想法實作起來很簡單，這樣子只有Electron相關套件會存在在全域環境中，用Wepback打包Vue.js及底下的單文件組件的方式仍然可以正常運作，實作起來相當順利。
這次我也認真去學習Vue.js單文件組件的用法，確實地建構最上層Vue以及底下的組件，並用prop在組件之間共享所需要的資料data。這樣可以確實將大型的應用程式拆成相當小的組件，而組件各自獨立運作，不會彼此干擾。
這樣做有另一個好處，當每個組件都小到容易維護的時候，我就能為組件寫比較複雜的功能。考慮到之前Semantic UI之類的套件會被Vue.js影響，這次我就把它們拉到Vue.js之外，由組件去控制額外元素的建立和更新。這種以Vue.js為主、其他套件為輔的架構做起來相當得心應手，也十分容易維護。
再來就是一樣找尋一些好用的套件工具，讓便利貼不僅能夠直接讀取剪貼簿、變成純文字檔案內容，它還能開啟各種不同的文件檔案：
- 純文字檔案內容：使用<textarea>實作，最單純的格式。
- 程式純文字檔案內容：會依據程式語言不同標亮程式語法，在閱讀JSON或XML的時候特別好用。這裡使用的是CodeMirror套件。
- 帶有格式的文件檔案內容：我將各種可能會附帶格式的文件格式轉換成HTML再來呈現。雖然這可能會導致格式不對，但如果只是簡單看一下文件內容的話，這樣倒是挺方便的。這裡支援ODT、DocX、Markdown。
- 向量圖片檔：以前一直找不到好瀏覽器來開啟SVG，現在可以用它了。這裡使用單純的<img>實作。
- 點陣圖片檔：我加入了大圖瀏覽工具OpenSeadragon，能用滑鼠拖曳畫面、滑鼠滾輪縮放比例，還有縮圖導覽，這才是我想要的圖片瀏覽器啊。
雖然看起來好像可以開啟很多不同類型的檔案，但它本質上還是個便利貼，所以沒有多餘的UI，只有最重要的「置頂」，還加入了「用預設編輯器開啟」的功能，也可以直接修改或儲存。
為了讓編輯器更為順手，我也使用了Keypress加入熱鍵。這個熱鍵函式庫是我試過幾個不同函式庫之後找到比較好用也直覺的函式庫，推薦給想要為網頁加入各種熱鍵的人使用。
嗯，我真的是是自己的編輯器自己做啊。
程式的生命週期 / Life-cycle of system
(圖片來源：Vue.js)
在這次開發中，我體悟到了定義程式生命週期的重要性。Vue.js有自己的一套生命週期的規範，我們通常會等到Vue走到mounted的時候，就會認為它已經把整個畫面準備好了。不過在Vue底下還有很多單文件組件時，到底什麼時候才是所有畫面完全準備好，似乎就很難釐清。
這次我在資料data裡面額外加入了progress，裡面定義了程式運作時各個不同的階段，每個階段在開始的時候都是false。當所有組件都準備好之後，我就會改變progress的階段，而其他組件則依需要用watch來監控階段的變化，執行對應階段所需要的任務。
這個做法有效區分了我需要各個組件在不同階段所要完成的工作。各組件只要知道它要在那個階段進行即可，不需要瞭解各階段何時變化、以及各階段是怎麽變化。釐清程式生命週期對於程式運作真的有很大的幫助，特別是對JavaScript這種很多時候都在非同步情況下運作的程式而言，讓各個程式排隊運作更是重要。
結語：探索程式開發風格 / In closing: What's the best practice?
在做到Electron Sticky Notes的時候，我總覺得稍微比較能夠掌握Electron、Webpack跟Vue.js。不過我在想，在Webpack跟Electron的整合上，應該會有更優雅的做法。我看過有人把Electron直接放在Wepback裡面一起編譯，只是在Webpack設定檔中排除Electron套件，這樣就不會因為Electron而編譯失敗。
不過，我比較想要把Electron這種跟作業系統比較緊密結合的相關工具獨立出來，未來應該要打包成跨平臺的函式庫。如果是在桌面作業系統，那就用Electron；如果是在行動端的載具，那就用Cordova。但因為這幾個專案幾乎都是為了桌面作業系統操作，最適合有鍵盤與滑鼠的使用情境，目前沒有把它們用在行動端的打算，所以就還沒有積極朝向這方向發展。
另一個問題是，這些專案都是單人使用的情境。對於桌面應用程式來說，一次一個使用者操作是蠻正常的事情，我們不需要在考慮多人協同作業的互動情境。不過因為我的論文本身就是一種合作學習，而且現在越來越多軟體也強調多人協同作業的特色，要怎麼建構背後同步資料的伺服器，就是我接下來主要需要鑽研的議題了。
我稍微碰觸了Sails.js跟Feathers，但並沒有想象中的順利。我會在另一篇再來聊這個問題，這篇就先這樣吧。
那麼這次對於AutoIT到Electron的開發過程閒聊就到這裡了。寫到最後，我有些問題想問問大家：
- 你有用AutoIT開發過應用程式嗎？你覺得AutoIT的方便和不便之處在那裡呢？
- 同樣的，你有用Electron開發過應用程式嗎？你覺得Electron的方便和不便之處在那裡呢？
- 除了上述的AutoIT和Electron之外，你還會用什麼方法來開發應用程式呢？
歡迎在下面的留言處跟我們分享你的想法。大家的意見是我繼續分享的動力喔！如果你覺得我這篇實用的話，請幫我在AddThis分享工具按讚、將這篇分享到Facebook等社群媒體吧！
感謝你的耐心閱讀，我是布丁，讓我們下一篇見。
