Kyiv Go Meetup พฤษภาคม 2018:
ผู้ดำเนินรายการ: - สวัสดีทุกคน! ขอบคุณที่อยู่ที่นี่! วันนี้เรามีวิทยากรอย่างเป็นทางการสองคน - Lyosha และ Vanya จะมีอีกสองถ้าเรามีเวลาเพียงพอ วิทยากรคนแรกคือ Alexey Grachev เขาจะเล่าให้เราฟังเกี่ยวกับ GopherJS
อเล็กเซย์ กราเชฟ (ต่อไปนี้จะเรียกว่า – เอจี): – ฉันเป็นนักพัฒนา Go และฉันเขียนบริการเว็บใน Go บางครั้งคุณต้องจัดการกับส่วนหน้า บางครั้งคุณต้องเข้าไปแก้ไขด้วยตนเอง ฉันต้องการพูดคุยเกี่ยวกับประสบการณ์และการค้นคว้าเกี่ยวกับ Go ในส่วนหน้า
ตำนานก็คือ อันดับแรกเราจะพูดถึงสาเหตุที่เราต้องการรัน Go บนฟรอนต์เอนด์ จากนั้นเราจะพูดถึงวิธีการนี้ มีสองวิธี - Web Assembly และ GopherJS มาดูกันว่าสถานะของโซลูชั่นเหล่านี้คืออะไรและทำอะไรได้บ้าง
มีอะไรผิดปกติกับส่วนหน้า?
ทุกคนเห็นด้วยหรือไม่ว่าทุกอย่างเรียบร้อยดีกับส่วนหน้า?
มีการทดสอบไม่เพียงพอหรือไม่? สร้างช้า? ระบบนิเวศ? ดี.
เกี่ยวกับส่วนหน้า ฉันชอบคำพูดที่หนึ่งในนักพัฒนาส่วนหน้ากล่าวไว้ในหนังสือของเขา:
Javascript ไม่มีระบบประเภท ตอนนี้ฉันจะบอกชื่อปัญหาที่ฉันพบระหว่างการทำงานและอธิบายว่าจะแก้ไขอย่างไร
ระบบประเภทโดยทั่วไปแทบจะเรียกได้ว่าเป็นระบบประเภทใน Javasript แทบไม่ได้ - มีบรรทัดที่ระบุประเภทของอ็อบเจ็กต์ แต่อันที่จริงสิ่งนี้ไม่เกี่ยวข้องกับประเภทเลย ปัญหานี้แก้ไขได้ใน TypeScript (ส่วนเสริมของ Javasript) และ Flow (ตัวตรวจสอบประเภทคงที่ใน Javascript) จริงๆ แล้วส่วนหน้าได้มาถึงจุดแก้ไขปัญหาระบบประเภทที่ไม่ดีใน Javascript แล้ว
ไม่มีไลบรารี่มาตรฐานในเบราว์เซอร์เช่นนี้ - มีออบเจ็กต์ในตัวและฟังก์ชัน "วิเศษ" ในเบราว์เซอร์ แต่ใน Javascript ไม่มีไลบรารี่มาตรฐานเช่นนี้ ปัญหานี้ได้รับการแก้ไขแล้วครั้งหนึ่งโดย jQuery (ทุกคนใช้ jQuery กับต้นแบบ ตัวช่วย และฟังก์ชันที่จำเป็นในการทำงานทั้งหมด) ตอนนี้ทุกคนใช้ Lodash:
โทรกลับนรก. ฉันคิดว่าทุกคนเห็นโค้ด Javascript เมื่อประมาณ 5 ปีที่แล้ว และมันดูเหมือนเป็น "เส้นก๋วยเตี๋ยว" ที่ซับซ้อนอย่างไม่น่าเชื่อของการโทรกลับ ตอนนี้ปัญหานี้ได้รับการแก้ไขแล้ว (ด้วยการเปิดตัว ES-15 หรือ ES-16) มีการเพิ่มสัญญาใน Javascript และทุกคนสามารถหายใจได้ง่ายขึ้นชั่วขณะหนึ่ง
จนกระทั่งนรก Promice มาถึง... ฉันไม่รู้ว่าอุตสาหกรรมส่วนหน้าจัดการอย่างไร แต่พวกเขามักจะพาตัวเองเข้าไปในป่าที่แปลกประหลาด เรายังจัดการให้นรกตามสัญญาด้วย จากนั้นเราก็แก้ไขปัญหานี้ด้วยการเพิ่มค่าดั้งเดิมใหม่ - async/await:
ปัญหาเกี่ยวกับความไม่ตรงกันได้รับการแก้ไขแล้ว Async/await เป็นภาษาดั้งเดิมที่ค่อนข้างได้รับความนิยมในภาษาต่างๆ Python และคนอื่นๆ มีแนวทางนี้ - มันค่อนข้างดี แก้ไขปัญหา.
ปัญหาอะไรที่ไม่ได้รับการแก้ไข? ความซับซ้อนที่เพิ่มขึ้นอย่างทวีคูณของกรอบงาน ความซับซ้อนของระบบนิเวศและตัวโปรแกรมเอง
- ไวยากรณ์ Javascript ค่อนข้างแปลก เราทุกคนรู้ถึงปัญหาในการเพิ่มอาร์เรย์และวัตถุและเรื่องตลกอื่นๆ
- Javascript มีหลายกระบวนทัศน์ นี่เป็นระบบที่เร่งด่วนอย่างยิ่งในขณะนี้ เมื่อระบบนิเวศมีขนาดใหญ่มาก:
- ทุกคนเขียนในรูปแบบที่แตกต่างกัน - บางคนเขียนเชิงโครงสร้าง บางคนเขียนตามการใช้งาน นักพัฒนาต่างเขียนด้วยวิธีที่ต่างกัน
- จากแพ็คเกจที่แตกต่างกัน กระบวนทัศน์ที่แตกต่างกันเมื่อคุณใช้แพ็คเกจที่แตกต่างกัน
- มี "ความสนุก" มากมายกับการเขียนโปรแกรมเชิงฟังก์ชันใน Javasript - ไลบรารี rambda ปรากฏขึ้นและตอนนี้ไม่มีใครสามารถอ่านโปรแกรมที่เขียนในไลบรารีนี้ได้
- ทั้งหมดนี้ส่งผลกระทบอย่างมากต่อระบบนิเวศ และเติบโตขึ้นอย่างไม่น่าเชื่อ แพ็คเกจต่างๆ เข้ากันไม่ได้: บางส่วนขึ้นอยู่กับสัญญา, บางส่วนขึ้นอยู่กับ async/await, บางส่วนขึ้นอยู่กับการโทรกลับ พวกเขายังเขียนในกระบวนทัศน์ที่แตกต่างกัน!
- ทำให้โครงการนี้ยากต่อการบำรุงรักษา เป็นการยากที่จะหาจุดบกพร่องหากคุณไม่สามารถอ่านโค้ดได้
เว็บแอสเซมบลีคืออะไร?
ผู้กล้าหาญจาก Mozilla Foundation และบริษัทอื่นๆ อีกจำนวนหนึ่งได้คิดค้น Web Assembly นี่คืออะไร?
- นี่คือเครื่องเสมือนที่สร้างไว้ในเบราว์เซอร์ที่รองรับรูปแบบไบนารี
- โปรแกรมไบนารี่ไปถึงที่นั่นและดำเนินการเกือบจะแบบเนทีฟ กล่าวคือ เบราว์เซอร์ไม่จำเป็นต้องแยกวิเคราะห์ "บะหมี่" ของโค้ดจาวาสคริปต์ทุกครั้ง
- เบราว์เซอร์ทั้งหมดได้ประกาศการสนับสนุนแล้ว
- เนื่องจากนี่คือ bytecode คุณจึงสามารถเขียนคอมไพเลอร์สำหรับภาษาใดก็ได้
- เบราว์เซอร์หลักสี่ตัวมาพร้อมกับการสนับสนุน Web Assembly แล้ว
- เราคาดหวังว่าจะได้รับการสนับสนุนแบบเนทิฟใน Go เร็วๆ นี้ สถาปัตยกรรมใหม่นี้ได้ถูกเพิ่มแล้ว: GOARCH=wasm GOOS=js (เร็วๆ นี้) เท่าที่ฉันเข้าใจมันใช้งานไม่ได้ แต่มีข้อความว่ามันจะอยู่ใน Go แน่นอน
จะทำอย่างไรตอนนี้? โกเฟอร์JS
แม้ว่าเราจะไม่รองรับ Web Assembly แต่ก็มี transpiler เช่น GopherJS
- โค้ด Go ถูกแปลงเป็น Javascript ที่ "บริสุทธิ์"
- ทำงานได้ในทุกเบราว์เซอร์ - ไม่มีคุณสมบัติใหม่ที่รองรับเฉพาะเบราว์เซอร์สมัยใหม่เท่านั้น (นี่คือ Vanilla JS ซึ่งทำงานบนอะไรก็ได้)
- มีการรองรับเกือบทุกอย่างที่ Go มี รวมถึง goroutines และช่องทาง... ทุกสิ่งที่เรารักและรู้มาก
- รองรับไลบรารีมาตรฐานเกือบทั้งหมด ยกเว้นแพ็คเกจที่ไม่สมเหตุสมผลที่จะรองรับในเบราว์เซอร์: syscall, การโต้ตอบทางเน็ต (มีไคลเอนต์ net/http แต่ไม่มีเซิร์ฟเวอร์ และไคลเอนต์ถูกจำลองผ่าน XMLHttpRequest) โดยทั่วไปแล้ว ไลบรารีมาตรฐานทั้งหมดจะพร้อมใช้งาน - ที่นี่อยู่ในเบราว์เซอร์ นี่คือ stdlib ของ Go ที่เราชอบ
- ระบบนิเวศแพ็คเกจทั้งหมดใน Go โซลูชันของบริษัทอื่นทั้งหมด (เทมเพลต ฯลฯ) สามารถคอมไพล์ได้โดยใช้ GopherJS และรันในเบราว์เซอร์
GopherJS ได้มาง่ายมาก - เป็นเพียงแพ็คเกจ Go ทั่วไป เราไปรับและเรามีคำสั่ง GopherJS เพื่อสร้างแอปพลิเคชัน:
สวัสดีโลกใบเล็กๆ แห่งนี้...
...โปรแกรม Go ทั่วไป แพ็คเกจ fmt ไลบรารี่มาตรฐานปกติ และ Binding Js เพื่อเข้าถึง API ของเบราว์เซอร์ ในที่สุด Println จะถูกแปลงเป็นบันทึกคอนโซลและเบราว์เซอร์จะเขียนว่า “Hello gophers”! มันง่ายมาก: เราทำ GopherJS build - เราเปิดใช้งานในเบราว์เซอร์ - ทุกอย่างใช้งานได้!
คุณมีอะไรอยู่ในขณะนี้? การผูก
มีการผูกข้อมูลสำหรับเฟรมเวิร์ก js ยอดนิยมทั้งหมด:
- เจคิวรี;
- Angular.js;
- D3.js สำหรับการวางแผนและทำงานกับข้อมูลขนาดใหญ่
- React.js;
- วูจเอส;
- มีการรองรับ Electron ด้วยซ้ำ (นั่นคือเราสามารถเขียนแอปพลิเคชันเดสก์ท็อปบน Electron ได้แล้ว)
- และสิ่งที่สนุกที่สุดคือ WebGL (เราสามารถสร้างแอพพลิเคชั่นกราฟิกเต็มรูปแบบได้ รวมถึงเกมที่มีกราฟิก 3D เพลง และสิ่งอื่นๆ ทั้งหมด)
- และการโยงอื่น ๆ อีกมากมายกับเฟรมเวิร์กและไลบรารีจาวาสคริปต์ยอดนิยมทั้งหมด
กรอบ
- มี Web Framework ที่พัฒนาแล้วโดยเฉพาะสำหรับ GopherJS - Vecty นี่คืออะนาล็อกเต็มรูปแบบของ React.js แต่ได้รับการพัฒนาใน Go เท่านั้น โดยมีข้อมูลเฉพาะของ GopherJS
- มีถุงใส่เกมด้วย (เซอร์ไพรส์!) ฉันพบสองรายการที่ได้รับความนิยมมากที่สุด:
- เอนโก;
- เอบิเทน
ฉันจะแสดงตัวอย่างสองสามตัวอย่างว่าหน้าตาเป็นอย่างไรและคุณสามารถเขียนใน Go ได้แล้ว:
หรือตัวเลือกนี้ (ฉันไม่พบเกมยิง 3 มิติ แต่อาจมีอยู่):
ฉันกำลังเสนออะไร?
ตอนนี้อุตสาหกรรมส่วนหน้าอยู่ในสถานะที่ภาษาทั้งหมดที่เคยร้องจาก Javascript ก่อนหน้านี้จะรีบเร่งไปที่นั่น ตอนนี้ทุกอย่างจะถูกรวบรวมเป็น "Web Assemblies" เราต้องทำอะไรเพื่อเข้ารับตำแหน่งที่ถูกต้องในฐานะโกเฟอร์?
Go สันนิษฐานว่าเป็นภาษาการเขียนโปรแกรมระบบ และในทางปฏิบัติแล้วไม่มีไลบรารีสำหรับการทำงานกับ UI มีบางอย่างแต่ถูกละทิ้งไปครึ่งหนึ่ง ครึ่งหนึ่งใช้งานไม่ได้
และตอนนี้เป็นโอกาสที่ดีที่จะสร้างไลบรารี่ UI ใน Go ที่จะทำงานบน GopherJS! ในที่สุดคุณก็สามารถเขียน Framework ของคุณเองได้แล้ว! นี่คือเวลาที่คุณสามารถเขียน Framework ได้ และจะเป็นหนึ่งใน Framework แรกๆ ที่ได้รับการนำไปใช้ตั้งแต่เนิ่นๆ และคุณจะเป็นดาวเด่น (หากเป็น Framework ที่ดี)
คุณสามารถปรับใช้แพ็คเกจต่างๆ มากมายที่มีอยู่ในระบบนิเวศ Go อยู่แล้วให้เข้ากับลักษณะเฉพาะของเบราว์เซอร์ได้ (เช่น เครื่องมือเทมเพลต) พวกเขาจะใช้งานได้แล้วคุณสามารถเชื่อมโยงได้อย่างสะดวกเพื่อให้คุณสามารถแสดงเนื้อหาในเบราว์เซอร์ได้โดยตรง นอกจากนี้ คุณยังสามารถสร้างบริการที่สามารถเรนเดอร์สิ่งเดียวกันบนเซิร์ฟเวอร์และฟรอนต์เอนด์ได้ โดยใช้โค้ดเดียวกัน - ทุกอย่างที่นักพัฒนาฟรอนต์เอนด์ชอบ (ตอนนี้มีเฉพาะใน Go)
คุณสามารถเขียนเกมได้! แค่เล่น ๆ...
นั่นคือทั้งหมดที่ฉันอยากจะพูด
คำถาม
คำถาม (ต่อไปนี้จะเรียกว่า Q): – ฉันจะเขียนใน Go หรือ Js?
เอจี: – คุณเขียนรูทีน ช่อง โครงสร้าง การฝัง – ทุกอย่างใน Go... คุณสมัครรับข้อมูลกิจกรรม ส่งฟังก์ชันที่นั่น
ที่: – ดังนั้นฉันจึงเขียนด้วยคำว่า "เปลือย" Js?
เอจี: – ไม่ คุณเขียนราวกับว่าอยู่ใน Go และเชื่อมต่อกับเบราว์เซอร์ API (API ไม่มีการเปลี่ยนแปลง) คุณสามารถเขียนการเชื่อมโยงของคุณเองเพื่อให้ข้อความถูกส่งไปยังช่องได้ไม่ยาก
ที่: – แล้วมือถือล่ะ?
เอจี: – ฉันเห็นอย่างแน่นอน: มีการผูกมัดสำหรับแพตช์ Cordova ที่ Js ทำงาน ใน React Native - ฉันไม่รู้; อาจจะมีอาจจะไม่ (ฉันไม่ได้สนใจเป็นพิเศษ) เอ็นจิ้นเกม N-go รองรับทั้งแอปพลิเคชั่นมือถือ - ทั้ง iOS และ Android
ที่: – คำถามเกี่ยวกับ Web Assembly มีการใช้พื้นที่มากขึ้นเรื่อยๆ แม้ว่าจะมีการบีบอัดและ "บีบอัด"... เราจะไม่ฆ่าโลกส่วนหน้าด้วยวิธีนี้อีกต่อไปหรือ?
เอจี: – Web Assembly เป็นรูปแบบไบนารี และโดยค่าเริ่มต้น ไบนารี่ไม่สามารถอยู่ในเวอร์ชันสุดท้ายได้มากกว่าข้อความ... คุณสนใจรันไทม์ แต่นี่ก็เหมือนกับการลากไลบรารี Javascript มาตรฐานออกมาเมื่อไม่มีอยู่ ดังนั้นเราจึง ใช้ Lodash บ้าง ฉันไม่รู้ว่า Lodash ใช้เวลาเท่าไหร่
ที่: – น้อยกว่ารันไทม์อย่างเห็นได้ชัด...
เอจี: – ใน Javascript “บริสุทธิ์”?
ที่: - ใช่. เราบีบอัดก่อนส่ง...
เอจี: – แต่นี่คือข้อความ... โดยทั่วไปแล้ว หนึ่งเมกะไบต์ดูเหมือนจะมาก แต่นั่นคือทั้งหมด (คุณมีเวลารันไทม์ทั้งหมด) ถัดไป คุณเขียนตรรกะทางธุรกิจของคุณเอง ซึ่งจะเพิ่มไบนารีของคุณ 1% จนถึงตอนนี้ฉันยังไม่เห็นว่าสิ่งนี้ฆ่าส่วนหน้า ยิ่งไปกว่านั้น Web Assembly จะทำงานเร็วกว่า Javascript ด้วยเหตุผลที่ชัดเจน - ไม่จำเป็นต้องแยกวิเคราะห์
ที่: – นี่ยังคงเป็นประเด็นที่ถกเถียงกันอยู่... ยังไม่มีการนำ “Vasma” (Web Assembly) ไปใช้อ้างอิงใดๆ เพื่อให้สามารถตัดสินได้อย่างไม่คลุมเครือ ตามแนวคิดแล้ว ใช่ เราทุกคนเข้าใจว่าไบนารีควรเร็วกว่า แต่การใช้งาน V8 เดียวกันในปัจจุบันนั้นมีประสิทธิภาพมาก
เอจี: - ใช่.
ที่: – การคอมไพล์ที่นั่นทำได้ยอดเยี่ยมมากและไม่ใช่ความจริงที่ว่าจะมีข้อได้เปรียบใหญ่
เอจี: – Web Assembly ก็ทำโดยคนตัวใหญ่เช่นกัน
ที่: – สำหรับฉันดูเหมือนว่าการตัดสิน Web Assembly ยังคงเป็นเรื่องยาก มีการสนทนากันมานานหลายปีแล้ว แต่มีความสำเร็จที่แท้จริงเพียงเล็กน้อยที่สามารถสัมผัสได้
เอจี: - อาจจะ. เราจะเห็น.
ที่: – เราไม่มีปัญหาในส่วนแบ็กเอนด์... บางทีเราควรทิ้งปัญหาเหล่านี้ไว้ที่ส่วนหน้าใช่ไหม ไปที่นั่นทำไม?
เอจี: – เราต้องรักษาพนักงานแนวหน้าไว้
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com