建站
咨詢
售后
建站咨詢
新聞中心
81.go + vue實現(xiàn)web應(yīng)用程序
前端框架越來越豐富，前后端分離已經(jīng)是大多數(shù)軟件團(tuán)隊采取的模式了。vue使用的場景也越來越多。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：主機(jī)域名、網(wǎng)絡(luò)空間、營銷軟件、網(wǎng)站建設(shè)、儋州網(wǎng)站維護(hù)、網(wǎng)站推廣。
go本來使用template模板來進(jìn)行前端的表現(xiàn)，現(xiàn)在可以用vue來分擔(dān)很大一部分工作了。
通常直接使用go語言寫后端，然后使用靜態(tài)模板加載渲染前端，前端獲取后端提供的數(shù)據(jù)是使用{{ }}符號，2個套在一起的花括號。這個也是vue使用的數(shù)據(jù)表現(xiàn)方式。
如果go+vue來協(xié)同工作的話，需要對vue進(jìn)行一點(diǎn)設(shè)置。比如把{{ }}的方式改為[[ ]]的方式。
首先我們要知道，vue的使用，需要在頁面中加載vue.js或vue.min.js
純靜態(tài)網(wǎng)頁使用vue是這樣的（給個html例子）
然后我們實現(xiàn)一個go的簡單web服務(wù)和模板頁面
這個go服務(wù)器通過端口 1989 展示服務(wù)器頁面，提供了一個靜態(tài)文件路徑 htmlpage，我們把vue.js和index.html文件都放置在htmlpage路徑里。
go服務(wù)器還用模板給前臺頁面提供了一個News結(jié)構(gòu)的數(shù)據(jù)，數(shù)據(jù)包括：Title,Content,Author的值。
在index.html頁面中，加載vue.js的時候需要帶上靜態(tài)路徑 htmlpage
在 new 一個 vue 變量的時候，必須有一句來設(shè)置包裹數(shù)據(jù)的符號，我們這里設(shè)置這個符號為[[ ]]
同時，所有需要由 vue 渲染的數(shù)據(jù)，都寫成類似這樣的樣子
在 go + vue 方式下的完整模板文件 index.html
此頁面中{{ }}包裹的數(shù)據(jù)是由go從后端提供的數(shù)據(jù)（ 例如：{{.Title}}），而[[ ]]包裹的數(shù)據(jù)，是vue渲染的數(shù)據(jù)。
只是把 Vue里的數(shù)據(jù)，改為由go后端提供即可。
好吧，作者已經(jīng)在向月亮示愛了。呵呵 _
運(yùn)行一下程序，看修改模板后的效果。
寫小程序，什么語言跨平臺兼容和性能較好？golang
我最早使用的語言是Java和Python， 并且一直都對Python充滿好感， 我喜歡這種很樸實和高效率的感覺， 但我卻最后沒有采用Python，原因其實也很簡單， 我就是不喜歡縮進(jìn)語法， 就跟很多人換工作僅僅是為了屏幕更大一點(diǎn)一樣， 另外就是有了同樣很棒的可選方案， 這就是Ruby， 所以我最終采用了Ruby作為主力編程語言， 同樣也為不能使用Python而有一點(diǎn)小遺憾，畢竟Python的健壯性比Ruby好很多，只不過Ruby也一直在進(jìn)步， 所以這一點(diǎn)無傷大雅
我們都知道，無論是Python還是Ruby，甚至Java， 都是在解決業(yè)務(wù)層的問題， 屬于應(yīng)用型語言， 以解決業(yè)務(wù)邏輯為主， 但還有一個領(lǐng)域是系統(tǒng)領(lǐng)域，偏網(wǎng)絡(luò)層和底層操作，在這一塊我一直在尋找一種優(yōu)雅的方案， C++被我首先給淘汰掉了， C的開發(fā)效率太低， Java倒是比較合適， 就是太臃腫，而且缺少系統(tǒng)編程的基因，畢竟它是企業(yè)級開發(fā)出身的
最后我選擇了Erlang， 因為它在網(wǎng)絡(luò)層方面表現(xiàn)優(yōu)秀， 同時容錯性和健壯性都很不錯， 它的虛擬機(jī)是唯一可以跟JVM媲美的， 而且還有OTP的超重量級武器， 幾乎可以是通殺網(wǎng)絡(luò)層應(yīng)用， 但根據(jù)我的總結(jié)它有一個硬傷和一個軟肋，這一點(diǎn)后面展開，可以說選擇Erlang是我目前所知道的方案里面是最優(yōu)的
直到有一天我了解了Golang， 我知道Golang其實也蠻早的， 大概08年的時候就知道Google在搞一門奇怪的語言， 之后的幾年，一直有不少以老莫為代表的人在嘀咕Golang， 其實我一直沒太關(guān)注，我從ROR中吸取的經(jīng)驗是，成熟度對于商用很重要， 后來基于Golang開發(fā)的產(chǎn)品越來越多，讓我不得不去研究一下， 這我才知道， 這就是我夢想中的Python， 效率和性能達(dá)到了最佳的平衡，對Go了解越多， 就越不愿意用Erlang寫代碼，主要原因：
1、Erlang的硬傷在于代碼的可讀性、表現(xiàn)力， 讓我來舉個小例子， 比如你為你的系統(tǒng)軟件構(gòu)建一個RESTFUL的接口，我們大致了解一下代碼風(fēng)格，先不說Erlang， 無論是你c/c++/python/ruby/java 出身， 對Go是不是有種很久違的感覺, 為什么說是硬傷？ 因為對一門語言來說，語法是不大可能會大幅度變更的， 而且不會出現(xiàn)大的變化， 我不知道有沒有人讀過《松本行弘的編程世界》，里面闡述的道理很明白， 真正好的編程方式是人去主宰計算機(jī)而不是計算機(jī)主宰人， 我感覺Erlang就有點(diǎn)主宰我的編程思維的感覺(我的視力本身就不好，它還在不斷的扼殺我的眼睛！)， 編程首先是門邏輯學(xué)，其次是工程學(xué)，最后才是數(shù)學(xué)， 又讓我想起吳軍的《數(shù)學(xué)之美》所說的， 人工智能上個世紀(jì)一直在走彎路， 期望機(jī)器的高度圖靈完備， 而忽視人類本身已有的文明，統(tǒng)計歸納的應(yīng)用
2、Erlang的軟肋在于高質(zhì)量的庫少，盡管有不少殺手級應(yīng)用， 同樣Go在這方面也是軟肋， 這一點(diǎn)對于一個不到五年的語言有情可原， 但對于一個20多年的語言是不是有點(diǎn)說不過去， 比如你用json解析庫，很多人都是從mochiweb這個基本不更新的庫中去抽取， 而我認(rèn)為對于類似json這種東西可以考慮融入到語言標(biāo)準(zhǔn)庫中， 因為未來的商業(yè)軟件的api化趨勢越來越明顯，說的難聽點(diǎn) ， 一個倚老賣老一個與時俱進(jìn)，反正我對Golang的庫一點(diǎn)也不擔(dān)心， 目前的成績易經(jīng)非常棒了， 遠(yuǎn)遠(yuǎn)優(yōu)于Ruby/Python的前五年， 可參見已有的高質(zhì)量的庫列表
3、Erlang不合群， 這主要體現(xiàn)在跟其他語言的交互性上， 當(dāng)然這也有深層次的原因， Erlang本身有自己的哲學(xué)， 如出錯恢復(fù)機(jī)制， 你融入一個其他語言的東西進(jìn)去， 這帳就不好算，就好比你硬要讓一個喝咖啡的跟一個吃大蒜的坐在一起， 總之你寫一個Erlang的port遠(yuǎn)遠(yuǎn)比Go復(fù)雜， 甚至比Python/Java還要復(fù)雜， 這就造成了Erlang在底層編程上效果不是很好， 沒法利用linux已有的很多優(yōu)秀成果，我一直認(rèn)為Erlang的什么的mysql/pg/oracle驅(qū)動都沒有必要存在， Erlang一定是一個self-container應(yīng)用， 你只要用到了其他東西， 根據(jù)木桶理論， 你就不敢號稱9個9，以系統(tǒng)的眼光看問題， 我覺得一個系統(tǒng)的魯棒性不能依賴于某一組件， 這也是為什么愛立信本身的Erlang應(yīng)用并不廣泛
4、說說數(shù)據(jù)類型吧， 我不止聽到1個人說Erlang對字符串的處理不有好， 它把string當(dāng)做list來處理，其實本質(zhì)上是該這么，但，還是那句話， 違背了面向人的哲學(xué)， 應(yīng)該做一些DSL， 比如Golang里面的 := 就是一個糖衣， 等價于 var xx yyy = zzzz， 大大方便的程序員少敲不少字符, Golang里面對字符轉(zhuǎn)可以說基本和python差不多， slice map函數(shù)很強(qiáng)大， 支持lambda條件，雖然Erlang的基本類型很少， 但有很多構(gòu)造， 所謂構(gòu)造等價于Golang里面復(fù)雜的struct， 也奇怪了，我就是感覺Erlang構(gòu)造傷眼睛好嗎？可能是各種括號的比對的原因吧， 而且我認(rèn)為這是不必要的， 顯然Erlang缺少DSL的基因， 當(dāng)然跟Erlang出身的年代有關(guān)， 我不夸張的說， 自打用Erlang以后我的視力又下降了100度左右， 我不是很喜歡lisp所說的符號也是一種語法， 可能這又跟函數(shù)式編程有關(guān)吧：形式推導(dǎo)遠(yuǎn)大于邏輯演繹
5、其實我最不關(guān)注的是性能問題， 因為隨著摩爾定律， 單位計算單元的性價比會無限高，但Golang既然提出它的性能逼近C， 那我還是提一下吧， 當(dāng)然， Erlang也還可以， 雖然比Java慢， 但跟Python一個檔次吧
6、再談?wù)剤箦e機(jī)制， 因為Erlang的的報錯信息太讓人糾結(jié)了， 起初以為我不會看出錯信息， 后來也使用了Sasl， 還是不夠直觀，甚至有時要用工具分析crash文件來定位問題，還是跟Erlang的哲學(xué)有關(guān)， 在Erlang中一切都是并行的， 所以它根本不care是物理哪一行出錯， 只跟Actor綁定， 然后告訴你Actor的ID和出錯代號， 你自己憑經(jīng)驗去分析吧，這樣做的好處是可以很方便定位出并行中出現(xiàn)的問題，但凡事都是相對的， 在這一點(diǎn)上有點(diǎn)糾枉過正，根據(jù)我的經(jīng)驗， 絕大部分時候我只希望先給我明確的指出哪一行出錯了好嗎？ 甚至把順序的backtrace用完整的英文句子打印出來好嗎？至于并行中的錯誤及時在命令式多線程語言中是不常見的，雖然并不是沒有， 但遇到錯誤我再費(fèi)勁去調(diào)試好了， 但并不是所有的邏輯都用并行的思維去定位問題， 我甚至認(rèn)為， 對于一個系統(tǒng)不完全是并行也不完全是串行，跟好比我們衡量世界不能單純的唯物也不能完全的唯心一樣， 這一點(diǎn)Golang就做了很好的折中， 不需要并行的時候你老老實實的寫串行代碼， 需要并行的時候也有較復(fù)雜的機(jī)制來應(yīng)對， 合乎情理
7、再說說招人吧， 以前招過好幾個C出來的人，說實話水平很好， 可以一周就完成一個小組件， libevent用的熟的很，后來我逼人家用Erlang，結(jié)果把人家逼走了，至今我還很后悔， 自己的一廂情愿強(qiáng)加在別人身上真是太不合適了，但我招純Erlang出來的人，可以說比招objc的人還難， 沒有人，空談技術(shù)的優(yōu)雅性首先就是不靠譜的，再看看郵件列表， Golang的活躍度明顯比Erlang高很多， 基本逼近Ruby，更重要的是， 我根本不擔(dān)心Golang的人才，因為只要熟悉Python/C/Ruby/或者C++， 基本可以實現(xiàn)半天入門， 之后就可以噼里啪啦邊搜資料邊干活了，雖然有足夠的深度，但門檻極其平緩，工程人員也可以復(fù)用很多已有的知識。 Erlang在這一點(diǎn)其實跟第一點(diǎn)硬傷有關(guān)，大部分人學(xué)一周都摸不著頭腦，不是每個人的抽象思維和世界觀都是一樣的好嗎， 所以函數(shù)式編程盡管不比命令式語言起步晚，但始終學(xué)的人很少，這就是歷史， 對于大部分人， 更希望解決問題，創(chuàng)造價值， 而不是數(shù)學(xué)來推導(dǎo)去
8、最后我建議， 如果你是玩c/c++的， 現(xiàn)在開始學(xué)Golang，是最好的時機(jī)， 跟一門靠譜的語言一起成長， 這種感覺非常棒， 你用Erlang折騰1個應(yīng)用， 用Go恐怕都完成了10個開源項目， 當(dāng)然，也要結(jié)合自己的口味， Golang就是Sublime Text， Erlang就是Emacs
相信自己的判斷，相信自己的邏輯， 贏就是贏，輸就是輸
轉(zhuǎn)載僅供參考，版權(quán)屬于原作者。祝你愉快，滿意請采納哦
go語言支持開發(fā)桌面級應(yīng)用嗎？
go 可以開發(fā)桌面應(yīng)用，但并不是很舒適。
可以使用的GUI庫有：
1、goqt，LiteIDE作者出品，Go和QT的綁定，還未發(fā)布
2、go.uik，純Go實現(xiàn)的并發(fā)UI工具
3、walk，Windows Application Library Kit
4、gform，Windows GUI framework
目前的話walk用得比較多
不過go的GUI庫用起來沒有C#、C/C++的那么順手。
這個問題不久之后應(yīng)該會有所改善，畢竟用Go開發(fā)桌面的需求在不斷增加。
目前我采用的是用go http 做后端，Webkit+HTML5 做界面，表現(xiàn)力很好，前端不需要學(xué)習(xí)新知識，一般的管理類應(yīng)用都能搞定。
網(wǎng)頁標(biāo)題：go語言實現(xiàn)小程序 go語言怎么運(yùn)行
文章分享：http://ef60e0e.cn/article/ddjpgpc.html
