user
Bun ကြောင့် Node ကြီး ပလုံတော့မှာလား။


assistant
Bun က benefit တွေ အများကြီး ယူလာခဲ့ပေမယ့် Node လို ဆယ်စုနှစ်တခုကျော်အောင် ရပ်တည်လာတဲ့ runtime ကို ကောက်လဲပလိုက်ဖို့ဆိုတာ အခုချိန်မှာတော့ အလျော်အစား ကြီးလွန်းနေသေးတယ်။
Node မတိုင်ခင်ကလည်း JS runtime တွေရှိခဲ့တာပဲ။ GCP ရဲ့ AppEngine တို့ နောက် silk တို့ထွက်ခဲ့တယ်။ ဒါပေမယ့် JavaScript ရဲ့ single thread model ကြောင့် JS web program တွေရဲ့ လုပ်နိုင်စွမ်းက အထင်ကြီးစရာ မရှိခဲ့ဘူး။ နောက်တော့ Node.js ရောက်လာပြီး Google ရဲ့ V8 Engine နဲ့ Event loop Architecture ကိုသုံးပြီး JavaScript Backend တခေတ်စခဲ့တယ်။
Node.js ရဲ့ သဘောက CPU bound task ကလွဲရင် I/O job တွေကို မ​စောင့်ပဲ callback တွေနဲ့ ပြန်လာစေမယ်။ ငွေရှင်းကောင်တာမှာ ငွေရှင်းဖို့ ရှေ့လူမှာတဲ့ စားစရာ ရတဲ့အထိ နောက်လူတွေက စောင့်စရာ မလိုတဲ့ ပုံစံပေါ့။
Http Server တခါတည်းပါပြီး NPM လို package management နဲ့ ပေါင်းလိုက်တဲ့အခါ Node.js က ခဏလေးနဲ့ ထိုးတက်လာတယ်။ Node API တွေကို အခြေခံပြီး Express တို့လို web serving component ကို ချောမွတ်စေတဲ့ library တွေ ထပ်ထွက်လာတယ်။ frontend မှာ Next တို့ Nuxt တို့လို SSR framework တွေ ထွက်ခဲ့တာမှာလည်း Node ကအခရာကျခဲ့တယ်။ Node Ecosystem က အချိန်တိုအတွင်း ခပ်မြန်မြန်ပဲ ကြီးလာတယ်။
အပြောင်းအလဲကြီးတခုက ECMAScript ပဲ။ ES6 မှာ prototype နဲ့ constructor helper pattern ကိုရှောင်ဖို့ class ကိုထည့်လာတာ၊ callback တွေကိုလျှော့ချပြီး ပိုချောမွတ်တဲ့ asynchronous code တွေရေးနိုင်ဖို့ ပြင်ဆင်လာတာနဲ့ module system အသစ်စတဲ့ အပြောင်းအလဲတွေကို မြင်ရခဲ့ရတယ်။
ဒီထဲမှာ Node Ecosystem ကို တိုင်ပတ်သွားစေတဲ့တချက်က CommonJS နဲ့ ES6 module အကြား compatability ဖြစ်လိမ့်မယ်။ Webpack, Vite စတဲ့ bundler, transpiler တွေနဲ့ တအိအိ ရှေ့ဆက်ခဲ့ကြပေမယ့် typescript ရောက်လာတဲ့အခါမှာတော့ uniformity မရှိတဲ့ ပြဿနာက ပိုကြီးလာတယ်။ ပိုဆိုးတာက Node.js ထွက်တုန်းက Typescript မရှိသေးလို့ Node မှာ Typescript native support မပါဘူး။
Bun က ဒီပြဿနာတွေကို ဖြေရှင်းဖို့ ရည်ရွယ်လာတယ်။ builtin typescript support ပါလာမယ်။ ပိုချောမွတ်တဲ့ module နဲ့ package management နောက် အဟော့ဆုံးက performance ပေါ့။ Node တို့ Deno တို့ထက် ဘယ်နှဆ မြန်တယ်ဆိုတာမျိုး။ တကယ်လည်း မြန်တယ်။ Bun Team ကတော့ Zig နဲ့ JSC (JavaScript Core) Engine ကြောင့်လို့ အသားပေး ပြောထားပေမယ့် ရာနှုန်းပြည့် မမှန်ဘူး။
Bun ရှေ့မှာ Deno ဆိုတာ ထွက်ခဲ့သေးတယ်။ Node ကိုဖန်တီးခဲ့တဲ့သူပဲ ဦးဆောင်ခဲ့တာ။ Deno မှာ Rust နဲ့ V8 Engine ကိုသုံးထားတယ်။ Rust နဲ့ Zig နှစ်ခုက အခုလောက် performance ကွာစရာ မရှိဘူး။ ဒါပေမယ့် သုံးထားတဲ့ JS Engine ချင်းယှဥ်ရင် V8 က JSC ထက် အတော်လေး အထနှေးတယ်။ အထနှေးလို့ V8 က JSC လောက် မကောင်းဘူးတော့ မဟုတ်ဘူးပေါ့။
Browser လို client program နဲ့ server program ရဲ့ fault tolerance နဲ့က သိပ်ကွာတယ်။ V8 Engine က သူ့ရဲ့ stability ကို Node.js နဲ့အတူ ဆယ်စုနှစ်တခုကျော် ရှေ့မှာ သက်သေပြထားပြီးသား။ ဒါကြောင့် အခုချိန်မှာ stability နဲ့ speed ကိုယှဥ်ရွေးဖို့ဆိုတာ အလျော်အစား ကြီးလွန်းနေသေးတယ်ပြောတာ။
JavaScript Engine တွေအကြောင်းပြောရင် JSC, V8 တို့အပြင် နောက်ထပ် အများကြီး ရှိသေးတယ်။ Facebook က ထုတ်ထားတဲ့ Hermes ဆိုရင် JSC ကိုပါ ရာနှုန်းပြည့် နောက်ကောက်ချလို့ရတယ်။ ပိုလည်းပေါ့ပါးတယ်။ React Native ရဲ့ကျောရိုး js engine ပေါ့။ ဒါပေမယ့် သူ့မှာ JIT compilation လို feature တွေတော့ ပါမှာမဟူတ်ဘူး။ ဒါကြောင့် JS engine ထက်စာရင် တကယ်တမ်း Bun နဲ့ Deno မှာစကားပြောသွားတာက runtime ရဲ့ architecture ပဲ။
လက်ရှိနဲ့ နောက်နှစ်တွေကိုကြည့်ရင်တော့ Node က ကျသွားဖို့ မဖြစ်နိုင်သေးဘူး။ ဒါပေမယ့် အနှေးနဲ့အမြန် Node ကို အစားထိုးသွားကြမှာလည်း ငြင်းမရဘူး။ အဲဒါက Bun ဖြစ်ရင်လည်းဖြစ်မယ်။ Deno ဖြစ်ချင်လည်းဖြစ်မယ်။ တခြားတခုခုလည်း ဖြစ်ရင်ဖြစ်မှာပဲ။
ခုတောင် ECMAScript က type annotation ထည့်ဖို့ ပြင်နေတယ် ပြောတယ်။ annotation ကြောင့် IDE type hint တွေပိုကောင်းလာမယ်။ နောက် static type checker တွေ ရေးရ လွယ်လာမယ်။ Frontend ဖက်မှာ Typescript မြင်ရတာ ပိုနည်းသွားနိုင်တယ်။ ဒါပေမယ့် ချုံကြည့်ရင် built in type check ပါလာတာ မဟုတ်တဲ့အတွက် typescript ကိုလည်း ဆက်သုံးနေဦးမှာပဲ။
ဒီတော့ Node.js လား Bun လားဆိုရင် စောင့်ကြည့်ဦးကြတာပေါ့။ အခုတော့ Bun လိုက်ဖို့ စောလွန်းပါသေးတယ်။

CodeHub by Harry Yan, Sep 2023