Kiev Go Buluşması Mayıs 2018:
moderatör: - Herkese selam! Burada olduğun için teşekkür ederim! Bugün iki resmi konuşmacımız var: Lyosha ve Vanya. Yeterli zamanımız olursa iki tane daha olacak. İlk konuşmacımız Alexey Grachev, bize GopherJS'i anlatacak.
Alexey Grachev (bundan böyle - AG olarak anılacaktır): – Ben bir Go geliştiricisiyim ve Go'da web hizmetleri yazıyorum. Bazen ön uçla uğraşmanız gerekir, bazen de buna manuel olarak girmeniz gerekir. Ön uçta Go ile ilgili deneyimim ve araştırmalarımdan bahsetmek istiyorum.
Efsane şu: Önce neden Go'yu ön uçta çalıştırmak istediğimizden bahsedeceğiz, sonra bunun nasıl yapılabileceğinden bahsedeceğiz. İki yol vardır: Web Assembly ve GopherJS. Bakalım bu çözümlerin durumu nedir ve neler yapılabilir.
Ön uçta sorun ne?
Herkes ön uçta her şeyin yolunda olduğu konusunda hemfikir mi?
Yeterli test yok mu? Yavaş inşa mı? Ekosistem? İyi.
Ön uçla ilgili olarak, ön uç geliştiricilerinden birinin kitabında söylediği alıntıyı beğendim:
Javascript'in bir tip sistemi yoktur. Şimdi çalışmalarım sırasında karşılaştığım sorunları adlandıracağım ve bunların nasıl çözüldüğünü anlatacağım.
Genel olarak tip sistemine Javasript'te bir tip sistemi denemez - nesnenin tipini gösteren satırlar vardır, ancak aslında bunun türlerle hiçbir ilgisi yoktur. Bu sorun TypeScript'te (Javasript'e bir eklenti) ve Flow'da (Javascript'te statik tip denetleyicisi) çözülmüştür. Aslında ön uç, Javascript'teki kötü tip sistem sorununu çözme noktasına çoktan ulaştı.
Tarayıcıda standart bir kitaplık yoktur - tarayıcılarda bazı yerleşik nesneler ve "sihirli" işlevler vardır. Ancak Javascript'te böyle bir standart kütüphane yoktur. Bu sorun jQuery tarafından bir kez çözülmüştü (herkes çalışması gereken tüm prototipler, yardımcılar ve işlevlerle birlikte jQuery'yi kullanıyordu). Artık herkes Lodash kullanıyor:
Geri arama cehennemi. Sanırım herkes Javascript kodunu yaklaşık 5 yıl önce gördü ve inanılmaz karmaşık geri aramalardan oluşan bir "şehriye" gibi görünüyordu. Artık bu sorun çözüldü (ES-15 veya ES-16'nın yayınlanmasıyla), Javascript'e sözler eklendi ve herkes bir süreliğine daha rahat nefes alabilecek.
Promice cehennemi gelene kadar... Ön uç sektörünün nasıl idare ettiğini bilmiyorum ama kendilerini her zaman tuhaf bir ormana sürüklüyorlar. Biz de vaatleri cehenneme çevirmeyi başardık. Daha sonra bu sorunu yeni bir ilkel - async/await ekleyerek çözdük:
Asenkron sorun çözüldü. Async/await, çeşitli dillerde oldukça popüler bir ilkeldir. Python ve diğerlerinin bu yaklaşımı var; oldukça iyi. Sorun çözüldü.
Hangi sorun çözülmedi? Çerçevelerin katlanarak artan karmaşıklığı, ekosistemin ve programların karmaşıklığı.
- Javascript sözdizimi biraz garip. Hepimiz bir dizi, bir nesne ve diğer şakaları eklemeyle ilgili sorunları biliyoruz.
- Javascript çoklu paradigmadır. Ekosistemin çok büyük olduğu günümüzde bu özellikle acil bir sistemdir:
- herkes farklı tarzlarda yazıyor - bazıları yapısal olarak yazıyor, bazıları işlevsel olarak yazıyor, farklı geliştiriciler farklı yazıyor;
- farklı paketlerden, farklı paketler kullandığınızda farklı paradigmalardan;
- Javasript'te işlevsel programlamanın pek çok "eğlenceli" yanı var - rambda kütüphanesi ortaya çıktı ve artık hiç kimse bu kütüphanede yazılan programları okuyamıyor.
- Bütün bunlar ekosistem üzerinde büyük bir etki yarattı ve ekosistem inanılmaz derecede büyüdü. Paketler birbirleriyle uyumsuz: bazıları vaatlere dayanıyor, bazıları eşzamansız/beklemede, bazıları geri aramalara dayanıyor. Ayrıca farklı paradigmalarla yazıyorlar!
- Bu da projenin sürdürülmesini zorlaştırıyor. Kodu okuyamıyorsanız bir hata bulmak zordur.
Web Montajı Nedir?
Mozilla Vakfı'nın ve diğer bazı şirketlerin cesur adamları Web Montajı gibi bir şey buldular. Bu nedir?
- Bu, tarayıcıya yerleşik, ikili biçimi destekleyen bir sanal makinedir.
- İkili programlar oraya ulaşır ve neredeyse yerel olarak yürütülür, yani tarayıcının her seferinde javascript kodunun tüm "eriştelerini" ayrıştırmasına gerek yoktur.
- Tüm tarayıcılar destek bildirdi.
- Bu bayt kodu olduğundan herhangi bir dil için derleyici yazabilirsiniz.
- Dört büyük tarayıcı zaten Web Assembly desteğiyle birlikte geliyor.
- Yakında Go'da yerel destek bekliyoruz. Bu yeni mimari zaten eklendi: GOARCH=wasm GOOS=js (yakında). Şu ana kadar anladığım kadarıyla işlevsel değil ama Go'da mutlaka olacağına dair bir açıklama var.
Şimdi ne yapmalı? GopherJS
Web Assembly desteğimiz olmasa da GopherJS gibi bir aktarıcı var.
- Go kodu "saf" Javascript'e aktarılır.
- Tüm tarayıcılarda çalışır - yalnızca modern tarayıcılar tarafından desteklenen yeni özellikler yoktur (bu, her şeyde çalışan Vanilla JS'dir).
- Goroutinler ve kanallar da dahil olmak üzere Go'nun sahip olduğu hemen hemen her şey için destek var... sevdiğimiz ve çok bildiğimiz her şey.
- Tarayıcıda desteklemenin bir anlamı olmayan paketler dışında neredeyse tüm standart kitaplık desteklenir: sistem çağrısı, ağ etkileşimleri (bir net/http istemcisi vardır, ancak sunucu yoktur ve istemci XMLHttpRequest aracılığıyla öykünülür). Genel olarak, standart kütüphanenin tamamı mevcuttur - işte tarayıcıda, işte Go'nun sevdiğimiz stdlib'i.
- Go'daki tüm paket ekosistemi, tüm üçüncü taraf çözümler (şablon oluşturma vb.) GopherJS kullanılarak derlenebilir ve tarayıcıda çalıştırılabilir.
GopherJS'i edinmek çok kolaydır; yalnızca normal bir Go paketidir. Gidip alıyoruz ve uygulamayı oluşturmak için bir GopherJS komutumuz var:
Bu çok küçük bir merhaba dünya...
...Normal bir Go programı, normal bir standart kütüphane fmt paketi ve tarayıcı API'sine ulaşmak için Binding J'ler. Println sonunda konsol günlüğüne dönüştürülecek ve tarayıcı "Merhaba gophers" yazacak! Bu kadar basit: GopherJS'i oluşturuyoruz - onu tarayıcıda başlatıyoruz - her şey çalışıyor!
Şu anda elinizde ne var? bağlamalar
Tüm popüler js çerçeveleri için bağlamalar vardır:
- JQuery;
- Angular.js;
- Büyük verilerle çizim yapmak ve çalışmak için D3.js;
- React.js;
- VueJS;
- Electron desteği bile var (yani, Electron'a zaten masaüstü uygulamaları yazabiliyoruz);
- ve en komik şey WebGL'dir (3D grafikli oyunlar, müzik ve tüm güzellikler dahil olmak üzere tam grafik uygulamalar yapabiliriz);
- ve tüm popüler javascript çerçeveleri ve kitaplıklarına yönelik diğer birçok bağlantı.
iskelet
- GopherJS - Vecty için özel olarak geliştirilmiş bir web çerçevesi zaten var. Bu, React.js'nin tam teşekküllü bir analogudur, ancak GopherJS'nin özellikleriyle yalnızca Go'da geliştirilmiştir.
- Oyun çantaları var (sürpriz!). En popüler ikisini buldum:
- Engo;
- Ebiten.
Size neye benzediğine ve Go'da zaten neler yazabileceğinize dair birkaç örnek göstereceğim:
Veya bu seçenek (3D tetikçi bulamadım ama belki vardır):
Ne sunuyorum?
Artık ön uç endüstrisi öyle bir durumda ki, daha önce Javascript'ten ağlayan tüm diller oraya akın edecek. Artık her şey “Web Montajları” halinde derlenecek. Gophers olarak orada hak ettiğimiz yeri almak için neye ihtiyacımız var?
Go, geleneksel olarak bunun bir Sistem programlama dili olduğunu varsayar ve kullanıcı arayüzüyle çalışmak için pratikte hiçbir kitaplık yoktur. Bir şey var ama yarısı terk edilmiş, yarısı işlevsiz.
Ve şimdi Go'da GopherJS üzerinde çalışacak kullanıcı arayüzü kitaplıkları oluşturmak için iyi bir şans! Sonunda kendi çerçevenizi yazabilirsiniz! Bu, bir çerçeve yazabileceğiniz zamandır ve bu ilklerden biri olacak ve erken benimsenecek ve bir yıldız olacaksınız (eğer iyi bir çerçeve ise).
Zaten Go ekosisteminde bulunan birçok farklı paketi tarayıcının özelliklerine (örneğin Şablon motoru) uyarlayabilirsiniz. Zaten çalışacaklar, içeriği doğrudan tarayıcıda kolayca oluşturabilmeniz için uygun bağlamalar yapabilirsiniz. Ayrıca, örneğin, aynı kodu kullanarak sunucuda ve ön uçta aynı şeyi (ön uç geliştiricilerin beğendiği her şeyi) (yalnızca şimdi Go'da) işleyebilen bir hizmet oluşturabilirsiniz.
Bir oyun yazabilirsin! Sadece eğlence için…
Bende her şey var.
sorular
Soru (bundan sonra Q olarak anılacaktır): – Go ile mi yoksa Js ile mi yazacağım?
AG: – Rutinleri, kanalları, yapıları, yerleştirmeleri – Go'da her şeyi yazarsınız... Bir etkinliğe abone olursunuz, orada bir işlev iletirsiniz.
In: – Yani “çıplak” J'lerle mi yazıyorum?
AG: – Hayır, Go’daymış gibi yazıp tarayıcı API’sine bağlanıyorsunuz (API değişmedi). Mesajların kanala gönderilmesi için kendi bağlamalarınızı yazabilirsiniz - bu zor değil.
In: – Peki ya mobil?
AG: – Kesinlikle şunu gördüm: Js'nin çalıştırdığı Cordova yaması için bağlamalar var. React Native'de - bilmiyorum; belki vardır, belki yoktur (özellikle ilgilenmiyordum). N-go oyun motoru hem iOS hem de Android mobil uygulamalarını destekler.
In: – Web Montajı hakkında soru. Sıkıştırmaya ve "sıkıştırmaya" rağmen giderek daha fazla yer kaplanıyor... Ön uç dünyayı bu şekilde daha da fazla öldürmeyecek miyiz?
AG: – Web Assembly ikili bir formattır ve ikili, varsayılan olarak son sürümde metinden daha fazla olamaz... Çalışma zamanına çekilirsiniz, ancak bu, standart Javascript kitaplığını orada olmadığında sürüklemekle aynıdır, bu yüzden biz biraz Lodash kullan. Lodash'ın ne kadar aldığını bilmiyorum.
In: – Açıkçası çalışma süresinden daha az...
AG: – “Saf” Javascript'te mi?
In: - Evet. Göndermeden önce sıkıştırıyoruz...
AG: – Ama bu bir metin... Genel olarak, bir megabayt çok gibi görünebilir, ancak hepsi bu (çalışma zamanının tamamına sahipsiniz). Daha sonra, ikili dosyanızı %1 artıracak kendi iş mantığınızı yazarsınız. Şimdiye kadar bunun ön ucu öldürdüğünü görmüyorum. Üstelik Web Assembly'nin Javascript'ten daha hızlı çalışabilmesinin bariz bir nedeni var; ayrıştırılmasına gerek yok.
In: – Bu hala tartışmalı bir nokta... “Vasma”nın (Web Assembly) kesin olarak yargılanabilecek herhangi bir referans uygulaması henüz yok. Kavramsal olarak evet: hepimiz ikili sistemin daha hızlı olması gerektiğini anlıyoruz, ancak aynı V8'in mevcut uygulaması çok verimli.
AG: - Evet.
In: – Orada derleme gerçekten çok harika çalışıyor ve büyük bir avantaj olacağı da bir gerçek değil.
AG: – Web Assembly da büyük adamlar tarafından yapılıyor.
In: – Bana öyle geliyor ki Web Assembly'yi yargılamak hala zor. Uzun yıllardan beri tartışmalar sürüyor, ancak hissedilebilecek çok az gerçek başarı var.
AG: - Belki. Göreceğiz.
In: – Arka uçta sorun yaşamıyoruz… Belki de bu sorunları ön uçta bırakmalıyız? Neden oraya gidelim?
AG: – Ön saflarda çalışanlardan oluşan bir kadro bulundurmalıyız.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com