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 จากนั้นหากจำเป็นต้องใช้เว็บ API เฉพาะหรือใช้ประโยชน์จากไลบรารี JavaScript ที่มีอยู่เพื่อ 'ใช้งานแบบเนทีฟ' และข้ามไปยัง JavaScript

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

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

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

ย้อนกลับไปในปี 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 จัดขึ้นทั้งในมิวนิกเยอรมนีและเมาน์เทนวิวแคลิฟอร์เนียในเดือนมกราคมและมีผู้เข้าร่วมมากกว่า 600 คนจากหลายสิบประเทศ ในวันที่ 11 พฤศจิกายนในฟลอเรนซ์ประเทศอิตาลีเราจะจัดพิมพ์ GWTcon การประชุม GWT ที่ขับเคลื่อนโดยชุมชนซึ่งฉันกำลังช่วยจัด

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

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

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

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

windows เขียนว่าอะไร

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

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

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

ส่วนหน้าของ JavaScript ด้วยพลังของแอป Java? ใช่คุณก็สามารถมีได้ทั้งหมดด้วย GWT! ทวีต

Under the Hood: เปลี่ยน Java เป็น JavaScript

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

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

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

GWT's Optimizing Compiler

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

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

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

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

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

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

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

JRE จำลอง

คอมไพเลอร์ Java-to-JavaScript จะมีความแปลกใหม่เล็กน้อยหากไม่ได้รับการเสริมด้วยการใช้งาน Java Runtime Environment (JRE) ซึ่งให้ไลบรารีหลักที่อาศัยโดยแอปพลิเคชัน Java เกือบทุกชนิด พูดอย่างคร่าวๆว่าการทำงานใน Java โดยไม่ใช้วิธีการ Collections หรือ String จะทำให้หงุดหงิดและแน่นอนว่าการย้ายไลบรารีเหล่านี้ถือเป็นงานไททานิก GWT เติมช่องนี้ด้วยสิ่งที่เรียกว่า 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 อนุญาตให้คุณเขียนการใช้งานของคุณเอง กลไกที่ทรงพลังนี้มีอยู่ในแท็กทำให้สามารถหลีกเลี่ยงปัญหาเมื่อปรับไลบรารีภายนอกใหม่ที่ใช้ส่วนต่างๆของ JRE ที่ไม่ได้จำลอง

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

Interoperability Layer

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

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

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

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

ตัวอย่างของตำแหน่งที่เลเยอร์นี้เข้ามาเล่นสามารถพบได้ในบริบทขององค์ประกอบ UI Mainstream Java ใช้ชุดเครื่องมือ Widgets มาตรฐานในการสร้างองค์ประกอบ 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- พอลิเมอร์องค์ประกอบ ซึ่งทำให้องค์ประกอบเหล็กและกระดาษทั้งหมดจาก พอลิเมอร์ ใช้ได้กับ GWT สิ่งที่น่าสนใจในไลบรารีนี้คือผู้พัฒนาไม่จำเป็นต้องสร้าง Java API ด้วยมือ โครงการใช้ gwt-api-generator เพื่อสร้างอินเทอร์เฟซส่วนใหญ่โดยตรงโดยการแยกวิเคราะห์ไลบรารีโพลิเมอร์และคำอธิบายประกอบ JSDoc ทำให้การผูกข้อมูลเป็นปัจจุบันเป็นเรื่องง่าย

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

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

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

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