Cuộc gặp gỡ Kyiv Go tháng 2018 năm XNUMX:
Dẫn: - Chào mọi người! Cảm ơn bạn đã ở đây! Hôm nay chúng ta có hai diễn giả chính thức - Lyosha và Vanya. Sẽ còn hai cái nữa nếu chúng ta có đủ thời gian. Diễn giả đầu tiên là Alexey Grachev, anh ấy sẽ kể cho chúng ta nghe về GopherJS.
Alexey Grachev (sau đây gọi là – AG): – Tôi là nhà phát triển Go và tôi viết các dịch vụ web bằng Go. Đôi khi bạn phải xử lý giao diện người dùng, đôi khi bạn phải vào đó một cách thủ công. Tôi muốn nói về trải nghiệm và nghiên cứu của tôi về Go trên frontend.
Truyền thuyết là thế này: đầu tiên chúng ta sẽ nói về lý do tại sao chúng ta muốn chạy Go trên giao diện người dùng, sau đó chúng ta sẽ nói về cách thực hiện điều này. Có hai cách - Web Assembly và GopherJS. Hãy xem tình trạng của những giải pháp này là gì và có thể làm được gì.
Có vấn đề gì với giao diện người dùng vậy?
Mọi người có đồng ý rằng mọi thứ đều ổn với giao diện người dùng không?
Không có đủ bài kiểm tra? Xây dựng chậm? Hệ sinh thái? Khỏe.
Về giao diện người dùng, tôi thích câu nói mà một trong những nhà phát triển giao diện người dùng đã nói trong cuốn sách của mình:
Javascript không có hệ thống loại. Bây giờ tôi sẽ kể tên những vấn đề tôi gặp phải trong quá trình làm việc và giải thích cách giải quyết chúng.
Hệ thống kiểu nói chung khó có thể được gọi là hệ thống kiểu trong Javasript - có những dòng chỉ ra kiểu của đối tượng, nhưng thực tế điều này không liên quan gì đến kiểu. Vấn đề này được giải quyết trong TypeScript (một tiện ích bổ sung cho Javasript) và Flow (trình kiểm tra kiểu tĩnh trong Javascript). Trên thực tế, giao diện người dùng đã đạt đến mức giải quyết được vấn đề hệ thống loại xấu trong Javascript.
Không có thư viện tiêu chuẩn nào trong trình duyệt như vậy - có một số đối tượng tích hợp sẵn và các chức năng “ma thuật” trong trình duyệt. Nhưng trong Javascript không có thư viện chuẩn như vậy. Vấn đề này đã được jQuery giải quyết một lần (mọi người đều sử dụng jQuery với tất cả các nguyên mẫu, trợ giúp, hàm cần thiết để hoạt động). Bây giờ mọi người đều sử dụng Lodash:
Gọi lại chết tiệt. Tôi nghĩ mọi người đều đã nhìn thấy mã Javascript khoảng 5 năm trước và nó trông giống như một “món mì” với sự phức tạp đáng kinh ngạc của các lệnh gọi lại. Giờ đây, vấn đề này đã được giải quyết (với việc phát hành ES-15 hoặc ES-16), các lời hứa đã được thêm vào Javascript và mọi người có thể dễ thở hơn trong một thời gian.
Cho đến khi địa ngục Promise đến... Tôi không biết ngành công nghiệp front-end quản lý như thế nào, nhưng họ luôn lao mình vào một khu rừng kỳ lạ nào đó. Chúng tôi cũng đã cố gắng thực hiện những lời hứa. Sau đó, chúng tôi đã giải quyết vấn đề này bằng cách thêm một nguyên hàm mới - async/await:
Vấn đề với sự không đồng bộ được giải quyết. Async/await là một nguyên thủy khá phổ biến trong nhiều ngôn ngữ khác nhau. Python và những người khác có cách tiếp cận này - nó khá tốt. Vấn đề đã được giải quyết.
Vấn đề gì không được giải quyết? Độ phức tạp ngày càng tăng theo cấp số nhân của các khuôn khổ, độ phức tạp của hệ sinh thái và bản thân các chương trình.
- Cú pháp Javascript hơi lạ. Tất cả chúng ta đều biết các vấn đề khi thêm một mảng và một đối tượng cũng như những trò đùa khác.
- Javascript là đa mô hình. Đây là một hệ thống đặc biệt cấp bách hiện nay khi hệ sinh thái rất lớn:
- mọi người viết theo những phong cách khác nhau - một số viết theo cấu trúc, một số viết theo chức năng, các nhà phát triển khác nhau viết theo những cách khác nhau;
- từ các gói khác nhau, các mô hình khác nhau khi bạn sử dụng các gói khác nhau;
- có rất nhiều điều “thú vị” với lập trình hàm trong Javasript - thư viện rambda đã xuất hiện và giờ đây không ai có thể đọc được các chương trình được viết trong thư viện này.
- Tất cả điều này tạo ra tác động lớn đến hệ sinh thái và nó đã phát triển một cách đáng kinh ngạc. Các gói không tương thích với nhau: một số dựa trên lời hứa, một số dựa trên async/await, một số dựa trên lệnh gọi lại. Họ cũng viết theo những mô hình khác nhau!
- Điều này làm cho dự án khó bảo trì. Thật khó để tìm ra lỗi nếu bạn không thể đọc được mã.
Web hội là gì?
Những người dũng cảm từ Mozilla Foundation và một số công ty khác đã nghĩ ra một thứ như Web Assembly. Cái này là cái gì?
- Đây là một máy ảo được tích hợp trong trình duyệt hỗ trợ định dạng nhị phân.
- Các chương trình nhị phân đạt được điều đó và được thực thi gần như nguyên bản, nghĩa là trình duyệt không cần phải phân tích cú pháp tất cả các “mì” của mã javascript mỗi lần.
- Tất cả các trình duyệt đã tuyên bố hỗ trợ.
- Vì đây là mã byte nên bạn có thể viết trình biên dịch cho bất kỳ ngôn ngữ nào.
- Bốn trình duyệt chính đã được hỗ trợ Web Assembly.
- Chúng tôi mong sớm nhận được sự hỗ trợ gốc trong Go. Kiến trúc mới này đã được thêm vào: GOARCH=wasm GOOS=js (sớm). Cho đến nay, theo tôi hiểu thì nó không hoạt động, nhưng có một tuyên bố rằng nó chắc chắn sẽ có trong Go.
Làm gì bây giờ? GopherJS
Mặc dù chúng tôi không hỗ trợ Web Assembly nhưng vẫn có một trình chuyển mã như GopherJS.
- Mã Go được dịch sang Javascript “thuần túy”.
- Chạy trong tất cả các trình duyệt - không có tính năng mới nào chỉ được hỗ trợ bởi các trình duyệt hiện đại (đây là Vanilla JS, chạy trên mọi thứ).
- Có sự hỗ trợ cho hầu hết mọi thứ mà Go có, bao gồm goroutines và kênh... mọi thứ chúng tôi yêu thích và biết rất nhiều.
- Hầu như toàn bộ thư viện tiêu chuẩn đều được hỗ trợ, ngoại trừ những gói không thể hỗ trợ trong trình duyệt: syscall, tương tác mạng (có máy khách net/http, nhưng không có máy chủ và máy khách được mô phỏng qua XMLHttpRequest). Nói chung, toàn bộ thư viện tiêu chuẩn đều có sẵn - đây là trong trình duyệt, đây là stdlib của Go, thứ mà chúng tôi yêu thích.
- Toàn bộ hệ sinh thái gói trong Go, tất cả các giải pháp của bên thứ ba (tạo khuôn mẫu, v.v.) đều có thể được biên dịch bằng GopherJS và chạy trong trình duyệt.
GopherJS rất dễ dàng có được - nó chỉ là một gói Go thông thường. Chúng tôi bắt đầu nhận và chúng tôi có lệnh GopherJS để xây dựng ứng dụng:
Đây quả là một thế giới xin chào nhỏ bé...
...Một chương trình Go thông thường, một gói fmt thư viện tiêu chuẩn thông thường và Binding Js để tiếp cận API trình duyệt. Println cuối cùng sẽ được chuyển đổi thành nhật ký bảng điều khiển và trình duyệt sẽ viết “Xin chào gophers”! Thật đơn giản: chúng tôi xây dựng GopherJS – chúng tôi khởi chạy nó trong trình duyệt – mọi thứ đều hoạt động!
Hiện tại bạn có gì? Ràng buộc
Có các ràng buộc cho tất cả các khung công tác js phổ biến:
- Truy vấn;
- Angular.js;
- D3.js để vẽ đồ thị và làm việc với dữ liệu lớn;
- React.js;
- VueJS;
- thậm chí còn có hỗ trợ cho Electron (nghĩa là chúng tôi đã có thể viết các ứng dụng máy tính để bàn trên Electron);
- và điều thú vị nhất là WebGL (chúng tôi có thể tạo ra các ứng dụng có đồ họa đầy đủ, bao gồm các trò chơi có đồ họa 3D, âm nhạc và tất cả các tính năng thú vị);
- và nhiều ràng buộc khác với tất cả các thư viện và khung javascript phổ biến.
Khung
- Có một khung web đã được phát triển riêng cho GopherJS - Vecty. Đây là một phiên bản tương tự hoàn toàn của React.js, nhưng chỉ được phát triển trong Go, với các đặc điểm cụ thể của GopherJS.
- Có túi trò chơi (ngạc nhiên chưa!). Tôi tìm thấy hai phổ biến nhất:
- Engo;
- Ebiten.
Tôi sẽ cho bạn xem một số ví dụ về giao diện của nó và những gì bạn có thể viết trong Go:
Hoặc tùy chọn này (tôi không thể tìm thấy game bắn súng 3D, nhưng có thể nó tồn tại):
Tôi đang cung cấp những gì?
Giờ đây, ngành công nghiệp front-end đang ở trong tình trạng mà tất cả các ngôn ngữ trước đây từng kêu gào từ Javascript sẽ đổ xô vào đó. Bây giờ mọi thứ sẽ được biên dịch thành “Web Assemblies”. Chúng ta cần làm gì để có được vị trí xứng đáng với tư cách là Gophers?
Theo truyền thống, Go thường cho rằng đó là ngôn ngữ lập trình Hệ thống và thực tế không có thư viện nào để làm việc với giao diện người dùng. Có một cái gì đó, nhưng nó một nửa bị bỏ rơi, một nửa không hoạt động.
Và bây giờ là cơ hội tốt để tạo các thư viện UI trong Go chạy trên GopherJS! Cuối cùng bạn có thể viết khuôn khổ của riêng bạn! Đây là lúc bạn có thể viết một framework và nó sẽ là một trong những framework đầu tiên được áp dụng sớm và bạn sẽ trở thành một ngôi sao (nếu đó là một framework tốt).
Bạn có thể điều chỉnh nhiều gói khác nhau đã có trong hệ sinh thái Go cho phù hợp với đặc điểm cụ thể của trình duyệt (ví dụ: Công cụ mẫu). Chúng sẽ hoạt động, bạn có thể tạo các ràng buộc thuận tiện để có thể dễ dàng hiển thị nội dung trực tiếp trong trình duyệt. Ngoài ra, chẳng hạn, bạn có thể tạo một dịch vụ có thể hiển thị cùng một thứ trên máy chủ và trên giao diện người dùng, sử dụng cùng một mã - mọi thứ mà các nhà phát triển giao diện người dùng yêu thích (chỉ có trong Go).
Bạn có thể viết một trò chơi! Chỉ để cho vui...
Đó là tất cả những gì tôi muốn nói.
câu hỏi
Câu hỏi (sau đây gọi tắt là Q): – Tôi viết bằng Go hay Js?
AG: – Bạn viết các quy trình, kênh, cấu trúc, nhúng – mọi thứ trong Go... Bạn đăng ký một sự kiện, chuyển một chức năng vào đó.
В: – Vậy tôi viết bằng chữ J “trần trụi” à?
AG: – Không, bạn viết như trong Go và kết nối với API trình duyệt (API không thay đổi). Bạn có thể viết các ràng buộc của riêng mình để gửi tin nhắn đến kênh - điều này không khó.
В: – Thế còn di động thì sao?
AG: – Tôi chắc chắn đã thấy: có các ràng buộc cho bản vá Cordova mà Js chạy. Trong React Native - Tôi không biết; có thể có, có thể không (tôi không đặc biệt quan tâm). Công cụ trò chơi N-go hỗ trợ cả ứng dụng di động - cả iOS và Android.
В: – Câu hỏi về Web Assembly. Ngày càng có nhiều không gian được chiếm dụng, bất chấp việc nén và “nén”... Chúng ta sẽ không giết chết thế giới front-end theo cách này nhiều hơn nữa sao?
AG: – Web Assembly là định dạng nhị phân và theo mặc định nhị phân không thể có nhiều hơn văn bản trong bản phát hành cuối cùng... Bạn bị cuốn hút vào thời gian chạy, nhưng điều này cũng giống như việc kéo thư viện Javascript tiêu chuẩn ra khi nó không có ở đó, vì vậy chúng tôi sử dụng một số Lodash. Tôi không biết Lodash cần bao nhiêu.
В: – Rõ ràng là ít hơn thời gian chạy…
AG: – Bằng Javascript “thuần túy”?
В: - Đúng. Chúng tôi nén nó trước khi gửi nó...
AG: – Nhưng đây là văn bản... Nói chung, một megabyte có vẻ rất nhiều, nhưng chỉ vậy thôi (bạn có toàn bộ thời gian chạy). Tiếp theo, bạn viết logic nghiệp vụ của riêng mình, điều này sẽ tăng hệ nhị phân của bạn lên 1%. Cho đến nay tôi không thấy điều này giết chết giao diện người dùng. Hơn nữa, Web Assembly sẽ hoạt động nhanh hơn Javascript vì lý do rõ ràng - nó không cần phải phân tích cú pháp.
В: – Đây vẫn còn là điểm gây tranh cãi… Hiện chưa có tài liệu tham khảo nào triển khai “Vasma” (Web Assembly) để có thể đánh giá rõ ràng. Về mặt khái niệm thì đúng: tất cả chúng ta đều hiểu rằng nhị phân sẽ nhanh hơn, nhưng việc triển khai cùng một động cơ V8 hiện tại là rất hiệu quả.
AG: - Đúng.
В: – Quá trình biên dịch ở đó hoạt động thực sự rất tuyệt vời và thực tế không phải là sẽ có lợi thế lớn.
AG: – Web Assembly cũng do các ông lớn làm.
В: – Với tôi, có vẻ vẫn còn khó để đánh giá Web Assembly. Đã có những cuộc đối thoại từ nhiều năm nay nhưng có rất ít thành tựu thực sự có thể cảm nhận được.
AG: - Có lẽ. Chúng ta sẽ thấy.
В: – Chúng tôi không gặp vấn đề gì ở phần phụ trợ... Có lẽ chúng ta nên để những vấn đề này ở phần frontend? Tại sao lại đến đó?
AG: – Chúng ta phải giữ được đội ngũ công nhân tiền tuyến.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com