프론트엔드 개발하고 싶은데 자바스크립트(와 떨거지들)가 싫은 이들에게

자, 웹 사이트를 만들고 싶다.
하지만 현실은 자바스크립트 없이 살 수가 없다.
고전의 상징인 ASP, JSP, PHP 도 자바스크립트 없이 힘들다.
심지어 아예 자바스크립트, 혹은 타입스크립트를 써야 한다.
나열하자면,

• react
• vue
• angular
• svelte
• knockout
• backbone
• ember.js

등등... 많다. 좆망한 진도는 패스.
하지만 자바스크립트로 웹 개발하는 건 끔찍하다는 이들이 있다.
특히 JSP 하는 애들. ASP나 PHP 개발하면서 자바스크립트 쓰는 불만 의견은 내 경험상 없었다. 근데 유난히 자바 웹 개발자들이 불만이 많다. 내가 괜히 JSTL과 JS의 혼파망 메뉴얼을 만든 게 아니다.

그렇다면 자바스크립트 하나도 안 쓰고 웹 개발이 가능할까?
좋은 소식을 알려주겠다. 가능하다.
하지만, 먼저 내가 일러두는데, 사용하는 언어의 장점을 누릴 수 있으나,
반대로 단점을 심각하게 느낄 수 있는 최고의 기회다.
즉, 한계에 부딪히고 포기할 거면, 그냥 자바스크립트 배워라.
배워서 손해볼 거 없다.

어쨌든, 소개하도록 하겠다. 자바스크립트 없이 프론트엔드 개발 가능한 프레임워크를 지금 소개하겠다.

Flutter

앱개발자, 웹개발자도 이거 들어본 적 있을 것이다.
내가 이녀석의 장점과 단점을 나열한 적도 있다.

• 장점: 프론트엔드의 전부를 품었다.
• 단점: Dart

그렇다. 내가 앞서 언급한 언어의 단점을 심각하게 느낄 수 있는 놈 중 하나이다.
하지만 구글 하나로 버틸 수 있는 프레임워크다.
어쨌든, 이녀석도 웹 개발이 가능하다.
세팅만 다를 뿐, 나머지 코딩하는 건 동일하다.
그렇다. Flutter 할 줄 안다면 이걸로 웹 개발 세팅하고 평소대로 코딩하고 배포만 좀 다르게 하면 된다.
나는 써본 적이 없으니 더 이상의 지식이 없어 여기까지 하겠다.
아무튼, 결론은 Flutter 도 웹 프론트엔드 지원한다.

Blazor

ASP.NET Webform 써본 개발자 손! 아마 거의 10년 전까지의 얘기일 것이다.
당시 웹폼은 비즈니스 웹 앱에 엄청난 혁신을 가져다 주었다.
상용이긴 했지만(개발은 공짜지만 당시 배포하려면 IIS 설치한 윈도우 서버 필요)
스크립트 의존도를 획기적으로 줄이고, 포스트백(Postback) 개념을 통해 웹에서 할 수 있는 동적 기능을 재대로 보여주었던 프레임워크다.
Ajax 가 추가될 당시에도, 여전히 스크립트 의존도를 줄여주었다.
지금 ASP.NET Core 는 웹폼을 지원하지 않는다. 지원할 계획도 없다.
그래서 ASP.NET Webform 은 윈도우 전용인 .NET Framework 전용이다.

하지만 이번에 소개할 Blazor 는 크로스 플랫폼이다.
굳이 살인적인 윈도우 라이선스를 살 필요가 없다.
그리고 당시 ASP.NET Webform 처럼 C# 으로 대부분의 비즈니스 처리가 가능하다.
Blazor Webassembly 는 결과를 웹어셈블리로 배포해 웹 서비스한다.
Blazor Server 는 서버를 운영하면서 풀 스택을 커버할 수 있다.
Blazor Hybrid 는 이제 앱까지 범위를 확장하고 있다. 아직 프리뷰 단계지만.

이렇게 매력적이지만, 한국의 닷넷 역사는 참으로 처참하기 그지없다.
지금도 개발자 머리에는 C# -> 상용 이라는 인식이 아직도 박혀있다.
닷넷 하다가 전자정부 간 개발자들 보면 전자정부를 찬양한다.
그리고 다시 닷넷으로 돌아갈 생각 물어보면, 끔찍하다면서 반대한다.
그래도 끝까지 닷넷으로 존버한 개발자들에게는 이런 꿀이 없을 것이다.
나도 닷넷에서 전자정부로 전향했지만, 난 반대로 전자정부가 더 끔찍하다.
그래서 만약 가능하다면 닷넷으로 회귀하고 싶다... 희망사항이다.
하지만 그래줄 시니어 닷넷 개발자가 있을까...

갑자기 개인적인 생각이 났군. 어쨌든, Blazor 는 프론트엔드를 대부분 C# 으로 만들어주는 웹 앱 프레임워크다. 역시 닷넷이다.

언어 스펙이 점점 뇌절로 가는 것만 빼면...

Vaadin

Jetbrains 에서 자사 제품 및 커뮤니티 설문조사를 통해 통계를 발표했다.
내가 놀라웠던 점은, 국가 중 한국을 별도 분리해서 통계를 내줬다는 것이다.
아마 한국 총판 덕분일 수는 있겠다. 세금계산서 되니 안쓸 이유는 없으니까.
하지만 놀랍지 않았던 점은, 전 세계 중에서 자바 사용 비율이 가장 높은(53%) 국가였다는 것이다.
내가 그래서 한국은 이렇게 놀린다. 자바성애자, 오라클의 노예국가.
물론 나도 얄짤없이 자바와 오라클 개발하고 있기 때문에 나도 마찬가지긴 하다.

자. 너희들이 좋아하는 자바다. 악으로 깡으로 버텨라.
는 아니고 이번에 소개할 건 자바로 개발할 수 있는 웹 UI 프레임워크다.
그렇다. 대부분의 비즈니스 로직을 자바로 모두 가능하다면,
이건 정말 꿈같은 일이 아닐 수 없을 것이다.

하지만 자바 개발자들과 커뮤니티 내에서도, 하도 스프링 성애자들인지 모르겠지만,
이 Vaadin 에 대한 한국어 소개를 좀처럼 찾기가 힘들다.
아마 이 프레임워크를 꺼리는 요소 중 하나가 바로 상용이라는 점인 것 같다.

엄밀히 말하자면, 일단 핵심 기능은 오픈소스다. 하지한 한국 비즈니스에서 기본적으로 요구되는 차트와 그리드 컴포넌트를 쓰려면... 한 사용자당 월 119달러다.
이게 싫다면, 직접 그리드와 차트를 구현해야 한다.
물론 자바스크립트 연계를 지원할 테니 그걸 이용해 별도 개발하면 되겠지만...
아무래도 Pricing 탭을 보면 꺼려지는 건 어쩔 수 없을 것이다.

확실한 점은, 자바로도 스크립트 없이 UI를 만들 수 있다는 것이다.

한계

자. 이렇게 프론트엔드를 자바스크립트 없이 개발할 수 있는 프레임워크를 나열해 보았다.
하지만, 다들 알겠지만 모든 프레임워크는 100%를 만족하지 못한다.
특히 UI는 더욱 더.
이건 웹에 국한된 문제가 아니고 전체적인 UI 프레임워크들의 문제점까지 같이 안고 있다. 네이티브는 더 심하다는 거다.
일단 가장 핵심은, UI에서 제공하는 각 코어의 100%를 구현하지 않았거나, 프레임워크 한계로 구현하지 못했다는 점이 있겠다.
이건 웹 프레임워크라도 마찬가지로, 물론 Blazor 처럼 태그 작성으로 HTML 100% 커버 가능하다 해도, 스크립트에 대해서는 어쩔 수 없다는 것이다.
먼저, <canvas> 태그에 대해 다른 언어로 제공해주는 프레임워크는 없다.
이건 자바스크립트로 해결해야 한다. 특히 3D는 더욱 더.
물론 Unity 라는 게임 엔진 프레임워크가 있다. 근데 이건 목적이 다르기 때문에 패스.
물론 이 경우는 웹 게임 프레임워크가 도와주지만, 스크립트로 도와주지 다른 언어로 도와주지는 않는다.
그리고 브라우저를 활용하는 여러 API 또한 구현하지 않았다.
위 UI 프레임워크들의 목적은, UI 구현을 위해서이기 때문에, 브라우저에서 제공하는 API를 100% 활용할 이유가 없기 때문이다.
물론 이들을 사용자가 만든 확장으로 커버가 가능하긴 하지만,
결국 이들은 스크립트로 해결해야 한다. Notification API 나 Web Audio API, 그리고 브라우저 보안 연동 API 등등...
이들은 결국 스크립트를 작성해야 한다.

그렇다고 해서 포기하고 react나 vue 로 가라는 얘기는 아니다.
물론 현실에서는 프론트엔드 시장은 react 나 vue 로 양분화하긴 했지만,
비즈니스 시장은 모를 일이다. 한 번 검증 나오면, 너도나도 사용하기 때문이다.
물론 이건 한국에서 바랄 일은 아니다. 아무리 검증해도 내가 모르면 안 쓰기 때문에. 특히 SI.

결론이 뭐냐고? 자, 다른 언어로 웹 UI 만들 수 있는 프레임워크를 제공한다.

아, 사족으로 전자정부프레임워크에 Vaadin 도입 어떻겠냐 라고 이슈 올리려고 했는데... 포기했다. 내가 자신있게 참여한다 해도... 내가 모르면 소용 없기 때문에 말이지... 전자정부는 99% SI 가 쓰니까.

끗.