Addy Osmai

Addy Osmani နှင့် အင်တာဗျူး

Addy Osmani ဆိုတာကတော့ JavaScript လောကမှ မသိသူ မရှိတဲ့သူ ဖြစ်ပါတယ်။ လောလောဆယ်တော့ Google Chrome မှာ Engineering Manager အနေနဲ့ တာဝန် ထမ်းဆောင်နေပါတယ်။ သူ့အင်တာဗျုးက Developer တွေအတွက် စိတ်ဝင်စားစရာ ကောင်းတဲ့အတွက် ဘာသာပြန်ပြီး တင်ဆက်လိုက်ရပါတယ်။

Addy Osmani

JavaScript Community အတွင်းမှာ တကယ့်ကို အံ့ဩစရာ ကောင်းလောက်အောင် ထူးချွန်တဲ့ လူတစ်ယောက်ရှိတယ်ဗျ။ သူရေးသမျှ စာတွေ၊ စာအုပ်တွေ အကုန်လုံး လန်ထွက်နေသလို သူ ဝင်ပါနေတဲ့ open source contribution တွေကလဲ တကယ့်ကို အံ့မခန်းပဲဗျို့။ လူတွေက သူ့ကို ခင်စရာ ကောင်းတယ်တဲ့၊​ မာနမကြီးဘူးတဲ့။

သူ့ရဲ့ blog ကလဲ တကယ့်နောက်ဆုံးပေါ် Front-end ဆိုင်ရာ အသိပညာတွေ ဖြန့်ဝေနေတာ ဆိုတော့ မသွားမဖြစ်၊​ မကြည့်မဖြစ်၊​ မသိမဖြစ်ဆိုတဲ့ အထဲမှာပါနေပြန်တယ်ဗျ။ သူကတော့ Addy Osmani ဆိုတဲ့ သူပါ။ သူနဲ့ အခု မေးခွန်းအနည်းငယ် မေးထားပါတယ်။ ဘယ်လို အကြောင်း အပေါင်းသင့်လို့ JavaScript ထဲကို ခြေစုံပစ်ဝင်လာပြီး ခြေစုံနစ်နေတာလဲ။ Google နဲ့ သူနဲ့ ဘယ်အခြေအနေအထိ ဆက်စပ်ပတ်သက်နေသလဲ စသည်ဖြင့်ပေါ့ဗျာ။

မေးခွန်း – ခင်ဗျားကြည့်ရတာ JavaScript ကို ရေပြင်လိုကူးမယ့် စူဠလိပ်ပဲဗျ။ JS ကမ္ဘာထဲမှာ အင်မတန်ပျော်နေပုံပဲ။

ဖြေ – ကျွန်တော် JavaScript နဲ့ ပတ်သက်ပြီး ရေးဖြစ်တာ Netscape Navigator ခေတ်ကောင်းစဉ် ကတည်းကဗျ။ အဲဒီအချိန်က Dynamic front-end development အပိုင်းနဲ့ပတ်သက်ရင် တိုးတက်မှုက နှေးတယ်ဗျ။ ဒါပေမယ့် HTML/CSS/JS နဲ့ ရေးမယ်ဆိုရင် ဘယ်နေရာမှာမဆို အလုပ်လုပ်တယ်ဆိုတဲ့ အိုင်ဒီယာကတော့ အဲဒီကတည်းက အားကောင်းခဲ့တယ်လို့ ဆိုရမယ်။ အဲဒီ အားကောင်းတဲ့ အိုင်ဒီယာအပေါ်မှာ အဲဒီကတည်းက သံယောဇဉ်ကြီးခဲ့တယ်ဗျ။ အဲဒီတုန်းက ရေးခဲ့တဲ့ program လေးတွေကို ခင်ဗျားကို ပြရင် ရယ်စရာတွေ ဖြစ်နေမယ်ဗျ။ တကယ့်ကို ဘာမှမဟုတ်တဲ့ calculator လို password generator လို program လေးတွေဗျ။

ကျွန်တော်က programming language တွေကို လေ့လာရတာ ဝါသနာပါတယ်ဗျ။ JavaScript ကို prototype-based လဲဖြစ်တယ်၊ အဲဒီအပြင် weakly typed လဲဖြစ်တယ်ဆိုတော့ စိတ်ဝင်စားတယ်ဗျ။ ဒီတော့ တစ်ခြား C++ စတာတွေနဲ့ အတူတူလေ့လာဖြစ်တယ်။ လွန်ခဲ့တဲ့ ၂၀၀၀ ခုနှစ် အစောပိုင်းလောက်က language တစ်ခုနဲ့တစ်ခု ပေါင်းကူးအနေနဲ့ သုံးလို့ရအောင် SpiderMonkey(Mozilla’s JavaScript Engine) အပေါ်မှာ အခြေခံပြီး interpreter program ခပ်သေးသေးတစ်ခု ရေးဖူးတယ်။ ကျွန်တော် လုပ်ချင်တဲ့ ပုံစံက JS နဲ့ သုံးပြီး program ရေးမယ် UI တွေကိုတော့ C++ နဲ့ ဆောက်မယ်ပေါ့ဗျာ။ အဲဒီလို အိုင်ဒီယာမျိုးက ခပ်ကြောင်ကြောင် ဖြစ်ချင်ဖြစ်မယ်၊​ ကျွန်တော့်အနေနဲ့ကတော့ JavaScript Engine ရဲ့ အတွင်းပိုင်းအထိ လက်ကုန်နှိုက်မိသွားတဲ့ အနေအထားဗျ။ ကျွန်တော်အတွက် အတွေ့အကြုံတွေ အများကြီး ရလိုက်တယ်ဗျ။

အဲဒီနောက်တော့ ကျွန်တော် ဝါသနာပါရာ site လေးတွေ ဟိုလုပ် ဒီလုပ်ပေါ့ဗျာ။ ဒါပေမယ့် အထက်တန်း ကျောင်းသားဘဝ နောက်ဆုံးနှစ်မှာ browser တွေရဲ့ အတွင်းပိုင်းကို ခြေစုံပစ် ဝင်တော့မယ်လို့ ဆုံးဖြတ်ချက် ချလိုက်တယ်ဗျ။ နောက်တော့ ပေါ့ပေါ့ပါးပါး သုံးလို့ရမယ့် rendering engine တစ်ခုကို တည်ဆောက်ဖြစ်တယ်။ သူက HTML 4.01/CSS 2.1 တွေကို ရိုက်ထုတ်ပေးနိုင်တဲ့ parser ပုံစံမျိုးဗျ။ ကျွန်တော့်ရဲ့ ကိုယ်ပိုင် browser လေးထဲမှာ ထည့်ကြည့်တယ်။ အဲဒီ project က ကျွန်တော့်အတွက် တကယ့် အိပ်မက်ဆိုးပဲဗျို့။ စိတ်ချလက်ချ သုံးနိုင်တဲ့ အဆင့်ကိုရောက်ဖို့ အတော်ကြီးကို လုပ်ယူရတယ်။ အဓိကအကျဆုံး စိန်ခေါ်မှုက table အကြီးကြီးတွေကို render လုပ်တဲ့အခါ performance (စွမ်းဆောင်ရည်) ပိုင်း အကောင်းဆုံး ဖြစ်အောင် ထိန်းသိမ်းရတဲ့ အပိုင်းတွေ၊ video plugin တွေကို load လုပ်တဲ့ အပိုင်းတွေပဲဗျ။

ကောလိပ်ရောက်တော့ Freelance Web Developer အနေနဲ့ JavaScript ကို ဆက်လေ့လာ ဖြစ်တယ်။ site ရှုပ်ရှုပ်ထွေးထွေးတွေ သိပ်မရေးတော့ပဲ Dojo လို့ ခေါ်တဲ့ JavaScript Library ကိုပဲ အချိန်ပြည့် ကလိနေမိတယ်ဗျ။ ၂၀၀၆ ခုနှစ်လောက်မှာ GMail Invitation တစ်ခုရတယ်၊​ အဲဒီအချိန်ကစပြီး Browser ဆိုတာ နောက်ပိုင်းမှာ တကယ့် rich application4 တွေ တည်ဆောက်လို့ ရမယ့် နောက်ထပ်နေရာတစ်ခုပဲလို့ သိလာတယ်။ အဲဒီလို တည်ဆောက်တဲ့ နေရာမှာ JavaScript က အဓိကအကျဆုံး အခန်းကဏ္ဍကနေ ပါလာတော့မယ်လို့ သတိထားမိပြီး Desktop App Development5 ကို လုံးဝ (လုံးဝ) ကျောခိုင်းလိုက်တယ်။

အဲဒီအချိန်ကစပြီး ရှေ့ဆက်ဇောက်ချလေ့လာတယ်။ front-end community ကို ရှေ့ရွေ့လာအောင် တွန်းတဲ့အနေနဲ့ စာတွေရေးတယ်၊ open-source တွေမှာ ပါဝင်ကူညီ ဆောင်ရွက်ဖြစ်တယ်။ ခုချိန်မှာတော့ဗျာ JavaScript ဆိုတာ နေရာတကာမှာ မပါမဖြစ် အခြေအနေကို ရောက်နေပါပြီ။ အဲဒီလို နေရာတကာမှာ JavaScript ပဲဆိုတဲ့ အနေအထားကြောင့်လဲ JavaScript ကို ကျွန်တော် ချစ်မိနေတာဗျ။ ကျွန်တော်ဗျာ JavaScript အကြောင်းကို ကလေးတွေကို သင်ပေးမယ်ဆိုပါစို့၊​ ကျွန်တော့် browser က DevTools ကိုဖွင့် ဒီဟာက ဒီလိုကွ၊​ ဟိုဟာက ဟိုလိုကွဆိုပြီး ရှင်းပြလိုက်ရုံပဲ။ compilation လုပ်စရာမလဲ မလိုဘူး။ တစ်ခြား ဘာအဆင့်မှမလိုဘူး။ အဲဒီလို တိုက်ရိုက်သုံးလို့ ရနေတာကိုက ကျွန်တော့် အကြိုဆုံးထဲက JavaScript ရဲ့ အားသာချက် တစ်ခုပဲဗျ။

မေးခွန်း – ခင်ဗျား စာတွေ အများကြီး ရေးခဲ့တယ်နော်။ အဲဒီလို စာတွေအများကြီး ရေးတာနဲ့ ပတ်သက်ပြီး လူတွေက သိချင်နေမှာပဲဗျ။ အဲဒီလောက် စာတွေ အများကြီးရေးနိုင်တာ ပြီးတော့ လူတွေ နားလည်လွယ်အောင် ရေးနိုင်တာရဲ့ လှို့ဝှက်ချက်က ဘာလဲ။

အဲဒါကတော့ဗျာ ကျွန်တော့်ကို ကျွန်တော် ငတုံးတစ်ယောက်လို့ မှတ်လိုက်တယ်။ တကယ်ပြောတာဗျ။ ငတုံးတစ်ယောက် နားလည်အောင် ဘယ်လို အစိတ်စိတ်ပိုင်းမလဲ။ ငတုံးတစ်ယောက် အနေနဲ့ ဘယ်လို ရေးမှ အလွယ်ဆုံး နားလည်နိုင်မလဲ၊ အရိုးရှင်းဆုံးဖြစ်မလဲ စသည်ဖြင့် စဉ်းစားပြီး ရေးတယ်ဗျ။ အဲဒီလို အမြင်နဲ့ ချဉ်းကပ်တာ ကျွန်တော်အတွက် သက်သက်သာသာရှိတယ်။ ဘာပဲရေးရေး အရိုးရှင်းဆုံးရေး၊ သာမာန် developer တွေ နားလည်အောင် ရေး အဲဒီလို မူနဲ့ စာတွေရေးဖြစ်တယ်။ ဒါပေမယ့် ဘာစာပဲရေးရေး ကျွန်တော် သေသေချာချာ နားလည်အောင် အရင်လုပ်တယ်ဗျ။ ကိုယ်မှ ကောင်းကောင်း နားမလည်သေးပဲ သူများကို ရှင်းပြ၊​ ရေးပြတာ အလုပ်မဟုတ်ဘူးလို့ ကျွန်တော် ယူဆတယ်ဗျ။

အိုင်းစတိုင်းပြောခဲ့တဲ့ စကားတစ်ခွန်းရှိတယ်ဗျ။

“သင့်အနေနဲ့ သူများကို အရိုးရှင်းဆုံး နားလည်အလွယ်ဆုံး ပုံစံနဲ့ မရှင်းပြနိုင်သေးဘူးဆိုရင် အဲဒီ အကြောင်းကို သင်သေသေချာချာ မသိသေးဘူး”

အဲဒါ အမှန်ပဲဗျ။ framework တစ်ခုပဲဖြစ်ဖြစ်၊ tool တစ်ခုပဲဖြစ်ဖြစ်၊ အကောင်းဆုံး အလေ့အကျင့် တစ်ခုပဲဖြစ်ဖြစ် သေသေချာချာ မသုံးဖူးသေးပဲနဲ့ တစ်ခြားသူတွေကို မသင်နိုင်ဘူးဗျ၊ အဲဒီလိုပဲ ကိုယ်လိုချင်တဲ့ အစိတ်အပိုင်း တွေကိုလဲ မတောင်းဆိုနိုင်ဘူးဗျ။ အဲဒီလို ကိုယ်အရင်ဆုံး နားလည်အောင် လုပ်ရတဲ့အတွက် လိုအပ်တဲ့ အချိန်ကို ရှာရတာ ကျွန်တော် အင်ဂျင်နီယာဘဝတုန်းက အတော်ခက်တယ်ဗျ။ သိတဲ့အတိုင်းပဲ အချိန်ပြည့်နီးပါး အလုပ်တွေနဲ့ဆိုတော့။ စနေ၊​ တနင်္ဂနွေမှာ ကျွန်တော် ရေးမယ့် အကြောင်းအရာအတွက် ကြားရက် အလုပ်ချိန်တွေထဲက မနက်စာစားတဲ့အချိန်တွေ နေ့လည်စာ စားတဲ့ အချိန်တွေမှာ လေ့လာရတယ်။ နားလည်အောင် လုပ်ရတယ်ဗျ။ အခုတော့ ကိုယ်နားလည်အောင် အရင်လုပ်ရတဲ့အတွက် ယူရတဲ့ အချိန် အတော်ရလာပါပြီ။

ကိုယ်လုပ်နေတဲ့ အလုပ်တစ်ခုကို အဆုံးသတ်ဖို့ အဆုံးအထိ ပြည့်ပြည့်စုံစုံပြီးဖို့ အချိန်ယူရတာ အချိန်ဖဲ့ထုတ်ရတာ မလွယ်ဘူးဗျ။ အမြဲတမ်းစိန်ခေါ်နေတာ အချိန်ပဲဗျ။ လွန်ခဲ့တဲ့နှစ်တွေ ကတည်းက ဂါထာတစ်ပုဒ်လို ရွတ်နေတာ တစ်ခုရှိတယ်ဗျ။

“ပထမ လုပ်သာလုပ်လိုက်၊ ပြီးရင် မှန်အောင်လုပ်၊ မှန်အောင်လုပ်ပြီးရင်တော့ ဒီထက် ကောင်းအောင်လုပ်”

အဲဒီနည်းအတိုင်းပဲ ဘာအလုပ်ဖြစ်ဖြစ် ကျွန်တော် လုပ်ဖြစ်တယ်။ ခရီးတစ်ခုအတွက် ပထမဦးဆုံး ခြေလှမ်းဟာ အရေးအကြီးဆုံးဖြစ်တယ် ဆိုတဲ့ ပုံစံအတိုင်းပဲ အဲဒီလို စလိုက်မှသာ လုပ်လိုက်မှသာ တကယ့် စစ်မှန်တဲ့ ပန်းတိုင်တွေဆီကို အရောက်လှမ်းနိုင်မယ်ဗျ။ စာတွေရေးတယ်ဆိုရင်လဲ ပထမတော့ အကောင်းဆုံးဖြစ်ချင်မှ ဖြစ်မယ်။ code တွေ ရေးတဲ့အခါမှာလဲ​ အရမ်းပျံလန်နေတဲ့ code တွေဖြစ်ချင်မှဖြစ်မယ်။ ဒါပေမယ့် အခြေခံအကျဆုံး စမှတ်ကတော့ တစ်ခုခုကို စလုပ်လိုက်တာပဲ။

ပထမဦးဆုံးစလိုက်တဲ့ အလုပ်အပေါ်မှာ ကိုယ့်သူငယ်ချင်းတွေရဲ့ လုပ်ဖော်ကိုင်ဖက်တွေရဲ့ တုန့်ပြန်မှုအပေါ်မှာ မူတည်ပြီး ဘယ်လိုတော့ဖြင့် အကောင်းဆုံး ဖြစ်အောင် လုပ်မယ်၊ ဘာတွေ​ ထပ်ပြင်ဆင်မယ်၊ ဘာတွေ ထပ်ဖြည့်မယ် စသည်ဖြင့် အကြံကောင်း ဉာဏ်ကောင်းတွေ ရလာတယ်ဗျ။ အဲဒီလို ပြုပြင်ရင်း ပြင်ဆင်ရင်းနဲ့ပဲ လမ်းမှန်ပေါ်ကို ရောက်သွားတာပါပဲ။

မေးခွန်း – ခင်ဗျား အရင်က AOL မှာ အလုပ်လုပ်ခဲ့တယ်နော်။ အဲဒီ AOL မှာ လုပ်တန်းက အနေအထားနဲ့ အခု Google မှာ လုပ်တဲ့ အနေအထား ဘာတွေကွာလဲ၊ အဲဒီလို အလုပ်နှစ်ခုမှာ လုပ်ခဲ့တဲ့အတွက် ခင်ဗျားရဲ့ အမြင်တွေ၊ software development နဲ့ ပတ်သက်တဲ့ အမြင်တွေအပေါ် သက်ရောက်မှုတွေ ဘာတွေ ရှိလဲ။

ဖြေ – AOL ရော Google မှာ တကယ့်ကို တော်တဲ့ အင်ဂျင်နီယာတွေနဲ့ ဖွဲ့ထားတဲ့ အဖွဲ့တွေရှိတဲ့ ကုမ္ပဏီတွေပါပဲ။ ကျွန်တော်ရဲ့ မူအရတော့ ဘယ် Team ရယ်လို့ မဟုတ်ပါဘူး။ အားလုံးနဲ့ အဆင်ပြေပါတယ်။

Google ရဲ့ ပုံစံက ထုတ်ကုန်တစ်ခုခု ထုတ်တော့မယ်ဆိုရင် မှန်ကန်တဲ့ ရလဒ်ရနေတာတောင် ဒီထက် အကောင်းဆုံး ဘာတွေ ထပ်ဖြည့်မလဲ၊​ အကောင်းဆုံး ဘယ်လိုတည်ဆောက်မလဲ၊ အဆင့်အြမင့်ဆုံးဖြစ်အောင် ဘယ်လို တည်ဆောက်မလဲ စတဲ့အပိုင်းတွေကို စဉ်းစားကြရတယ်။ တည်ဆောက် ကြရပါတယ်။

AOL မှာတုန်းက ကျွန်တော်တို့ ပြီးမြောက်တဲ့ အဆင့်အထိ လုပ်ခဲ့တဲ့ product တွေ၊ application တွေနဲ့ ပတ်သက်ပြီး ကျွန်တော် အခုထိ ဂုဏ်ယူနေတုန်းပဲ။ ဒါပေမယ့် နည်းပညာဈေးကွက်က မြန်ဆန်လွန်းတာ၊ ပြိုင်ဆိုင်မှု ပြင်းထန်လွန်းတာ စတဲ့ အချက်တွေကြောင့် ကျွန်တော်တို့ ပြီးအောင် ရေးခဲ့တဲ့ ထုတ်ကုန်တွေ ထွက်မလာတာတွေ၊ အချိန်ကောင်း စောင့်နေရတာတွေ ရှိခဲ့တယ်ဗျ။ မတူညီတဲ့ အတွေ့အကြုံတွေ​ မတူညီတဲ့ အမြင်တွေကို ပေးစွမ်းနိုင်တာတော့ နှစ်ခုလုံး အတူတူပါပဲ။

မေးခွန်း – လူတွေအတော်များများ ပြောနေကြတာ ရှိတယ်ဗျ။ Google အနေနဲ့ WebKit ကို သုံးလိုက်တာ Dart ကို Chrome ထဲ ထည့်ချင်လို့တဲ့။ ခင်ဗျားရော Google ရဲ့ Dart အပေါ်​ ဘယ်လိုမြင်လဲ။ JavaScript ကို အစားထိုးမယ့် Google ရဲ့ စံတစ်ခုလား။

ဖြေ – ကျွန်တော် Google နဲ့ စပြီးလက်တွဲတော့ Dart နဲ့ ပတ်သက်တဲ့ ရည်ရွယ်ချက်တွေကို အရမ်းသိချင် သင်ချင်ခဲ့တယ်ဗျ။ လူပြောသူပြောတွေအရ JavaScript ကို အလဲထိုးအနိုင်ယူပြီး အစားထိုး သွားမယ်ပေါ့ဗျာ။ ဒါပေမယ့် ကျွန်တော့်အမြင်အရ အဲဒါလဲ သိပ်အမှန်ကြီး မဟုတ်သေးဘူး။ Dart က Java, C++, C# စတဲ့ Language တွေနဲ့ ရင်းနှီးတဲ့သူတွေကို ပစ်မှတ်ထားတယ်ဗျ။ အဲဒီ Language တွေသုံးပြီး high-performance web apps တွေ ရေးလိုသူတွေ အတွက်ပါ။ အဲဒီလို အနေအထားအတွက် Dart ဆိုတာ ထွက်ပေါ်လာရတယ်လို့ ပြောမယ်ဆိုရင် ပြောလို့ရတယ်ဗျ။

Google အနေနဲ့တော့ JavaScript ရော Dart ပါ တကယ့်ကို ရင်းနှီးမြှတ်နှံသင့်တဲ့ နည်းပညာတွေပဲလို့ ယုံကြည်ထားတယ်ဗျ။ TC39 မှာ ကျွန်တော်တို့ ပူးပေါင်းပါဝင်ပြီး JavaScript ရဲ့ အနာဂတ်အတွက် အလုပ်လုပ်သလို အမြန်ဆုံး JavaScript Engine ဖြစ်တဲ့ V8 ကိုလဲ ဆက်လုပ်ဖြစ်တယ်။ Chrome က အင်ဂျင်နီယာတွေအနေနဲ့ web ရဲ့ ရှေ့ဆက်ရမယ့် ခရီးအဖြစ် web components တွေ စတဲ့ နည်းပညာ အသစ်တွေကို တည်ဆောက်နေသလို တစ်ဖက်ကလဲ V8 ကို တည်ဆောက်ခဲ့တဲ့ အင်ဂျင်နီယာတွေ အနေနဲ့ Dart VM ကို တည်ဆောက်နေပါတယ်။

ခင်ဗျားရဲ့ မေးခွန်းကို ပြန်သွားရမယ်ဆိုရင် WebKit ကို သုံးလိုက်တာဟာ Dart ကို Chrome မှာ ပေါင်းလိုက်ဖို့ထက် multi-processing architecture တွေမှာ ဒီထက်ပိုပြီး ကောင်းအောင် တည်ဆောက်နိုင်ဖို့ဆိုတဲ့ ရည်ရွယ်ချက်က အများကြီး ပိုလိမ့်မယ်လို့ ကျွန်တော် ယုံကြည်ပါတယ်။ Dart ကတော့ open source project အနေနဲ့ သီးသန့် ရပ်တည်သွားမယ်။ သူ့မှာလဲ သူ့နဲ့ သက်ဆိုင်တဲ့ ရည်ရွယ်ချက်တွေ ရှိလိမ့်မယ်ဗျ။

မေး – Google အနေနဲ့ အခုအချိန်မှာ အင်မတန် စိတ်ဝင်စားဖို့ ကောင်းတဲ့ အနေအထားမှာ ရှိနေပါတယ်။ Google အနေနဲ့ native apps (Android) ဖက်မှာ အကြီးအကျယ် ရင်းနှီးမြှတ်နှံ နေသလို web experience ပိုင်းမှာလဲ အကြီးအကျယ် မြှတ်နှံနေပါတယ်။ Google နဲ့ ဆက်စပ် ပတ်သက်နေတဲ့ developer တစ်ယောက် အနေနဲ့ မတူညီတဲ့ ဝန်းကျင်နှစ်ခု အပေါ်မှာ ဘယ်လိုများ လုပ်ကိုင် ဆောင်ရွက်နေပါသလဲ။

ဖြေ – အဲဒီလို native vs web နဲ့ ပတ်သက်ပြီး ဆွေးနွေးငြင်းခုန်ကြတာ အခုခေတ်မှာ နေရာတကာလို ဖြစ်နေပါပြီ။ အဲဒီလို ငြင်းကြခုန်က လုပ်နေကြတဲ့သူတွေ အဓိက လွတ်နေတဲ့ အပိုင်းက user ဆိုတဲ့ အပိုင်းပဲ။ user ကို အဓိကထားပြီး စဉ်းစားရမယ်ဗျ။ သူတို့က အဓိက အကျဆုံး အာရုံစိုက်ရမယ့် နေရာပဲ။ desktop မှာပဲ ဖြစ်ဖြစ် mobile မှာပဲဖြစ်ဖြစ် web အနေနဲ့ တကယ့်ကို ကောင်းမွန်တဲ့ စွမ်းဆောင်ရည်တွေ ပေးစွမ်းနိုင်တယ်ဆိုတာ သာဓကတွေ အများကြီးပဲ ရှိတယ်ဗျ။ တကယ့်ကို စွမ်းဆောင်ရည် အကောင်းဆုံး ပေးစွမ်းနိုင်ကြတယ်ဗျ။ တစ်ချို့ကတော့ ပြောကြတယ်၊ web အတွက် platform မှာဖြစ်ဖြစ် browser မှာဖြစ်ဖြစ် ပြည့်စုံဖို့ အများကြီး လိုသေးတယ်တဲ့။ ဒါပေမယ့် အခုအချိန်မှာ native အတွက်ပဲဖြစ်ဖြစ် browser အတွက်ပဲဖြစ်ဖြစ် အကောင်ဆုံး platform တွေ တစ်ခုပြီးတစ်ခု ပေါ်လာနေပါတယ်။ ကောင်းသထက် ကောင်းလာနေပါတယ်။ Android ကနေ တစ်ဆင့်သုံးမလား၊ ဒါမှမဟုတ် Chrome Browser ကနေသုံးမလား ရွေးချယ်စရာတွေ ရှိလာနေပါတယ်။

မေး – အခုလက်ရှိ ရှိနေတဲ့ web technology တွေကို အသာထားဗျာ အနာဂါတ်မှာ developer တွေ အနေနဲ့ တွေးထားရမယ့် ဒီထက်အဆင့်မြင့်တဲ့ အပိုင်းက ဘာဖြစ်မလဲ။ web ရဲ့ အနာဂတ်က ဘာများဖြစ်မလဲ။

ဖြေ – Reusable components (ပြန်သုံးလို့ရတဲ့ အစိတ်အပိုင်းတွေ) ဗျ။ သမာရိုးကျ အားဖြင့် ကျွန်တော်တို့ application တွေကို တည်ဆောက်ရာမှာ application တစ်ခုခြင်းစီ သီးသန့်သက်ဆိုင်တဲ့ development method တွေနဲ့ တည်ဆောက်လေ့ရှိတယ်။ အဲဒီလို application-specific တည်ဆောက်လိုက်တဲ့အတွက် ထိန်းသိန်းရတာလဲ ခက်လာတယ်။ အဆင့်မြှင်တင်ဖို့လဲ ခက်လာတယ်ဗျ။ အဆိုးဆုံးကတော့ အဲဒီ application ကနေ လိုတဲ့အပိုင်းတွေ ဖြတ်ထုတ်ပြီး ပြန်သုံးမယ်ဆိုရင် မဖြစ်နိုင်တော့ဘူးဗျ။ ဖြစ်နိုင်တယ် ထားဦးတော့ လွယ်လွယ်နဲ့ မရတာ သေချာတယ်။ အဲဒီအပြင် ကိုယ့်ဆီက component တွေကို တစ်ခြားသူတွေနဲ့ ဝေမျှ သုံးစွဲဖို့ ခက်သွားတယ်ဗျ။

အခုအချိန်ကတော့ အဲဒီလို component တွေ တစ်ခုခြင်းစီ စိတ်ပိုင်းလိုက်ပြီး ကိုယ်လိုချင်တဲ့ application ကို ပေါင်းစပ် အကောင်အထည်ဖော်ဖို့ အချိန်အခါကောင်းပဲဗျ။ ပြန်သုံးလို့ရတဲ့ component တွေအဖြစ် ရေးလိုက်တာနဲ့ ပြုပြင်လို့ လွယ်သွာမယ်။ ပြောင်းလဲဖို့ လွယ်သွားမယ်။ အဆင့်မြှင်တင်လို့ လွယ်သွားမယ်။ ဝေမျှဖို့ လွယ်သွားပါလိမ့်မယ်။

Nettuts+ မှ Master Developers: Addy Osmani နှင့် အင်တာဗျူးကို ကောက်နှုတ်၍ သင့်တော်သလို ဘာသာပြန်ဆိုပါသည်။ 2013 May လက အင်တာဗျူး ဖြစ်ပါသည်။