Alexey Grachev: 프론트엔드로 이동

2018년 XNUMX월 Kyiv Go 모임:

진행자 : - 안녕하세요 여러분! 여기 있어주셔서 감사합니다! 오늘 우리는 Lyosha와 Vanya라는 두 명의 공식 연사를 모셨습니다. 시간이 충분하다면 두 개 더 있을 거예요. 첫 번째 발표자는 Alexey Grachev입니다. 그는 GopherJS에 대해 설명할 것입니다.

Alexey Grachev(이하 – AG): – 저는 Go 개발자이고 Go로 웹 서비스를 작성합니다. 프런트엔드를 처리해야 할 때도 있고, 수동으로 들어가야 할 때도 있습니다. 저는 프론트엔드에서 Go에 대한 저의 경험과 연구에 대해 이야기하고 싶습니다.

전설은 이렇습니다. 먼저 Go를 프론트엔드에서 실행하려는 이유에 대해 이야기한 다음 이를 수행하는 방법에 대해 이야기하겠습니다. Web Assembly와 GopherJS의 두 가지 방법이 있습니다. 이러한 솔루션의 상태는 무엇이며 무엇을 할 수 있는지 살펴보겠습니다.

프론트엔드에 무슨 문제가 있나요?

모두가 프런트엔드에 문제가 없다는 데 동의합니까?

테스트가 충분하지 않습니까? 느린 빌드? 생태계? 괜찮은.

프론트엔드에 관해 나는 프론트엔드 개발자 중 한 명이 그의 책에서 말한 다음과 같은 인용문을 좋아합니다.

Javascript에는 유형 시스템이 없습니다. 이제 작업 과정에서 직면한 문제를 언급하고 해결 방법을 설명하겠습니다.

일반적으로 유형 시스템은 Javasript에서 유형 시스템이라고 할 수 없습니다. 객체 유형을 나타내는 줄이 있지만 실제로 이것은 유형과 관련이 없습니다. 이 문제는 TypeScript(Javasript의 추가 기능) 및 Flow(Javascript의 정적 유형 검사기)에서 해결되었습니다. 실제로 프론트엔드는 이미 Javascript의 잘못된 유형 시스템 문제를 해결하는 지점에 도달했습니다.

브라우저에는 표준 라이브러리가 없습니다. 브라우저에는 몇 가지 내장 개체와 "마법" 기능이 있습니다. 그러나 Javascript에는 표준 라이브러리가 없습니다. 이 문제는 이미 jQuery에 의해 해결되었습니다(모두가 작업에 필요한 모든 프로토타입, 도우미, 함수와 함께 jQuery를 사용했습니다). 이제 모두가 Lodash를 사용합니다.

콜백 지옥. 내 생각에 모든 사람들이 약 5년 전에 Javascript 코드를 본 것 같습니다. 그리고 그것은 콜백의 믿을 수 없을 정도로 복잡한 "국수"처럼 보였습니다. 이제 이 문제는 해결되었으며(ES-15 또는 ES-16 출시로) Javascript에 Promise가 추가되어 모든 사람이 잠시 더 쉽게 숨을 쉴 수 있게 되었습니다.

Promice 지옥이 도래할 때까지... 프론트엔드 산업이 어떻게 운영되는지는 모르겠지만, 그들은 항상 이상한 정글 속으로 스스로를 몰고 다닙니다. 우리는 또한 약속을 지켰습니다. 그런 다음 새로운 기본 요소인 async/await를 추가하여 이 문제를 해결했습니다.

비동기 문제가 해결되었습니다. Async/await는 다양한 언어에서 꽤 널리 사용되는 기본 요소입니다. Python과 다른 사람들은 이런 접근 방식을 가지고 있습니다. 꽤 좋습니다. 문제 해결됨.

어떤 문제가 해결되지 않았나요? 프레임워크의 복잡성, 생태계 및 프로그램 자체의 복잡성이 기하급수적으로 증가하고 있습니다.

• 자바스크립트 구문이 좀 이상합니다. 우리 모두는 배열과 객체 및 기타 농담을 추가할 때의 문제를 알고 있습니다.
• 자바스크립트는 멀티 패러다임입니다. 이는 생태계가 매우 큰 현재 특히 시급한 시스템입니다.
  • 모든 사람은 서로 다른 스타일로 글을 씁니다. 일부는 구조적으로 작성하고, 일부는 기능적으로 작성하며, 개발자마다 서로 다른 방식으로 작성합니다.
  • 다른 패키지에서, 다른 패키지를 사용할 때 다른 패러다임;
  • Javasript에는 함수형 프로그래밍에 많은 "재미"가 있습니다. Rambda 라이브러리가 등장했고 이제 누구도 이 라이브러리에 작성된 프로그램을 읽을 수 없습니다.

• 이 모든 것이 생태계에 큰 영향을 미치며 엄청나게 성장했습니다. 패키지는 서로 호환되지 않습니다. 일부는 Promise를 기반으로 하고 일부는 async/await를 기반으로 하며 일부는 콜백을 기반으로 합니다. 그들은 또한 다른 패러다임으로 글을 씁니다!
• 이로 인해 프로젝트를 유지 관리하기가 어려워집니다. 코드를 읽을 수 없으면 버그를 찾기가 어렵습니다.

웹 어셈블리란 무엇입니까?

Mozilla 재단과 다른 여러 회사의 용감한 사람들이 웹 어셈블리와 같은 것을 생각해냈습니다. 이게 뭔가요?

• 이는 바이너리 형식을 지원하는 브라우저에 내장된 가상 머신입니다.
• 바이너리 프로그램이 도착하여 거의 기본적으로 실행됩니다. 즉, 브라우저는 매번 자바스크립트 코드의 모든 "요소"를 구문 분석할 필요가 없습니다.
• 모든 브라우저가 지원을 선언했습니다.
• 이는 바이트코드이므로 모든 언어에 대한 컴파일러를 작성할 수 있습니다.
• XNUMX개의 주요 브라우저에는 이미 웹 어셈블리 지원이 포함되어 있습니다.
• 우리는 곧 Go에서 기본 지원을 기대하고 있습니다. 이 새로운 아키텍처는 이미 추가되었습니다: GOARCH=wasm GOOS=js(곧). 지금까지 제가 이해한 바로는 기능적이지는 않지만 Go에는 반드시 포함될 것이라는 진술이 있습니다.

이제 무엇을 해야 할까요? 고퍼JS

웹 어셈블리는 지원되지 않지만 GopherJS와 같은 트랜스파일러는 있습니다.

• Go 코드는 "순수한" Javascript로 변환됩니다.
• 모든 브라우저에서 실행됩니다. 최신 브라우저에서만 지원되는 새로운 기능은 없습니다(이것은 모든 브라우저에서 실행되는 Vanilla JS입니다).
• 고루틴과 채널을 포함하여 Go가 가지고 있는 거의 모든 것에 대한 지원이 있습니다. 우리가 너무나 사랑하고 알고 있는 모든 것입니다.
• 브라우저에서 지원하는 것이 타당하지 않은 패키지인 syscall, net 상호 작용(net/http 클라이언트는 있지만 서버는 없고 클라이언트는 XMLHttpRequest를 통해 에뮬레이션됨)을 제외하고 거의 전체 표준 라이브러리가 지원됩니다. 일반적으로 전체 표준 라이브러리를 사용할 수 있습니다. 여기 브라우저에 있고 여기에 우리가 좋아하는 Go의 stdlib가 있습니다.
• Go의 전체 패키지 생태계, 모든 타사 솔루션(템플릿 등)은 GopherJS를 사용하여 컴파일하고 브라우저에서 실행할 수 있습니다.

GopherJS는 얻기가 매우 쉽습니다. 일반 Go 패키지일 뿐입니다. 우리는 애플리케이션을 빌드하기 위한 GopherJS 명령을 가지고 있습니다.

이곳은 정말 작은 Hello World입니다...

...일반 ​​Go 프로그램, 일반 표준 라이브러리 fmt 패키지 및 브라우저 API에 도달하기 위한 바인딩 Js입니다. Println은 결국 콘솔 로그로 변환되고 브라우저는 "Hello gophers"를 작성합니다! 매우 간단합니다. GopherJS 빌드를 수행하고 브라우저에서 실행하면 모든 것이 작동합니다!

지금 당신은 무엇을 가지고 있습니까? 바인딩

널리 사용되는 모든 js 프레임워크에 대한 바인딩이 있습니다.

• 제이쿼리;
• Angular.js;
• 빅데이터 플로팅 및 작업을 위한 D3.js
• React.js;
• VueJS;
• Electron에 대한 지원도 있습니다(즉, 이미 Electron에서 데스크톱 애플리케이션을 작성할 수 있습니다).
• 가장 재미있는 것은 WebGL입니다(우리는 3D 그래픽, 음악 및 모든 기능이 포함된 게임을 포함한 전체 그래픽 애플리케이션을 만들 수 있습니다).
• 그리고 널리 사용되는 모든 자바스크립트 프레임워크 및 라이브러리에 대한 기타 많은 바인딩이 있습니다.

뼈대

1. GopherJS - Vecty를 위해 특별히 개발된 웹 프레임워크가 이미 있습니다. 이는 React.js의 본격적인 아날로그이지만 GopherJS의 특성을 사용하여 Go에서만 개발되었습니다.
2. 게임 가방이 있습니다(놀랐어요!). 가장 인기 있는 두 가지를 찾았습니다.
   • 엔고;
   • 에비텐.

Go에서 어떻게 보이는지와 이미 작성할 수 있는 내용에 대한 몇 가지 예를 보여 드리겠습니다.

또는 이 옵션(3D 슈팅 게임을 찾을 수 없지만 존재할 수도 있습니다):

나는 무엇을 제공하고 있습니까?

이제 프론트엔드 산업은 이전에 Javascript에서 울부짖던 모든 언어가 그곳으로 몰려들 정도의 상태입니다. 이제 모든 것이 "웹 어셈블리"로 컴파일됩니다. Gophers로서 우리의 정당한 자리를 차지하려면 무엇이 필요합니까?

Go는 전통적으로 이것이 시스템 프로그래밍 언어라고 가정했으며 실제로 UI 작업을 위한 라이브러리가 없습니다. 뭔가가 있지만 절반은 버려졌고 절반은 작동하지 않습니다.

이제 GopherJS에서 실행될 UI 라이브러리를 Go에서 만들 수 있는 좋은 기회입니다! 마침내 자신만의 프레임워크를 작성할 수 있습니다! 지금은 프레임워크를 작성할 수 있는 시기이며, 프레임워크가 가장 먼저 초기에 채택되고 스타가 될 것입니다(좋은 프레임워크라면).

이미 Go 생태계에 있는 다양한 패키지를 브라우저의 세부 사항(예: 템플릿 엔진)에 맞게 조정할 수 있습니다. 이미 작동하고 있으므로 편리한 바인딩을 만들어 브라우저에서 직접 콘텐츠를 쉽게 렌더링할 수 있습니다. 또한, 예를 들어 동일한 코드를 사용하여 서버와 프런트엔드에서 동일한 것을 렌더링할 수 있는 서비스를 만들 수 있습니다. 이는 프런트엔드 개발자가 좋아하는 모든 것입니다(현재 Go에서만 가능).

게임을 작성할 수 있습니다! 재미로...

나는 모든 것을 가지고있다.

질문

질문(이하 Q): – Go로 글을 쓰나요 아니면 Js로 작성하나요?

AG: – 루틴, 채널, 구조, 임베딩 등 모든 것을 Go에서 작성합니다. 이벤트를 구독하고 거기에 함수를 전달합니다.

에서 : – 그래서 “naked” Js로 글을 쓴다는 건가요?

AG: – 아니요, Go에서처럼 작성하고 브라우저 API에 연결합니다(API는 변경되지 않았습니다). 메시지가 채널로 전송되도록 바인딩을 직접 작성할 수 있습니다. 어렵지 않습니다.

에서 : – 모바일은 어떻습니까?

AG: – 확실히 봤습니다. Js가 실행하는 Cordova 패치에 대한 바인딩이 있습니다. React Native에서는 - 모르겠습니다. 있을 수도 있고 없을 수도 있습니다(특별히 관심이 없었습니다). N-go 게임 엔진은 iOS와 Android의 모바일 애플리케이션을 모두 지원합니다.

에서 : – 웹 어셈블리에 관한 질문입니다. 압축과 "압축"에도 불구하고 점점 더 많은 공간을 차지하고 있습니다... 이런 식으로 프론트 엔드 세계를 더욱 죽이지 않을까요?

AG: – 웹 어셈블리는 바이너리 형식이며 기본적으로 바이너리는 최종 릴리스에 텍스트보다 많을 수 없습니다. 런타임에 끌리지만 이는 표준 Javascript 라이브러리가 없을 때 끌어서내는 것과 동일하므로 우리는 Lodash를 사용하세요. Lodash가 얼마나 걸리는지 모르겠습니다.

에서 : – 분명히 런타임보다 적습니다 ...

AG: – "순수한" 자바스크립트에서요?

에서 : - 예. 압축해서 보내드립니다...

AG: – 하지만 이것은 텍스트입니다... 일반적으로 메가바이트는 많은 것처럼 보이지만 그게 전부입니다(전체 런타임이 있습니다). 다음으로 바이너리를 1% 늘리는 비즈니스 로직을 직접 작성합니다. 지금까지 나는 이것이 프론트엔드를 죽이는 것을 보지 못했습니다. 더욱이 웹 어셈블리는 구문 분석이 필요하지 않기 때문에 Javascript보다 빠르게 작동합니다.

에서 : – 아직도 논란이 되고 있는 부분인데… 아직 명확하게 판단할 수 있을 만큼 “Vasma”(웹 어셈블리)의 참조 구현이 없습니다. 개념적으로 그렇습니다. 우리 모두는 바이너리가 더 빨라야 한다는 것을 알고 있지만 동일한 V8의 현재 구현은 매우 효율적입니다.

AG: - 네.

에서 : – 편집은 정말 훌륭하게 작동하며 큰 이점이 있다는 것은 사실이 아닙니다.

AG: - 웹어셈블리도 대기업이 만드는군요.

에서 : – 웹어셈블리에 대한 판단은 아직 어려운 것 같습니다. 수년 동안 대화가 있었지만 느낄 수 있는 실제 성과는 거의 없습니다.

AG: - 아마도. 두고 보자.

에서 : – 백엔드에는 문제가 없습니다. 이러한 문제를 프론트엔드에 남겨두는 것이 좋을까요? 왜 거기로 가나요?

AG: – 일선 인력을 유지해야 합니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com