作者denkeni (Denken)
看板Soft_Job
標題Re: [討論] 未來JS based將是App開發主流？
時間Fri Feb 24 22:16:54 2017
※ 引述《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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1487874240.A.DDA.html
1F：推 TETZ: 我是覺得很適合新創一開始要可以跑的app但之後使用者多了還 02/24 15:32
2F：→ TETZ: 是要調校performance這時就得往更底層去 像fb app一開始也是 02/24 15:32
3F：→ TETZ: 用web view而已 那我不如直接開網頁版的就好 後來有大幅更新 02/24 15:32
4F：→ TETZ: 效能好像有好一點吧 02/24 15:32
FB App 打從一開始就是 native app，而且還是爆強到蘋果放官網推薦
是 v4 期間強推 HTML 5 開發，結果問題一大堆
從 v5 開始砍掉重練，又改回用 native 寫
React Native 出來後，僅部分採用
5F：→ netburst: ig不就是用RN嗎??? 02/24 16:19
6F：推 thinkpadT450: IG 不是就是用 RN 嗎? 我覺得 RN 用起來沒有很明顯 02/24 19:58
7F：→ thinkpadT450: 的效能問題啊，都說是 native 了，RN 成本是不會寫 02/24 19:58
8F：→ thinkpadT450: react redux 要花一些時間成本，樓上在說效能的是 02/24 19:58
9F：→ thinkpadT450: 不是誤會成 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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1487945819.A.C41.html
10F：推 thinkpadT450: 感謝說明~ 原來只有某些頁面，我也不覺得 js 會完 02/24 22:33
11F：→ thinkpadT450: 全取代 native，不過我想幫 RN 說說話的部分是 RN 02/24 22:33
12F：→ thinkpadT450: 沒有慢到如同某些回文所說的完全不考慮的地步 02/24 22:33
13F：推 gerojeng: 推這篇 02/24 22:38
14F：噓 ggttoo44: RN,絕對不是開發一次跑全部平臺，android跟ios一共要開 02/24 23:02
15F：→ ggttoo44: 發兩次加上，要懂那個平臺不同特效，只是用共同語言罷了 02/24 23:02
16F：→ ggttoo44: 加上web等於還是一共開發三次XDD 02/24 23:04
17F：噓 ggttoo44: FB在android上還有發布一個圖片的libs，甚至改到c底層去 02/24 23:06
18F：→ ggttoo44: 改變android對圖片的存緩機制跟暫存空間 02/24 23:06
19F：噓 ggttoo44: 三個平臺特性不同，api也不同，學習成本也是3次，開發 02/24 23:08
20F：→ ggttoo44: 成本也是3次 02/24 23:08
21F：推 Rachelmas: 樓上也是噓三次 沒有RN開發三個平台不是本來就開發成 02/25 00:00
22F：→ Rachelmas: 本三次了嗎… 有了RN開發成本<=三次不好嗎 而且android 02/25 00:00
23F：→ Rachelmas: 跟ios跨平台何止共同語言而已 很大部分的code都是相同 02/25 00:00
24F：→ Rachelmas: 的 02/25 00:00
25F：→ qwdfbn: 我也是認為在成本上會比較省。效能的話，我想絕大部分的AP 02/25 00:07
26F：→ qwdfbn: P是不用碰到多底層的，RN就很夠用了 02/25 00:07
27F：推 justben: 比較大的問題/好處 是它兩個禮拜更新一版 有點High啊 XD 02/25 00:12
28F：→ netburst: 開發三次是哪招 RN的開發概念熟了 IOS跟安卓基本上底下 02/25 00:43
29F：→ netburst: 的API CALL都是RN幫你做掉了 連畫面幾乎都可用JSX搞定了 02/25 00:43
30F：→ netburst: 當然有很多原生的需求需要自己下去寫原生模組 02/25 00:43
31F：推 Argos: 我要是老闆 我也還是選原生 就算最簡單的也還是用原生吧？ 02/25 01:15
32F：→ Argos: 畢竟是原廠推薦 最保險阿 02/25 01:16
33F：→ alog: 首先你要像有程度的隊友開發起來才爽快 02/25 02:21
34F：→ alog: 不然乖乖找原生工程師比較快 02/25 02:21
35F：→ alog: 畢竟出錢開發的是你老闆跟客戶 若是因為省錢碰RN有點找自己 02/25 02:23
36F：→ alog: 的麻煩 02/25 02:23
37F：→ j1988922: 全rn要提也是airbnb不是ig，雖然我覺得他改爛了XD，目前 02/25 09:10
38F：→ j1988922: 最麻煩是rn本身和lib版本變動大，但減少開發時間效果是 02/25 09:10
39F：→ j1988922: 顯著的，用在小型app很ok ，反正功能也是常在改(誤 02/25 09:10
40F：推 dophin332: == 3 要講成 <=3 我也是醉了 02/25 18:04
41F：推 dophin332: 那我是不是也要凹成用了 >= 3種以上的技術 02/25 18:06
43F：→ ggttoo44: 賴，看起來純RN不碰原生也是不夠的 02/26 00:30
44F：→ angusyu: 講這麼多.這種東西有公司敢用就去用，能少個對手慢走不送 02/26 02:00