講實話，JavaScript 要在 Embedded System 上發展，最後的問題，大概會卡在 Developer 的素質。嵌入式應用上，不像 PC 有這麼多的資源給你燒，User 也不會容許你的東西不順的跑，如網頁中緩慢或斷斷續續出現結果這件事是不被允許的呀。

使用GC的語言的通病啊

嘛...我覺得光是要叫Embbedded的開發者去了解JS 不等於Java就得花一番功夫了。

所以說，不要鳥 Emebbeded 的開發者。 XD.... 我相信懂 Web Tech 的開發者比搞 Java 的人還多。 XD

多慮了! 君不見五年前多數人還不能想像把 javascript 用在 server side/desktop 和手機。結果?!

我们公司只是把php拿来开发嵌入式 <- 好吧，我承认是因为我不会别的语言...

當然，如果你說的 embedded system 是指只有數 MB 、甚至數百 K 的 memory，那我就不敢說了。

Thinker : 我指的平台都是有幾百 MB 的 RAM，這兩年我們在很多案子裡都採用 JavaScript。其中發現很多情況，常燒光記憶體和程式不順暢的運作。其問題都不是 JavaScript 本身，而是 JavaScript 開發者的問題。

有不少前端或過去 web 用的很爽的東西或 Framework，在拿來 Embedded System 做一些不一樣的應用時，表現的相當糟。當然這一方面是因為不是這些元件原本的用途，但很多開發者就算重寫，依然是以過去的經驗來做，結果一樣糟。。。

其實仔細玩 Firefox OS，在許多地方的流暢度不順，也是有類似的問題。這不是 JavaScript 或瀏覽器本身的問題，而是開發者要改變自己的思維，所以我才説最後的問題會是在 Developer 的素質。

時間正在解決這些問題。比起 B2G 一開始，現在已經進步很多。很多部分都還沒調到最好，許多部分還在努力往 HW 加速前進。Web+JS 目前還沒達到他的極限，現在就斷言 developer 需要像 platform engineer 一樣懂那麼多細節，我覺的太早了。

"graphics programming has been always full of tricks. It will always be." -- Ariya Hidayat

如果現在一團糟，大部分不是 frontend 的錯，而是 platform engineer 的責任。硬要把這些責任叫 front end 吃下，我實在無法接受。

目前的系統通常分很多層次，基本上就有 app/framework/platform 等層次。大家各司其職，層層之間互相合作才能完成最後的任務。而不是打破層次，硬要寫上層人多注意下層如何運作。

其實，我指的不是系統層面的問題，而是許多 JavaScript 開發者尚未對 JavaScript 本身有確實的了解和掌握。很多人或許了解原理和機制，但卻不知何時該使用或避免。

我相信單純的 Graphical things -> HW 加速或是其他部份的加速都是很容易的，所以我也並不擔心這問題。我常看到的問題多半也都不是卡在這（因為我做的很多 Project 不是在做需要硬體加速的東西）。多半比較像早期 GTK+ 程式常常 UI Hangs 這類的狀況。我認為通常這種純語言或機制的問題， 身為 JavaScript 的開發者有必要了解和掌握。

PS. 我想表達的其實跟 UI、圖形運算沒關系，只是借來舉例而已。我的經驗和觀點，多半是從 Node.js on Embedded System 的 project 中所看到。

朱邦復年代用asm榨出硬體所有效能 vs. 反正硬體/平台夠快 code 再爛都沒差？