[Blog] One Year War (part 1/3) : Typescript

เมื่อช่วงเวลานี้ของปีที่แล้ว ... อันเนื่องมาจาก Oracle ประกาศลอยแพ Java Plugins บน Browser ...  

เลยทำให้ได้มีโอกาส(เริ่ม)ทำ SPA แบบที่เป็น Modern Technology ที่มีอยู่ในท้องตลาดอย่าง AngularJS และ Typescript ที่เรียกได้ว่าช่วงนั้น ปังสุดๆ ก็ว่าได้ ...  

จนมาถึงวันนี้ ก็ถือว่าประสบการณ์ 1 ปีแล้วสำหรับ AngularJS และ Typescript .. 

เลยคิดว่าได้เวลามาเขียนรีวิว จริงๆ จังๆ ซะที ...

ด้วย Background การทำ web ที่มีอยู่แล้ว
อะไรที่ Simple ๆ จะขอข้ามไปเพราะคิดว่า search google 

ยังไงก็เจอ tutorial แบบ Copy and Paste ได้อยู่แล้ว

ทำไมถึง One Year War ?

การสู้รบปรบมือ เป็นเรื่องธรรมดามากหากเราหัดใช้ Tech ใหม่ๆ
มีทั้ง Surprise หลายๆ อย่างที่เจอระหว่าง Dev ไม่ว่าจะเป็น Typescript Transpiler หรือแม้แต่ AngularJS ที่ไม่คิดว่าจะมีปัญหาก็ต้องมาเจอกับปัญหา Performance ที่เกิดจากเขียนแบบ Noob Noob


Typescript ดียังไง ?

หากเคยเขียน Type Language มาก่อน อย่างเช่น JAVA หรือ C# หรือแม้แต่ PHP ...
การที่ตัวแปรมี Type นั้นทำให้เราจัดการกับ Data ที่เก็บอยู่ในตัวแปรนั้นๆ ได้อย่างสบายใจ
ซึ่งผิดกับ javascript ที่ไม่มี Type หรือแม้มี Type ก็มีพวก Object
หรือ Define Type ที่การใช้งานค่อนข้างจะลำบาก และ ไม่มี Hint Assist ใน IDE ทั่วๆ ไป

Typescript จึงมาช่วยในส่วนที่ขาดของ Javascript เหล่านั้น ดังเช่น
การทำ IIFE (immediately-invoked function expression) 
ถ้าเป็น Typescript เราสามารถเขียนได้ดังต่อไปนี้

namespace Hello {
  export function world() {
  }
}

เมื่อทำการ Transpile ผ่านพวก tsc ให้เป็น Javascript ปกติ ... เราจะได้ code แบบนี้

var Hello;
(function (Hello) {
    function world() {
    }
    Hello.world = world;
})(Hello || (Hello = {}));

ดูดีเลยทีเดียว ...
แต่ส่วนตัวที่คิดว่า Highlight ของ Typescript นั้น
น่าจะอยู่ที่ Feature ที่ทำให้เรา เลิกที่จะเขียน ....

var that = this;

โดยการใช้แบบนี้ แทน ....

 แล้ว Code ที่เราจะได้ คือ ....

จะเห็นว่า Typescript ทำการ Wrap inner function ด้วย IIFE ให้
ซึ่งทำให้เราลดการเขียน var that = this ไปได้หลายบรรทัดเลยหากเราเขียนเป็น Class ...

ไปลองเล่นตาม Play Ground ได้ที่นี่ - https://www.typescriptlang.org/play/index.html


ข้อเสีย Typescript ?

แน่นอนว่าภาษาที่ต้องใช้ Compiler/Translator มันมักจะไม่ค่อยคล่องตัวเท่าไหร่ ....
เนื่องมาจาก Typescript โดยพื้นฐานเป็นการทำ Javascript ให้มี "Type"
ดังนั้นหากเราต้องการใช้ Javascript Library จึงจำเป็นที่จะต้องมี "Type" เสียก่อน
โชคยังดีที่มี DefinitelyTyped ซึ่งเป็นที่รวม "Type" ของ Javascript Library
ที่มีคนอาสา Define "Type" มาให้ ซึ่งถ้าหาก Library ที่เราใช้ ไม่ Popular พอ ...
เราก็ต้องทำ Type ขึ้นมาเอง แต่จุดเริ่มต้นที่ดี คือไปลองหาใน repo นั้นก่อน หรือผ่านทาง Typings

และแม้ว่า tsc จะสามารถทำ sourcemap ที่เกิดจากการ transpile typescript ให้เป็น javascript
แต่ในบางครั้งการที่เราจะ debug typescript นั้นก็ไม่ง่ายเท่าไหร่นัก ....

สรุป

การใช้ Typescript ทำให้การเขียน code javascript เป็นเรื่องที่ง่ายขึ้น
แต่ก็แลกมากับ overhead ที่เกิดขึ้นไม่ว่าจะเป็นการ Transpile หรือแม้แต่ Debug ....
หากจะนำ Typescript ไปใช้ อาจจะต้องดูว่า ทีมที่ทำนั้นมีประสบการณ์ Javascript มามากน้อยแค่ไหน
ถ้ามาจากฝั่งพวก Java หรือ Type Language เพื่อมาเริ่ม project ใหม่
ที่เป็น javascript ก็เป็นนิมิตหมายที่ดีที่จะนำมาใช้ครับ

แต่ถ้า โปร javascript อยู่แล้ว  ... หรือเขียน module style แบบ NodeJS ....
ข้ามๆ มันไปเถอะ ถ้าไม่ได้จะใช้ AngularJS 2  lol

Backbone.js งานกระดูกๆ บน javascript

ช่วงนี้ได้มีเวลาลง effort เต็มที่กับ Web Application หลังจากตัว POC เสร็จไประดับนึงแล้ว
ความยากของงานคราวนี้ดูเหมือนจะเป็นการ port โปรแกรมจากเดิมที่เป็น Client - Server
ให้มาอยู่ในรูปของWeb Application ครับ

ต้องยอมรับว่าสมัยนี้ Web Application  หากไม่มี Ajax หรือ Javascript ที่เกี่ยวกับ Transition แล้ว
Web นั้นๆ จะดูธรรมดาลงไปเลยทันที ซึ่งทั้งนี้การเขียน code javascript แบบสะเปะสะปะ
อาจจะทำให้งานงอกภายหลังได้ เหมือนกับที่ปวดหัวกับ Legacy Code ในขณะนี้ ....

Backbone.js เป็น Library อีกตัวที่ช่วยวาง Framework ในการเขียน javascript ของเรา
ให้อยู่ในรูปแบบของ MVC Design Pattern ที่ช่วยให้เราสามารถ manage code ในแต่ละส่วน
แยกออกจากกันอย่างมีประสิทธิภาพแต่ใน Backbone.js นี้จะมีลักษณะแตกต่าง
กับ MVC Design Pattern ทั่วๆ ไปในภาษาอื่นตรงที่ Controller ใน Framework ตัวนี้
จะไม่มีให้เห็นชัดเจน หากแต่จะเป็น Component อื่นๆ ที่ช่วยในการ Controller อันได้แก่

Router - ไว้ทำการ navigate แบบ hashtag
Collection - ไว้จัดการข้อมูลที่เป็น List ของ Model
Sync - ไว้ Synchronize Data กลับไปยัง Server ยามที่เราจำเป็น

ส่วน  Model ก็ เก็บ Data  ,  View ก็เก็บ การแสดงผล
เนื่องด้วยการทำงานของ Backbone.js จะเป็น Event Driven ผสมกับ Model Driven ..
การติดต่อกับ Server จึงไม่จำเป็นที่จะต้องเขียน Ajax Query เองตรงๆ แต่สามารถเก็บ URL
ที่ใช้ในการ Access Data ไว้ในตัว Model เองได้เลย โดย Backbone.js นั้น จะ built-in  REST Service
มาให้อยู่แล้ว ทำให้เราสามารถเรียกใช้ REST ให้ตรงกับความต้องการของ Backbone ได้โดยตรง ....
เช่น

Application = Backbone.Model.extend({
             url: '/auth/status'
});
var myApp = new Application();

เวลาเราต้องการดึงข้อมูล เราสามารถเขียนได้ในลักษณะนี้

myApp.fetch();

Backbone.js จะทำการไป query ตาม URL ที่เรากำหนดไว้ใน model ให้ทันที

ซึ่งจะควบคุมโดย REST service ตามการทำงานแบบ CRUD.

การใช้งานส่วนใหญ่ก็มีเวปฝรั่งเยอะพอสมควรแล้ว ขอไม่เขียนละกันครับ :)
ตัวอย่างแบบละเอียด สามารถดูได้จาก

Todos

http://documentcloud.github.com/backbone/examples/todos/index.html

โดยมี sourcecode annotation อธิบายทีละบรรทัดว่าทำอะไรเพื่ออะไรอย่างไรบ้างโดยดูจาก

http://documentcloud.github.com/backbone/docs/todos.html


ขอบ่นจากประสบการณ์ที่ใช้โดยตรงเลยดีกว่า

ข้อดี :

• Sample App ใช้ Learning Curve ต่ำ 
• Backbone.js มีขนาดค่อนข้างเล็ก เมื่อเทียบกับ Framework อื่น
  ( โดยรวม JQuery กับ UnderScore )
• template engine ( underscore ) ค่อนข้างเก่ง และ เข้าใจง่าย
• code ไม่เละ สามารถแยก object และ class ได้อย่างชัดเจน
• Delegate events จาก DOM มาจัดการใน View ได้โดยตรง
• เหมาะสำหรับทำ Application แบบ Stateless ( Asynchronous )

ข้อเสีย

• Document น้อย 
• ด้วย Pattern ที่เป็น MVC อาจทำให้เกิด over-design ได้ ต้องระวัง
• หากทำ SPA ต้องคำนึงถึง Performance
• อาจจะไม่เหมาะสำหรับบาง Web Application Framework ที่ไม่สามารถแก้ HTTP Header ได้

โดยรวมแล้ว อาจจะค่อนข้างเป็น Trend ใหม่สำหรับการทำ Webapp แบบ Single Page Application
แต่ในยุคสมัยนี้ Browser ค่อนข้างเก่งกว่าเมื่อก่อนมาก ในบางครั้งการทำ Application ที่ต้องติดต่อกับ Server ภายนอกโดยครอบคลุมทุก Platform นั้น จึงเหมาะสมที่จะใช้เป็น Web Application มากกว่าการเสียเวลามานั่งเขียน Native App โดยไม่จำเป็น เพราะหากเรามี Protocol ที่ดีอยู่แล้ว ไม่ว่า Web Application หรือ Native Application ก็ไม่ใช่เรื่องใหญ่อีกต่อไป