ალექსეი გრაჩოვი: წადი Frontend

კიევის წინ შეხვედრა 2018 წლის მაისი:

მოდერატორი: - Სალამი ყველას! გმადლობთ აქ ყოფნისთვის! დღეს ჩვენ გვყავს ორი ოფიციალური მომხსენებელი - ლიოშა და ვანია. კიდევ ორი ​​იქნება თუ დრო გვექნება. პირველი მომხსენებელია ალექსეი გრაჩევი, ის მოგვითხრობს GopherJS-ის შესახებ.

ალექსეი გრაჩევი (შემდგომში - AG): – მე ვარ Go დეველოპერი და ვწერ ვებ სერვისებს Go-ში. ხან ფრონტენტთან გიწევს საქმე, ხან სახელურებით იქ ასვლა. მინდა ვისაუბრო ჩემს გამოცდილებასა და კვლევაზე Go on frontend-ზე.

ლეგენდა ასეთია: ჯერ ვისაუბრებთ იმაზე, თუ რატომ გვინდა Go-ს გაშვება წინა პლანზე, შემდეგ ვისაუბრებთ იმაზე, თუ როგორ შეგვიძლია ამის გაკეთება. არსებობს ორი გზა - ვებ ასამბლეა და GopherJS. ვნახოთ, რა მდგომარეობაშია ეს გადაწყვეტილებები და რა შეიძლება გაკეთდეს.

რა სჭირს frontend?

ყველა ეთანხმება, რომ ფრონტენტთან ყველაფერი კარგადაა?

რამდენიმე ტესტი? ნელი აშენება? ეკოსისტემა? ჯარიმა.

რაც შეეხება ფრონტ-ენდს, მომწონს ციტატა, რომელიც ერთ-ერთმა წინა დეველოპერმა თქვა თავის წიგნში:

Javascript არ აქვს ტიპის სისტემა. ახლა დავასახელებ იმ პრობლემებს, რომლებიც შემხვედრია ჩემი მუშაობის პროცესში და ავხსნი, როგორ გვარდება ისინი.

ტიპის სისტემა ზოგადად რთულია Javascript-ში ტიპის სისტემის გამოძახება - არის ხაზები, რომლებიც მიუთითებენ ობიექტის ტიპზე, მაგრამ სინამდვილეში ამას არანაირი კავშირი არ აქვს ტიპებთან. ეს პრობლემა მოგვარებულია TypeScript-ში (Javascript-ის დანამატი) და Flow-ში (Javascript-ის ტიპების სტატიკური შემოწმება). სინამდვილეში, ფრონტენტი უკვე წავიდა იქამდე, სანამ გადაჭრის ცუდი ტიპის სისტემის პრობლემას Javascript-ში.

ბრაუზერში, როგორც ასეთი, არ არსებობს სტანდარტული ბიბლიოთეკა - ბრაუზერებში არის ჩაშენებული ობიექტები და "ჯადოსნური" ფუნქციები. მაგრამ მე არ მაქვს სტანდარტული ბიბლიოთეკა Javascript-ში, როგორც ასეთი. ეს პრობლემა უკვე მოგვარებულია jQuery-ის მიერ (ყველა იყენებდა jQuery-ს ყველა პროტოტიპით, დამხმარეებით, ფუნქციებით, რომლებიც საჭირო იყო სამუშაოდ). ახლა ყველა იყენებს Lodash-ს:

გამოძახება ჯოჯოხეთი. მე ვფიქრობ, რომ ყველამ დაინახა Javascript კოდი დაახლოებით 5 წლის წინ და ის გამოიყურებოდა როგორც "noodle" გამოძახების წარმოუდგენელი სირთულეებიდან. ახლა ეს პრობლემა მოგვარებულია (ES-15-ის ან ES-16-ის გამოშვებით), ჯავასკრიპტს დაემატა დაპირებები და ყველამ ცოტა ხნით უფრო ადვილად სუნთქვა დაიწყო.

სანამ Promise ჯოჯოხეთი არ მოვიდა... არ ვიცი, როგორ ახერხებს ფრონტ-ენდის ინდუსტრია, მაგრამ ისინი ყოველთვის თავს ატარებენ რაღაც უცნაურ ჯუნგლებში. ჩვენ ასევე მოვახერხეთ "დაპირებების" ჯოჯოხეთი. შემდეგ ჩვენ გადავწყვიტეთ ეს პრობლემა ახალი პრიმიტივის დამატებით - async / await:

ასინქრონულობით პრობლემა მოგვარებულია. Async/wait საკმაოდ პოპულარული პრიმიტივია სხვადასხვა ენაში. Python-ს და სხვებს აქვთ ეს მიდგომა - ეს საკმარისად კარგია. პრობლემა მოგვარებულია.

რა პრობლემა არ მოგვარდება? ჩარჩოების ექსპონენტურად მზარდი სირთულე, ეკოსისტემის სირთულე და თავად პროგრამები.

• Javascript-ის სინტაქსი ცოტა უცნაურია. ჩვენ ყველამ ვიცით მასივის და ობიექტის დამატების პრობლემები და სხვა ხრიკები.
• Javascript არის მრავალ პარადიგმა. ახლა ეს განსაკუთრებით აქტუალური სისტემაა, როდესაც ეკოსისტემა ძალიან დიდია:
  • ყველა წერს სხვადასხვა სტილში - ვიღაც წერს სტრუქტურულად, ვიღაც წერს ფუნქციურად, სხვადასხვა დეველოპერები განსხვავებულად წერენ;
  • სხვადასხვა პაკეტებიდან (პაკეტებიდან) სხვადასხვა პარადიგმები სხვადასხვა პაკეტების გამოყენებისას;
  • ბევრი "გართობა" Javascript-ში ფუნქციონალური პროგრამირებით - გამოჩნდა rambda ბიბლიოთეკა და ახლა ამ ბიბლიოთეკაში დაწერილ პროგრამებს ვერავინ კითხულობს.

• ეს ყველაფერი დიდ გავლენას ახდენს ეკოსისტემაზე და ის წარმოუდგენლად გაიზარდა. პაკეტები ერთმანეთთან შეუთავსებელია: ზოგი დაპირებაზეა, ზოგი async/ლოდინზეა, ზოგიც უკურეკვაზე. ისინიც სხვადასხვა პარადიგმებში წერენ!
• ეს ართულებს პროექტის შენარჩუნებას. ძნელია ხარვეზის პოვნა, თუ კოდს ვერ კითხულობ.

რა არის ვებ ასამბლეა?

მამაცი ბიჭები Mozilla Foundation-დან და რიგი სხვა კომპანიებიდან გამოვიდნენ ისეთი რამ, როგორიცაა Web Assembly. Ეს რა არის?

• ეს არის ბრაუზერში ჩაშენებული ვირტუალური მანქანა, რომელიც მხარს უჭერს ორობით ფორმატს.
• ბინარული პროგრამები იქ მიდის, ისინი შესრულებულია თითქმის ბუნებრივად, ანუ ბრაუზერს არ სჭირდება ყოველ ჯერზე javascript კოდის ყველა "noodles"-ის გაანალიზება.
• ყველა ბრაუზერმა გამოაცხადა მხარდაჭერა.
• ვინაიდან ეს არის ბაიტიკოდი, შეგიძლიათ დაწეროთ შემდგენელი ნებისმიერი ენისთვის.
• ოთხი ძირითადი ბრაუზერი უკვე იგზავნება ვებ ასამბლეის მხარდაჭერით.
• მალე გოში ველოდებით ადგილობრივ მხარდაჭერას. ეს ახალი არქიტექტურა უკვე დამატებულია: GOARCH=wasm GOOS=js (მალე). ჯერჯერობით, როგორც მივხვდი, არ არის ფუნქციონალური, მაგრამ არის განცხადება, რომ აუცილებლად იქნება გოში.

Რა უნდა გავაკეთოთ ახლა? GopherJS

მიუხედავად იმისა, რომ ჩვენ არ გვაქვს ვებ ასამბლეის მხარდაჭერა, არსებობს გადამყვანი, როგორიცაა GopherJS.

• Go კოდი გადაყვანილია "სუფთა" Javascript-ში.
• მუშაობს ყველა ბრაუზერში - არ არის ახალი ფუნქციები, რომლებსაც მხოლოდ თანამედროვე ბრაუზერები უჭერენ მხარს (ეს არის Vanilla JS, რომელიც მუშაობს ნებისმიერზე).
• არსებობს მხარდაჭერა თითქმის ყველაფრისთვის, რაც არის Go-ში, მათ შორის გორუტინებსა და არხებზე... - ყველაფერი, რაც ძალიან გვიყვარს და ვიცით.
• თითქმის მთელი სტანდარტული ბიბლიოთეკა მხარდაჭერილია, გარდა იმ პაკეტებისა, რომელთა მხარდაჭერასაც აზრი არ აქვს ბრაუზერში: syscall, net ურთიერთქმედება (არსებობს net/http კლიენტი, მაგრამ არა სერვერი და კლიენტი ემულირებულია XMLHttpRequest-ის საშუალებით) . ზოგადად, მთელი სტანდარტული ბიბლიოთეკა ხელმისაწვდომია - აქ არის ის ბრაუზერში, აქ არის Go stdlib, რომელიც ჩვენ გვიყვარს.
• მთელი პაკეტის ეკოსისტემა Go-ში, ყველა მესამე მხარის გადაწყვეტილებები (თარგი და ა.შ.) შეიძლება შედგეს GopherJS-ით და გაუშვათ ბრაუზერში.

GopherJS-ის მიღება ძალიან მარტივია - ეს მხოლოდ ჩვეულებრივი Go პაკეტია. ჩვენ ვაკეთებთ გადასვლას და გვაქვს GopherJS ბრძანება აპლიკაციის შესაქმნელად:

აქ არის ასეთი პატარა გამარჯობა სამყარო ...

... რეგულარული Go პროგრამა, სტანდარტული ბიბლიოთეკის რეგულარული fmt პაკეტი და Binding Js ბრაუზერის API-მდე მისასვლელად. Println საბოლოოდ გარდაიქმნება კონსოლის ჟურნალად და ბრაუზერი დაწერს "Hello gophers"! ეს ძალიან მარტივია: ჩვენ ვაკეთებთ GopherJS build-ს - ჩვენ მას ბრაუზერში გავუშვით - ყველაფერი მუშაობს!

რა არის ამ მომენტში? საკინძები

არსებობს სავალდებულო ყველა პოპულარული js ჩარჩოსთვის:

• jquery;
• კუთხოვანი.js
• D3.js დიდი მონაცემების შედგენისა და მუშაობისთვის;
• React.js
• VueJS;
• არის ელექტრონის მხარდაჭერაც კი (ანუ უკვე შეგვიძლია ელექტრონზე დესკტოპის აპლიკაციების დაწერა);
• და ყველაზე სასაცილო არის WebGL (ჩვენ შეგვიძლია შევქმნათ სრული გრაფიკული აპლიკაციები, მათ შორის თამაშები 3D გრაფიკით, მუსიკით და ყველა სიკეთით);
• და ბევრი სხვა კავშირი ყველა პოპულარულ javascript ჩარჩოებსა და ბიბლიოთეკებთან.

ჩარჩო

1. არსებობს ვებ ჩარჩო უკვე შემუშავებული სპეციალურად GopherJS - Vecty-სთვის. ეს არის React.js-ის სრულფასოვანი ანალოგი, მაგრამ განვითარებულია მხოლოდ Go-ში, GopherJS-ის სპეციფიკით.
2. არის თამაშის ჩანთები (უცებ!). მე ვიპოვე ორი ყველაზე პოპულარული:
   • ენგო;
   • ებიტენი.

მე გაჩვენებთ რამდენიმე მაგალითს, თუ როგორ გამოიყურება და რა შეიძლება უკვე ჩაიწეროს Go-ში:

ან ეს ვარიანტი (მე ვერ ვიპოვე 3D მსროლელი, მაგრამ შესაძლოა ის არსებობს):

რას ვთავაზობ?

ახლა ფრონტ-ენდის ინდუსტრია ისეთ მდგომარეობაშია, რომ ყველა ენა, რომელიც ადრე Javascript-დან ტიროდა, იქ ჩქარობს. ახლა ყველაფერი შედგენილი იქნება "ვებ ასამბლეებში". რა გვჭირდება იქ ღირსეული ადგილი დავიკავოთ, როგორც „გოფერებმა“?

Go-ში ტრადიციულად წავიდა, რომ ეს არის სისტემის პროგრამირების ენა და პრაქტიკულად არ არსებობს ბიბლიოთეკები UI-სთან მუშაობისთვის. არის რაღაც, მაგრამ ნახევრად მიტოვებული, ნახევრად უფუნქციო.

ახლა კი - კარგი შანსია შექმნათ UI ბიბლიოთეკები Go-ში, რომლებიც იმუშავებს GopherJS-ზე! თქვენ საბოლოოდ შეგიძლიათ დაწეროთ თქვენი საკუთარი ჩარჩო! დადგა დრო, როცა შეგიძლია დაწერო ფრეიმერი და ის იქნება ერთ-ერთი პირველი და ადრე მიიღება, და იქნები ვარსკვლავი (თუ კარგი ფრეიმორია).

თქვენ შეგიძლიათ შეცვალოთ ბევრი სხვადასხვა პაკეტი, რომელიც უკვე არსებობს Go-ის ეკოსისტემაში, ბრაუზერის სპეციფიკასთან (მაგალითად, Template engine). ისინი უკვე იმუშავებენ, შეგიძლიათ მოაწყოთ მოსახერხებელი საკინძები, რათა მარტივად შეძლოთ შინაარსის გადაცემა პირდაპირ ბრაუზერში. გარდა ამისა, შეგიძლიათ შექმნათ, მაგალითად, სერვისი, რომელსაც შეუძლია ერთი და იგივეს გადაცემა სერვერზე და ფრონტზე, იგივე კოდის გამოყენებით - ყველაფერი, რაც მოსწონთ წინა დეველოპერებს (მხოლოდ ახლა Go-ზე).

შეგიძლიათ დაწეროთ თამაში! Გასართობად…

სულ ეს იყო რისი თქმაც მინდოდა.

კითხვები

კითხვა (შემდგომში Q): – მე ვწერ Go-ში თუ Js-ში?

AG: – თქვენ წერთ რუტინებს, არხებს, სტრუქტურებს, ჩანერგვას – ყველაფერს Go-ში… იწერთ ღონისძიებას, ატარებთ იქ ფუნქციას.

In: - ანუ "შიშველ" ჯ-ებზე ვწერ?

AG: - არა, Go-ში ისე წერ და უერთდები ბრაუზერის API-ს (API არ შეცვლილა). თქვენ შეგიძლიათ დაწეროთ საკუთარი საკინძები ისე, რომ შეტყობინებები მოვიდეს არხზე - ეს არ არის რთული.

In: - რაც შეეხება მობილურს?

AG: - მე ნამდვილად ვნახე: არის ბაინდერები Cordova პაჩისთვის, რომელსაც Js უშვებს. React Native-ში, არ ვიცი; შეიძლება არის, შეიძლება არა (განსაკუთრებით არ მაინტერესებს). N-go თამაშის ძრავა მხარს უჭერს ორივე მობილურ აპლიკაციას - iOS და Android.

In: – შეკითხვა ვებ ასამბლეის შესახებ. სულ უფრო და უფრო მეტი ადგილი იკავებს, მიუხედავად ლაკონურობის, „ზიპის“... ამ გზით უფრო მეტად ხომ არ მოვკლავთ ფრონტენტის სამყაროს?

AG: - ვებ ასამბლეა არის ორობითი ფორმატი და ნაგულისხმევი ორობითი არ შეიძლება იყოს ტექსტზე მეტი საბოლოო გამოშვებაში... თქვენ იზიდავთ Runtime-ით, მაგრამ ეს იგივეა, რაც Javascript-ის სტანდარტულ ბიბლიოთეკაში გაყვანა, როდესაც ის იქ არ არის, ამიტომ ჩვენ გამოიყენეთ რამდენიმე Lodash. არ ვიცი, რამდენი დრო სჭირდება ლოდაშს.

In: - აშკარად ნაკლებია ვიდრე გაშვება ...

AG: - "სუფთა" Javascript-ზე?

In: - დიახ. ჩვენ შევკუმშავთ მას გაგზავნამდე...

AG: - მაგრამ ეს არის ტექსტი... ზოგადად, მეგაბაიტი ბევრს ჰგავს, მაგრამ ეს ყველაფერია (თქვენ გაქვთ მთელი გაშვების დრო). შემდეგი, თქვენ დაწერეთ თქვენი საკუთარი ბიზნეს ლოგიკა, რომელიც გაზრდის თქვენს ბინარს 1%-ით. ჯერჯერობით მე ვერ ვხედავ, რომ ეს კლავს წინა მხარეს. უფრო მეტიც, ვებ ასამბლეა იმუშავებს უფრო სწრაფად, ვიდრე Javascript გასაგები მიზეზის გამო - მას არ სჭირდება ანალიზი.

In: - ჯერჯერობით საკამათო პუნქტი... „ვასმას“ (ვებ ასამბლეის) საცნობარო იმპლემენტაცია ჯერ კიდევ არ არის, რომ ცალსახად ვიმსჯელოთ. კონცეპტუალურად, დიახ: ჩვენ ყველას გვესმის, რომ ორობითი უნდა იყოს უფრო სწრაფი, მაგრამ იგივე V8-ის მიმდინარე განხორციელება ძალიან ეფექტურია.

AG: - დიახ.

In: - იქ შედგენა მართლაც ძალიან მაგრად მუშაობს და ფაქტი არ არის, რომ დიდი უპირატესობა იქნება.

AG: - ვებ ასამბლეასაც დიდი ბიჭები აკეთებენ.

In: - ჯერჯერობით, მეჩვენება, მაინც რთულია ვებ ასამბლეის განსჯა. მრავალი წლის განმავლობაში იყო მოლაპარაკებები, მაგრამ არის რამდენიმე რეალური მიღწევა, რომელიც შეიძლება იგრძნოს.

AG: - Შესაძლოა. Მოდი ვნახოთ.

In: – ჩვენ არ გვაქვს პრობლემები ბექენდზე... იქნებ ეს პრობლემები წინა პლანზე დავტოვოთ? რატომ უნდა წავიდეთ იქ?

AG: - ჩვენ უნდა შევინარჩუნოთ ფრონტის შტაბი.

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com