GWT Toolkit: สร้าง JavaScript Front End อันทรงพลังโดยใช้ Java

GWT Web Toolkit เดิมชื่อ Google Web Toolkit เป็นชุดเครื่องมือการพัฒนาสำหรับการสร้างและเพิ่มประสิทธิภาพแอปพลิเคชันบนเบราว์เซอร์ที่ซับซ้อนโดยใช้ภาษาการเขียนโปรแกรม Java

สิ่งที่ทำให้ GWT ไม่ใช่ “เครื่องมือ Java อีกตัวในการเขียนเว็บแอป” คือความจริงที่ว่าหัวใจของชุดเครื่องมือคือคอมไพเลอร์ที่แปลง Java เป็น JavaScript (เช่นเดียวกับ HTML และ CSS) ทำให้นักพัฒนาสามารถเขียนเว็บแอปพลิเคชันส่วนหน้า ในขณะที่ใช้ประโยชน์จากจุดแข็งทั้งหมดของ Java

การใช้งาน Java และ JavaScript ผสมผสานกันเป็นเรื่องง่าย เนื่องจาก GWT มีสถาปัตยกรรมการทำงานร่วมกันที่มีประสิทธิภาพสำหรับการเชื่อมต่อกับแพลตฟอร์มเว็บ เช่นเดียวกับ Java Native Interface (JNI) ที่อนุญาตให้ Java Virtual Machine (JVM) เรียกใช้รูทีนเฉพาะแพลตฟอร์ม (เช่น เพื่อเข้าถึงคุณลักษณะฮาร์ดแวร์เฉพาะ หรือใช้ไลบรารีภายนอกจากภาษาอื่น) GWT ช่วยให้เราเขียน แอปพลิเคชันใน Java จากนั้นหากจำเป็นเพื่อใช้ Web API เฉพาะ หรือใช้ประโยชน์จากไลบรารี JavaScript ที่มีอยู่ ให้ "ใช้งานแบบเนทีฟ" และข้ามไปยัง JavaScript

GWT ถือกำเนิดขึ้นในฐานะผลิตภัณฑ์ของ Google แต่จบการศึกษาเป็นโอเพ่นซอร์สในปลายปี 2554 และปัจจุบันเผยแพร่ภายใต้ Apache License (เวอร์ชัน 2) ภายใต้ชื่อ GWT Open Source Project มีการจัดการโดยคณะกรรมการกำกับที่มีตัวแทนจากหลายบริษัท รวมทั้ง Google, RedHat, ArcBees, Vaadin และ Sencha ตลอดจนนักพัฒนาอิสระจากชุมชน

GWT ในอดีตและในอนาคต

Google Web Toolkit เปิดตัวครั้งแรกในปี 2549 สร้างขึ้นเพื่อเป็นเครื่องมือที่จะช่วยให้วิศวกรของ Google พัฒนาแอปพลิเคชันบนเบราว์เซอร์ที่ซับซ้อน เช่น AdWords, Google Wallet และ Google Flights และล่าสุดได้ถูกใช้เป็นหัวใจของ แอปพลิเคชัน Google ชีตและกล่องจดหมาย

ย้อนกลับไปในปี 2549 เบราว์เซอร์ (และตัวแปล JavaScript) นั้นยังห่างไกลจากมาตรฐาน รหัสส่วนหน้าช้า บั๊กกี้ และใช้งานยากอย่างน่าเชื่อถือ มีการขาดไลบรารีและเฟรมเวิร์กคุณภาพสูงเกือบทั้งหมดสำหรับการพัฒนาเว็บ ตัวอย่างเช่น jQuery ไม่มีอยู่จนกระทั่งปีนี้ ดังนั้น เพื่อให้สามารถพัฒนาเว็บแอปพลิเคชันขนาดใหญ่ได้ วิศวกรของ Google จึงตัดสินใจใช้เครื่องมือและความสามารถที่มีอยู่ Java เป็นภาษาที่เหมาะสมที่สุดสำหรับความต้องการของพวกเขา เป็นที่รู้จักกันดีและรวมเข้ากับ IDE ได้อย่างสมบูรณ์แบบ เช่น Eclipse ดังนั้น Google Web Toolkit จึงเริ่มต้นชีวิต

เป้าหมายคือการซ่อนความแตกต่างระหว่างเบราว์เซอร์และสรุปเทคนิคที่จำเป็นในการเขียน JavaScript ที่มีประสิทธิภาพภายในคอมไพเลอร์ Java ทำให้นักพัฒนาซอฟต์แวร์ปราศจากการกดขี่ของเทคนิคของเบราว์เซอร์

แน่นอนว่าในช่วงทศวรรษที่ผ่านมา เว็บได้เปลี่ยนแปลงไป เบราว์เซอร์ทำงานเร็วขึ้นและผสานเข้ากับมาตรฐานการใช้งาน และเฟรมเวิร์กและไลบรารีส่วนหน้าที่ยอดเยี่ยมจำนวนมากได้รับการพัฒนาขึ้น รวมถึง jQuery, Angular, Polymer และ React ดังนั้นคำถามแรกที่คุณอาจถามโดยธรรมชาติคือ "GWT ยังมีประโยชน์อยู่หรือไม่"

ในคำ: ใช่

ในบริบทของการพัฒนาเว็บสมัยใหม่ การกำหนดเป้าหมายเบราว์เซอร์เป็นสิ่งที่หลีกเลี่ยงไม่ได้ และ JavaScript ได้กลายเป็น ภาษากลาง ของแอปพลิเคชันส่วนหน้า แต่แน่นอนว่าเครื่องมือและภาษาต่างๆ จะเหมาะกับงานที่แตกต่างกันมากกว่า GWT พร้อมด้วยโปรเจ็กต์ที่คล้ายกันจำนวนหนึ่งมีเป้าหมายเพื่อกำหนดเป้าหมายเบราว์เซอร์โดยไม่จำกัดให้นักพัฒนาใช้ JavaScript

การพัฒนาและการใช้งานเครื่องมือ "คอมไพล์ไปยังเว็บ" เช่น GWT จะได้รับการอำนวยความสะดวกโดยกลุ่ม WebAssembly ของ World Wide Web Consortium ในอนาคตอันใกล้นี้ ไม่ได้มีเพียงพื้นที่กว้างใหญ่สำหรับเครื่องมือที่คอมไพล์เป็น JavaScript แต่แนวทางนี้อาจเติมเต็มความต้องการที่แท้จริงในบริบทที่มีตั้งแต่การลดการประมวลผลส่วนหนึ่งของการคำนวณไปจนถึงเบราว์เซอร์ การนำโค้ดและไลบรารีที่มีอยู่มาใช้ซ้ำ การแชร์โค้ดระหว่างแบ็คเอนด์และฟรอนต์เอนด์ โดยใช้ความสามารถและเวิร์กโฟลว์ที่มีอยู่และการใช้ประโยชน์จากคุณลักษณะของภาษาต่างๆ (เช่น การพิมพ์แบบคงที่ในกรณีของ GWT)

โครงการ GWT คาดว่าจะออกเวอร์ชัน 2.8 ในเร็วๆ นี้ และเวอร์ชัน 3.0 กำลังอยู่ในระหว่างการพัฒนา โดยมีการปรับปรุงอย่างมากในการทำงาน:

• ปรับปรุงการทำงานร่วมกันด้วย JavaScript
• ปรับปรุง (เขียนใหม่เกือบทั้งหมด) คอมไพเลอร์
• รองรับ Java ที่ทันสมัย ​​(เช่น lambdas)

อันที่จริง ฟีเจอร์ส่วนใหญ่ของ GWT 3.0 มีอยู่แล้วในที่เก็บ Git สาธารณะ เพียงตรวจสอบลำต้น ที่นี่ และรวบรวม GWT ตามเอกสาร ที่นี่

ชุมชน GWT

ตั้งแต่ GWT เป็นโอเพ่นซอร์สในปี 2554 ชุมชนได้ถือว่ามีบทบาทสำคัญในวิวัฒนาการของโครงการ

การพัฒนาทั้งหมดเกิดขึ้นบนที่เก็บ Git ที่โฮสต์บน gwt.googlesource.com และการตรวจสอบโค้ดทั้งหมดจะทำบน gwt-review.googlesource.com ในหน้าเหล่านี้ ผู้ที่สนใจในการพัฒนา Toolkit สามารถมีส่วนร่วมและดูว่าชุมชนกำลังทำอะไรอยู่ ในช่วงสองสามปีที่ผ่านมา เปอร์เซ็นต์ของแพตช์ใหม่จากผู้ที่ไม่ใช่ Googler ได้เพิ่มขึ้นจากประมาณ 5 เปอร์เซ็นต์ในปี 2012 เป็นประมาณ 25 เปอร์เซ็นต์ในปีที่แล้ว ซึ่งยืนยันถึงการมีส่วนร่วมที่เพิ่มขึ้น

ในปีนี้ ชุมชนได้รวมตัวกันเพื่อการประชุมใหญ่สองสามครั้งในสหรัฐอเมริกาและยุโรป GWT.create ซึ่งจัดโดย Vaadin จัดขึ้นทั้งในมิวนิก เยอรมนี และ Mountain View รัฐแคลิฟอร์เนียในเดือนมกราคม และมีผู้เข้าร่วมกว่า 600 คนจากหลายสิบประเทศ วันที่ 11 พฤศจิกายน ในเมืองฟลอเรนซ์ ประเทศอิตาลี เราจะจัด GWTcon รุ่นที่สอง ซึ่งเป็นการประชุม GWT ที่ขับเคลื่อนโดยชุมชน ซึ่งฉันกำลังช่วยจัดระเบียบ

GWT เหมาะกับอะไร?

แบบสำรวจประจำปีเกี่ยวกับชุดเครื่องมือ GWT ที่เผยแพร่โดย Vaadin กล่าวถึงวิวัฒนาการการพัฒนาของ GWT ความรู้สึกของนักพัฒนาซอฟต์แวร์ที่มีต่อชุดเครื่องมือ ข้อดี ข้อเสีย และอื่นๆ แบบสำรวจนี้ยังช่วยให้เราเข้าใจว่าชุดเครื่องมือนี้ใช้ทำอะไร ชุมชนผู้ใช้เปลี่ยนแปลงไปอย่างไร และความคาดหวังที่นักพัฒนามีต่อชุดเครื่องมือในอนาคต

สามารถดู รายงานอนาคตของ GWT สำหรับปี 2015 ได้ที่นี่ และทำให้เห็นชัดเจนว่า GWT เป็นที่นิยมอย่างมากสำหรับการสร้างเว็บแอปพลิเคชันขนาดใหญ่ ตัวอย่างเช่น ในหน้า 14 กล่าวว่า "แอปพลิเคชันส่วนใหญ่เป็นแอปพลิเคชันทางธุรกิจที่มีข้อมูลจำนวนมากและใช้งานได้หลายชั่วโมงต่อวัน"

ตามที่คาดไว้ เป็นเรื่องง่ายที่จะสรุปว่าสภาพแวดล้อมทางธรรมชาติสำหรับ GWT เป็นสาขาของเว็บแอปพลิเคชันขนาดใหญ่ ซึ่งความสามารถในการบำรุงรักษาโค้ดเป็นสิ่งสำคัญ และทีมขนาดใหญ่จะได้รับประโยชน์จากโครงสร้างของภาษา Java

ในทางกลับกัน การดูเกณฑ์มาตรฐานสำหรับโค้ดที่สร้างโดย GWT (เช่น ในประเด็นสำคัญของการประชุม GWT.create ปีที่แล้ว ในหน้า 7, 8 และ 11) จะเห็นว่าในแง่ของประสิทธิภาพและ ขนาดโค้ด JavaScript ที่คอมไพล์แล้วนั้นยอดเยี่ยมมาก หากใช้อย่างถูกต้อง ประสิทธิภาพที่ได้รับจะเทียบได้กับ JavaScript ที่เขียนด้วยมือที่ดีที่สุด ด้วยเหตุนี้ จึงเป็นไปได้จริงที่จะใช้ GWT เพื่อพอร์ตไลบรารี Java ไปยังเว็บ

สิ่งนี้ทำให้เห็นสถานการณ์ในอุดมคติอื่นสำหรับ GWT ระบบนิเวศของ Java เต็มไปด้วยไลบรารีคุณภาพสูงที่ไม่มีคู่ที่พร้อมใช้งานใน JavaScript คอมไพเลอร์ GWT สามารถใช้เพื่อปรับไลบรารีดังกล่าวสำหรับเว็บ กล่าวอีกนัยหนึ่ง GWT ช่วยให้เราผสมผสานไลบรารีที่มีอยู่ในทั้ง Java และ JavaScript และเรียกใช้ในเบราว์เซอร์

แนวทางนี้สามารถเห็นได้ในการพัฒนา PicShare ซึ่งเราแสดงให้เห็นว่าไลบรารี Java หลายไลบรารีที่ไม่ได้พิจารณาโดยทั่วไปสำหรับเว็บ (เช่น NyARToolkit เป็นต้น) สามารถย้ายไปยังเบราว์เซอร์โดยใช้ GWT ได้อย่างไร และรวมกับเว็บ API รวมถึง WebRTC และ WebGL เพื่อ รับเครื่องมือ Augmented Reality บนเว็บโดยสมบูรณ์ ฉันภูมิใจนำเสนอ PicShare ในการประชุม 2015 GWT.create เมื่อเดือนมกราคมที่ผ่านมา

ภายใต้ประทุน: เปลี่ยน Java เป็น JavaScript

GWT Toolkit เป็นชุดเครื่องมือที่ซับซ้อนปานกลาง แต่ทุกคนสามารถเริ่มใช้งานได้ในเวลาอันสั้น ต้องขอบคุณการผสานรวมกับ Eclipse ที่ใช้งานง่ายอย่างน่าประหลาดใจ

การสร้างแอปพลิเคชันอย่างง่ายด้วย GWT นั้นค่อนข้างง่ายสำหรับทุกคนที่มีพื้นหลังในโครงการพัฒนา Java แต่เพื่อให้เข้าใจถึงสิ่งที่ “เกิดขึ้นจริง” นั้น ควรพิจารณาองค์ประกอบหลักของชุดเครื่องมือนี้อย่างเหมาะสม:

• Java เป็น JavaScript Transpiler
• สภาพแวดล้อมรันไทม์ Java จำลอง
• เลเยอร์การทำงานร่วมกัน

คอมไพเลอร์เพิ่มประสิทธิภาพของ GWT

คำอธิบายเชิงลึกเกี่ยวกับวิธีการทำงานของคอมไพเลอร์นั้นกลายเป็นเรื่องทางเทคนิคได้ค่อนข้างเร็ว และเราไม่จำเป็นต้องเจาะลึกถึงขนาดนั้น แต่แนวคิดทั่วไปบางส่วนก็คุ้มค่าที่จะดู

สิ่งแรกที่ต้องเข้าใจคือ GWT คอมไพล์ Java เป็น JavaScript โดยการแปลที่ระดับซอร์สโค้ด นั่นคือแหล่งที่มาของ Java ถูกแปล ( transpiled เป็นศัพท์เทคนิค) เป็น JavaScript ซึ่งตรงกันข้ามกับ Java Virtual Machine บางประเภทที่เขียนด้วย JavaScript ซึ่งรัน Java bytecode (นี่เป็นไปได้จริง ๆ และเป็นแนวทางที่ Doppio ใช้ แต่ไม่ใช่วิธีการทำงานของ GWT)

โค้ด Java จะถูกแยกย่อยออกเป็นแผนผังโครงสร้างนามธรรม (AST) แทนองค์ประกอบทางวากยสัมพันธ์ของโค้ด จากนั้นจะจับคู่กับ Javascript AST ที่เทียบเท่า (และปรับให้เหมาะสม) ซึ่งสุดท้ายแล้วจะถูกแปลงกลับเป็นโค้ด JavaScript จริง

การชั่งน้ำหนักข้อดีและข้อเสียของการ transpilation อยู่ไกลจากวัตถุประสงค์ของโพสต์นี้ แต่ให้ฉันสังเกตว่าด้วยวิธีนี้ GWT สามารถใช้ประโยชน์จากบริการรวบรวมขยะของล่าม JavaScript ได้โดยตรง พร้อมกับคุณสมบัติอื่น ๆ ที่มาจากเบราว์เซอร์

มีบางส่วนที่ยุ่งยากแน่นอน ตัวอย่างเช่น JavaScript มีประเภทตัวเลขเพียงประเภทเดียวเท่านั้น ซึ่งไม่สามารถมีประเภทจำนวนเต็มแบบ long 64 บิตของ Java ดังนั้นประเภทที่ long จึงจำเป็นต้องได้รับการดูแลเป็นพิเศษจากคอมไพเลอร์ นอกจากนี้ การพิมพ์สแตติกของ Java ไม่ได้มีความหมายโดยตรงใน JavaScript ดังนั้นจึงต้องระมัดระวังเป็นพิเศษเพื่อคงไว้ซึ่งการดำเนินการพิมพ์ดีดเทียบเท่าหลังจากการทรานสพิเลชั่น

ในอีกทางหนึ่ง ข้อได้เปรียบที่เข้าใจได้ง่ายของการทรานสพิเลชั่นคือ GWT สามารถทำการปรับให้เหมาะสม (สำหรับทั้งขนาดและประสิทธิภาพ) ที่ระดับ Java และ ที่ระดับ JavaScript โค้ด JavaScript มาตรฐานที่เป็นผลลัพธ์สามารถประมวลผลเพิ่มเติมในไปป์ไลน์การปรับใช้ของคุณ ตัวอย่างเช่น แนวปฏิบัติทั่วไปที่ตอนนี้ถูกรวมเข้ากับการกระจาย GWT มาตรฐานนั้นเกี่ยวข้องกับการเพิ่มประสิทธิภาพเอาต์พุต JavaScript โดยทรานสปิลเลอร์โดยใช้ JavaScript-to-JavaScript Closure Compiler ที่เชี่ยวชาญเป็นพิเศษ (ของขวัญอีกชิ้นจากเทพเจ้า Google)

คำอธิบายเชิงลึกที่สุดของคอมไพเลอร์ GWT ที่ฉันรู้จักมีอยู่ในสไลด์นี้และคำบรรยายต้นฉบับที่มาจาก ที่นี่ คุณจะพบรายละเอียดเกี่ยวกับคุณสมบัติเจ๋งๆ อื่นๆ ของกระบวนการคอมไพล์ เช่น ความสามารถของ GWT ในการแยกโค้ด การสร้างไฟล์สคริปต์แยกกันหลายไฟล์เพื่อโหลดโดยอิสระจากเบราว์เซอร์

JRE จำลอง

คอมไพเลอร์ Java-to-JavaScript จะเป็นมากกว่าความแปลกใหม่เล็กน้อย หากไม่เสริมด้วยการใช้งาน Java Runtime Environment (JRE) ซึ่งจัดเตรียมไลบรารีหลักที่แอปพลิเคชัน Java เกือบทั้งหมดใช้อ้างอิง พูดโดยคร่าว การทำงานใน Java โดยไม่ใช้เมธอด Collections หรือ String จะเป็นเรื่องที่น่าหงุดหงิด และแน่นอนว่าการพอร์ตไลบรารี่เหล่านี้เป็นงานไททานิค GWT เติมหลุมนี้ด้วย Emulated JRE ที่เรียกว่า

Emulated JRE ไม่ได้หมายถึงการนำ Java JRE กลับมาใช้ใหม่ทั้งหมด แต่เป็นการเลือกคลาสและเมธอดที่เป็นประโยชน์ (และใช้งานได้) ฝั่งไคลเอ็นต์ ฟังก์ชันการทำงานที่อยู่ใน Java JRE แต่คุณจะไม่พบใน Emulated JRE แบ่งออกเป็นสามประเภท:

• สิ่งที่ไม่สามารถย้ายฝั่งไคลเอ็นต์ ตัวอย่างเช่น java.lang.Thread หรือ java.io.File ไม่สามารถนำมาใช้ในเบราว์เซอร์ที่มีความหมายเดียวกันกับ Java หน้าเบราว์เซอร์เป็นแบบเธรดเดียวและไม่มีการเข้าถึงระบบไฟล์โดยตรง

• สิ่งที่สามารถนำมาใช้ได้ แต่จะ "เสียค่าใช้จ่ายมากเกินไป" ในแง่ของขนาดโค้ด ประสิทธิภาพ หรือการขึ้นต่อกัน และสิ่งที่ชุมชนไม่ต้องการให้มีอยู่ใน GWT ตัวอย่างเช่น ที่รวมอยู่ในหมวดหมู่นี้คือการสะท้อนของ Java ( java.lang.reflect ) ซึ่งจะต้องการให้ทรานสปิลเลอร์เก็บข้อมูลคลาสสำหรับแต่ละประเภท และนั่นจะทำให้ขนาดของ JavaScript ที่คอมไพล์เป็นบอลลูน

• สิ่งที่ไม่มีใครสนใจจึงยังไม่ได้ดำเนินการ

หากเกิดขึ้นที่ Emulated JRE ไม่ตรงกับความต้องการของคุณ (เช่น คุณต้องมีคลาสที่ไม่ได้จัดเตรียมไว้) GWT จะอนุญาตให้คุณเขียนการนำไปใช้งานของคุณเอง กลไกอันทรงพลังนี้มีให้ใช้งานผ่านแท็ก <super-source> ทำให้สามารถหลีกเลี่ยงปัญหาเมื่อปรับไลบรารีภายนอกใหม่ที่ใช้บางส่วนของ JRE ที่ไม่ได้จำลอง

อาจซับซ้อนเกินไปหรือเป็นไปไม่ได้เลยที่จะจัดให้มีการใช้งานบางส่วนของ JRE อย่างเต็มรูปแบบ ดังนั้นสำหรับงานเฉพาะ การใช้งานของคุณเองอาจไม่เป็นไปตามความหมายของ JRE ของ Java อย่างเคร่งครัด แม้ว่าจะใช้งานได้ในกรณีเฉพาะของคุณก็ตาม อันที่จริง หากคุณกำลังพิจารณาที่จะมอบคลาสของคุณกลับไปที่โปรเจ็กต์ จำไว้ว่ามันมีความสำคัญอย่างยิ่งยวดสำหรับ Emulated JRE ที่แต่ละคลาสที่รวมไว้นั้นเป็นไปตามความหมายเดียวกันของ Java JRE ดั้งเดิม เพื่อให้แน่ใจว่าทุกคนสามารถคอมไพล์โค้ด Java ใหม่เป็น JavaScript และไว้วางใจว่าพวกเขาจะได้รับผลลัพธ์ที่คาดหวัง ตรวจสอบให้แน่ใจเสมอว่าโค้ดของคุณได้รับการทดสอบอย่างละเอียดถี่ถ้วนก่อนที่จะส่งคืนให้กับชุมชน

เลเยอร์การทำงานร่วมกัน

เพื่อให้เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการผลิตแอปพลิเคชันบนเว็บในโลกแห่งความเป็นจริง GWT ต้องอนุญาตให้นักพัฒนาโต้ตอบกับแพลตฟอร์มพื้นฐานได้อย่างง่ายดาย นั่นคือเบราว์เซอร์และ DOM

ตั้งแต่เริ่มต้น GWT ถูกสร้างขึ้นเพื่อรองรับการโต้ตอบผ่าน JavaScript Native Interface (JSNI) ซึ่งทำให้การเข้าถึง API ในเบราว์เซอร์เป็นเรื่องง่าย ตัวอย่างเช่น การใช้คุณลักษณะทางไวยากรณ์เฉพาะสำหรับคอมไพเลอร์ GWT คุณสามารถเขียนโค้ด Java ต่อไปนี้:

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

และคุณมีอิสระที่จะใช้เนื้อหาของวิธีการใน JavaScript คุณยังสามารถรวมออบเจ็กต์ JavaScript ใน JavaScriptObject (JSO) และทำให้สามารถเข้าถึงได้ในโค้ด Java ของคุณ

ตัวอย่างของตำแหน่งที่เลเยอร์นี้เข้ามาเล่นสามารถพบได้ในบริบทขององค์ประกอบ UI Java กระแสหลักมักใช้ชุดเครื่องมือวิดเจ็ตมาตรฐานเสมอเพื่อสร้างองค์ประกอบ UI โดยใช้ประโยชน์จาก Java Native Interface เพื่อเข้าถึงระบบหน้าต่างและระบบอินพุตของระบบปฏิบัติการ เลเยอร์ความสามารถในการทำงานร่วมกันของ GWT ทำสิ่งเดียวกัน ดังนั้นวิดเจ็ตแบบเดิมจึงทำงานได้อย่างราบรื่นภายในเบราว์เซอร์ ข้อแตกต่างเพียงอย่างเดียวคือ ในกรณีนี้ ระบบพื้นฐานคือเบราว์เซอร์และ DOM

อย่างไรก็ตาม เฟรมเวิร์กฟรอนต์เอนด์ดั้งเดิมได้รับการปรับปรุงอย่างรวดเร็วในช่วงไม่กี่ปีที่ผ่านมา และในปัจจุบันมีข้อได้เปรียบที่สำคัญเหนือวิดเจ็ตของ GWT เมื่อเฟรมเวิร์กเหล่านี้เติบโตขึ้นอย่างซับซ้อน ความพยายามที่จะนำไปใช้ใน JSNI ได้เผยให้เห็นข้อบกพร่องในสถาปัตยกรรมของเลเยอร์การทำงานร่วมกัน เริ่มต้นด้วยเวอร์ชัน 2.7 GWT ได้แนะนำ JsInterop ซึ่งเป็นแนวทางใหม่ตามคำอธิบายประกอบของ Java ซึ่งช่วยให้คุณผสานรวมคลาส GWT ของคุณกับ JavaScript ได้อย่างรวดเร็วและง่ายดาย ไม่จำเป็นต้องเขียนเมธอด JSNI หรือคลาส JSO อีกต่อไป คุณสามารถใช้คำอธิบายประกอบเช่น @JSType หรือ @JSProperty ได้ ทำให้คุณสามารถทำงานกับคลาส JavaScript ดั้งเดิมราวกับว่าเป็น Java

ข้อมูลจำเพาะทั้งหมดของ JsInterop ยังอยู่ในระหว่างดำเนินการ และสามารถทดลองใช้การอัปเดตล่าสุดได้โดยรวบรวมแหล่งที่มาจากที่เก็บ GWT เท่านั้น แต่เห็นได้ชัดว่านี่คือทิศทางใหม่ที่จะทำให้ GWT สามารถติดตามแพลตฟอร์มเว็บที่กำลังพัฒนาได้

โปรเจ็กต์ต่อเนื่องหนึ่งโครงการที่ใช้ประโยชน์จาก JsInterop คือ gwt-polymer-elements ที่เพิ่งเปิดตัว ซึ่งทำให้องค์ประกอบเหล็กและกระดาษทั้งหมดจากพอลิเมอร์พร้อมใช้งานสำหรับ GWT สิ่งที่น่าสนใจในไลบรารีนี้คือนักพัฒนาไม่จำเป็นต้องสร้าง Java API ด้วยมือ โปรเจ็กต์ใช้ gwt-api-generator เพื่อสร้างอินเทอร์เฟซส่วนใหญ่ได้โดยตรงโดยการแยกวิเคราะห์ไลบรารี Polymer และคำอธิบายประกอบ JSDoc ทำให้การผูกมัดเป็นปัจจุบันได้ง่าย

คำพูดสุดท้าย

ด้วยการปรับปรุงคอมไพเลอร์ เลเยอร์การทำงานร่วมกัน และประสิทธิภาพและขนาดของโค้ดที่สร้างขึ้นในช่วงสองปีที่ผ่านมา เป็นที่ชัดเจนว่า GWT ไม่ได้เป็นเพียง "เครื่องมือพัฒนาเว็บอีกตัวหนึ่ง" แต่กำลังจะกลายเป็นชุดเครื่องมืออ้างอิงที่สำคัญสำหรับ การพัฒนาเว็บแอปพลิเคชันขนาดใหญ่และซับซ้อน และอาจเป็นตัวเลือกที่ยอดเยี่ยมในการทำให้แอปที่ใช้งานง่ายขึ้นนั้นยอดเยี่ยม

ฉันใช้ GWT ทุกวันในการทำงานเป็นนักพัฒนาและที่ปรึกษา แต่ส่วนใหญ่ฉันชอบ GWT เพราะมันทำให้ฉันสามารถผลักดันขีดจำกัดของความสามารถของเบราว์เซอร์และแสดงให้เห็นว่าเว็บแอปพลิเคชันสมัยใหม่สามารถมีประสิทธิภาพเท่ากับแอปพลิเคชันเดสก์ท็อป

ชุมชนของโครงการ GWT มีความกระตือรือร้นอย่างมาก และมีการเสนอไลบรารี โครงการ และแอปพลิเคชันใหม่ๆ ที่อิงตาม GWT อย่างต่อเนื่อง ในเมืองฟลอเรนซ์ งาน GWTcon2015 ที่ขับเคลื่อนโดยชุมชนจะมีขึ้นในวันที่ 11 พฤศจิกายน หากคุณอยู่ในภูมิภาคนี้ ฉันหวังว่าคุณจะมาพบกับนักพัฒนาหลักบางส่วน และเรียนรู้เกี่ยวกับโอกาสทั้งหมดที่จะได้เป็นส่วนหนึ่งของวิวัฒนาการของชุดเครื่องมือที่น่าทึ่งนี้