PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 未來JS based將是App開發主流？

看板Soft_Job (軟體人)作者 (Denken)時間9年前 (2017/02/24 22:16), 編輯推噓4(7推 3噓 25→)
留言35則, 12人參與, 最新討論串2/7 (看更多)
※ 引述《ripple0129 (perry tsai)》之銘言： : 開發一次跑多平台 : 這樣的效益 : 遠遠大於Android iOS Web開發三種來的高 看似簡單合理的推論 往往需要精心計算加上血淚經驗 才能得知是否真如想像一般 : 手機的硬體效能越來越強大 : 撇開遊戲不說 : 當硬體速度快到一定程度 : 單純的應用似乎也沒必要以原生開發 : 當JS based開發方式達到一定數量 : 手機OS廠商勢必是也要顧及廣大的使用者 : 對JS based開發方式有某種程度的優化 早在 iOS 7 就內建於系統的 JavaScriptCore 就是 React Native 運作的核心之一 你也可以理解為 手機 OS 廠商如蘋果，其實早已顧及了 JS based 開發方式？ : 個人認為在這個重視開發速度與維護性的 : 軟體思維下 : 以及軟體人員的成本與日俱增 : JS based的開發模式未來將會超越原生開發 : 成為主流中的主流 : 大家是否也這樣認為？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.196.101 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1487874240.A.DDA.html
推
02/24 15:32,
我是覺得很適合新創一開始要可以跑的app但之後使用者多了還
02/24 15:32
→
02/24 15:32,
是要調校performance這時就得往更底層去 像fb app一開始也是
02/24 15:32
→
02/24 15:32,
用web view而已 那我不如直接開網頁版的就好 後來有大幅更新
02/24 15:32
→
02/24 15:32,
效能好像有好一點吧
02/24 15:32
FB App 打從一開始就是 native app，而且還是爆強到蘋果放官網推薦 是 v4 期間強推 HTML 5 開發，結果問題一大堆 從 v5 開始砍掉重練，又改回用 native 寫 React Native 出來後，僅部分採用
→
02/24 16:19,
ig不就是用RN嗎???
02/24 16:19
推
02/24 19:58,
IG 不是就是用 RN 嗎? 我覺得 RN 用起來沒有很明顯
02/24 19:58
→
02/24 19:58,
的效能問題啊，都說是 native 了，RN 成本是不會寫
02/24 19:58
→
02/24 19:58,
react redux 要花一些時間成本，樓上在說效能的是
02/24 19:58
→
02/24 19:58,
不是誤會成 web view 了
02/24 19:58
https://facebook.github.io/react-native/showcase.html 官方 Showcase 其實很開明，連各家技術文章都附上了 我讀過的幾篇大都還是 native 為主、React Native 為輔 以 Instagram 來說，比較可能點到用 React Native 寫的頁面 是推播通知設定 你用的主要功能都還是用 native 寫的 -- 我最近寫了一個 iOS App 叫作「工作咖啡館」 https://goo.gl/iBWJSs -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.84.246.198 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1487945819.A.C41.html
推
02/24 22:33, , 1F
感謝說明~ 原來只有某些頁面，我也不覺得 js 會完
02/24 22:33, 1F
→
02/24 22:33, , 2F
全取代 native，不過我想幫 RN 說說話的部分是 RN
02/24 22:33, 2F
→
02/24 22:33, , 3F
沒有慢到如同某些回文所說的完全不考慮的地步
02/24 22:33, 3F
推
02/24 22:38, , 4F
推這篇
02/24 22:38, 4F
噓
02/24 23:02, , 5F
RN,絕對不是開發一次跑全部平臺，android跟ios一共要開
02/24 23:02, 5F
→
02/24 23:02, , 6F
發兩次加上，要懂那個平臺不同特效，只是用共同語言罷了
02/24 23:02, 6F
→
02/24 23:04, , 7F
加上web等於還是一共開發三次XDD
02/24 23:04, 7F
噓
02/24 23:06, , 8F
FB在android上還有發布一個圖片的libs，甚至改到c底層去
02/24 23:06, 8F
→
02/24 23:06, , 9F
改變android對圖片的存緩機制跟暫存空間
02/24 23:06, 9F
噓
02/24 23:08, , 10F
三個平臺特性不同，api也不同，學習成本也是3次，開發
02/24 23:08, 10F
→
02/24 23:08, , 11F
成本也是3次
02/24 23:08, 11F
推
02/25 00:00, , 12F
樓上也是噓三次 沒有RN開發三個平台不是本來就開發成
02/25 00:00, 12F
→
02/25 00:00, , 13F
本三次了嗎… 有了RN開發成本<=三次不好嗎 而且android
02/25 00:00, 13F
→
02/25 00:00, , 14F
跟ios跨平台何止共同語言而已 很大部分的code都是相同
02/25 00:00, 14F
→
02/25 00:00, , 15F
的
02/25 00:00, 15F
→
02/25 00:07, , 16F
我也是認為在成本上會比較省。效能的話，我想絕大部分的AP
02/25 00:07, 16F
→
02/25 00:07, , 17F
P是不用碰到多底層的，RN就很夠用了
02/25 00:07, 17F
推
02/25 00:12, , 18F
比較大的問題/好處 是它兩個禮拜更新一版 有點High啊 XD
02/25 00:12, 18F
→
02/25 00:43, , 19F
開發三次是哪招 RN的開發概念熟了 IOS跟安卓基本上底下
02/25 00:43, 19F
→
02/25 00:43, , 20F
的API CALL都是RN幫你做掉了 連畫面幾乎都可用JSX搞定了
02/25 00:43, 20F
→
02/25 00:43, , 21F
當然有很多原生的需求需要自己下去寫原生模組
02/25 00:43, 21F
推
02/25 01:15, , 22F
我要是老闆 我也還是選原生 就算最簡單的也還是用原生吧？
02/25 01:15, 22F
→
02/25 01:16, , 23F
畢竟是原廠推薦 最保險阿
02/25 01:16, 23F
→
02/25 02:21, , 24F
首先你要像有程度的隊友開發起來才爽快
02/25 02:21, 24F
→
02/25 02:21, , 25F
不然乖乖找原生工程師比較快
02/25 02:21, 25F
→
02/25 02:23, , 26F
畢竟出錢開發的是你老闆跟客戶 若是因為省錢碰RN有點找自己
02/25 02:23, 26F
→
02/25 02:23, , 27F
的麻煩
02/25 02:23, 27F
→
02/25 09:10, , 28F
全rn要提也是airbnb不是ig，雖然我覺得他改爛了XD，目前
02/25 09:10, 28F
→
02/25 09:10, , 29F
最麻煩是rn本身和lib版本變動大，但減少開發時間效果是
02/25 09:10, 29F
→
02/25 09:10, , 30F
顯著的，用在小型app很ok ，反正功能也是常在改(誤
02/25 09:10, 30F
推
02/25 18:04, , 31F
== 3 要講成 <=3 我也是醉了
02/25 18:04, 31F
推
02/25 18:06, , 32F
那我是不是也要凹成用了 >= 3種以上的技術
02/25 18:06, 32F
→
02/26 00:30, , 33F
https://goo.gl/lxWRZJ 看看大陸公司用的經驗談也不
02/26 00:30, 33F
→
02/26 00:30, , 34F
賴，看起來純RN不碰原生也是不夠的
02/26 00:30, 34F
→
02/26 02:00, , 35F
講這麼多.這種東西有公司敢用就去用，能少個對手慢走不送
02/26 02:00, 35F
‣ 更多 denkeni 的文章
文章代碼(AID): #1Oi41Rn1 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 7 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共7篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 denkeni 的文章
文章代碼(AID): #1Oi41Rn1 (Soft_Job)