WEB 프런트 엔드 개발에 Haxe를 사용했지만 Elm으로 환승해도 괜찮을까 생각한 이야기

이것은 이치가야 Geek★Night 「형이 있는 프런트 엔드의 세계~프런트 엔드・프론티어~」의 LT에서 발표 내용입니다.

이것은 Elm을 사용해 보면 좋았다라고 하는 이야기입니다.

이 발표의 타이틀에 Haxe가 포함되어 있습니다만, “형이 있는 프런트 엔드의 세계”라고 하는 당 공부회의 타이틀을 따서 붙이고 있는 것만으로, Haxe에 대한 불만은 거의 나오지 않습니다. 미리 용서해주세요 m (__) m

뭐, 하지만 Haxe라는 이름도 냈으므로 Haxe에 대해서도 조금 소개해 둡시다.

Haxe를 사용한 이유

DeadCodeElimination으로 컴파일 후의 코드가 필요한 코드만이 된다!

표준 라이브러리가 풍부합니다 (프론트 엔드 자바 스크립트와 비교하여)

구조적 부분형 편리!

컴파일 할 때 Asset을 코드에 삽입 할 수있는 기능

컴파일 초기

뭔가 언어 기능을 원했을 때의 매크로

Haxe 그만둘까 생각한 이유

_인인인인인인인인인인인인인인인인인인인인인_
> FlashDevelop이 Windows에서만 사용할 수 있습니다 <
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣


Haxe의 약점은 에디터가 적다는 것은 알려진 사실이라고 생각합니다만, 지금까지 애용하고 있던 IDEA의 Haxe 플러그인의 갱신이 멈추어 버려, Mac로부터 이용할 수 있는 괜찮은 IDE가 없어져 버립니다 다…



마지막으로 갱신된 것이, 약 1년전…
그 사이에 IDEA의 최신 버전이 올라 이용할 수 없게 되어 버렸습니다…

그런 실의 속에, 어떤 소문을 듣습니다.

Elm, FRP 그만해

Elm은 무엇입니까?

AltJS의 일종

Haskell의 신택스

ElmArchitecture라는 개념으로 응용 프로그램 빌드

Elm에 대한 첫 인상

최소한의 간단한 언어 사양이라는 개념은 매우 흥미 롭습니다

ElmArchitecture라는 개념이 요즘 프론트 엔드 라이브러리/프레임 워크 전쟁에서 벗어나는 (언어가 Architecture를 가지고 있음)에 호감이있었습니다.

하지만, Signal이라는 개념을 이용해 FRP라고 하는 근처에서, 조금 앙상하다고 생각해 경원…

최신 Elm

Signal을 철폐했습니다

ClosureCompiler 대응

RequireJS, CommonJS 대응

Signal을 철폐한 것으로, ElmArchitecture가 매우 단순한 것이 되어, 또, ClosureCompiler나 RequireJS, CommonJS에 대응하는 것으로 실용성도 오히려 높아져 왔습니다.

가정을 갖고 버리고 학습 시간을 무한하게 취할 수 있는 엔지니어에게 있어서, 앞으로 습득하는 기술이 단순한 것은 매우 중요합니다.

Elm은 학습하는 점에서 다음과 같은 이점이 있습니다.

언어 사양이 간단하기 때문에, 습득까지의 시간이 거기까지 필요 없다 (주관이지만 ES6 기억하는 것보다 편하다)

Elm은 가상 DOM의 모듈을 패키지로 제공하므로 Js 세계의 가상 DOM 라이브러리 전쟁에 신경 쓰지 않아도됩니다.

ElmArchitecture를 배워야하므로 프로젝트를 통해 Architecture를 제공하는 프레임 워크를 배울 필요가 없습니다

Elm이 좋을 것이라고 생각하는 사람은 빨리 시도해 보자.

끝