Svelte Native - Svelte로 모바일 네이티브 앱 개발하기
(svelte-native.technology)- Svelte 프레임워크를 이용한 모바일 앱 개발
- Transitions, Stores, Reactivity를 포함한 Svelte의 전체 기능을 그대로 이용
- NativeScript를 이용하여 크로스플랫폼 네이티브 iOS/Android 앱을 WebView 없이 개발
- 모바일 기기에서 대부분의 작업을 수행하는 React Native 나 NativeScript-Vue 와 달리 컴파일 단계에서 대부분의 작업을 처리
- 웹 기술과 코드를 공유하면서 진정한 네이티브 UI와 성능을 제공
- 가상 DOM Diffing 같은 기술 대신, 앱의 상태가 변경될 때 네이티브 뷰 위젯을 정교하게 업데이트 하는 코드를 작성
Hacker News 의견
- 프로젝트의 장점에도 불구하고, 이것이 공식 Svelte 프레임워크의 일부가 아니라는 사실을 좀 더 명확히 해야 함. 프로젝트가 Svelte 문서의 외관을 모방하고 있으나, 그들이 누구인지에 대한 설명이 부족하다고 느낌.
- React Native로 앱을 몇 개 만들어본 경험이 있는데, 시간이 지나면서 다양한 버전의 자바스크립트 라이브러리, 프레임워크, 안드로이드/iOS 버전, 빌드 시스템 간의 호환성 문제로 복잡성이 폭발적으로 증가하여 악몽이 됨. Kotlin/Swift를 배우고 단일 생태계를 유지하는 것을 선호함.
- Svelte의 열렬한 팬임에도 불구하고, 이 프로젝트는 지난 몇 년간 많은 관심과 주의를 받지 못함. 그러나 React와 React Native가 웹 기술로 네이티브 앱을 만들고자 하는 사람들에게 더 적합하다고 생각함. Safari의 PWA 지원 진전, Apple의 네이티브 개발자에 대한 증가하는 적대감, WebGPU와 같은 브라우저 개선 사항 등을 고려할 때, 앞으로는 95%의 사용 사례에 대해 네이티브 앱을 만들 필요가 없기를 희망함. 이를 방해하는 주된 장애물은 Apple이 iOS에서 웹 앱을 계속해서 두등급 시민으로 취급하고 Safari에 좋은 네이티브 경험을 제공하기 위한 API를 마지못해 추가하는 것임.
- 몇 년 전 회사에서 크로스 플랫폼 앱을 만들기 위해 이 기술을 시도했으며, Svelte 웹 인터페이스와 많은 코드를 공유할 수 있기를 희망함. 3-4개월 동안 많은 진전을 이루었지만, 디버깅하기 어려운 많은 이상한 버그와 엣지 케이스에 부딪힘. 결국 모바일 코드베이스에 Flutter로 전환함. 이후에 개선되었을 수 있지만, 초기 인상을 바탕으로 NativeScript를 간단한 인터페이스 요구 사항 이외의 것에는 추천하지 않음.
- 이것은 React Native의 Svelte 버전이라기보다는 NativeScript의 래퍼 중 하나임.
- NativeScript를 기반으로 함. 크로스 플랫폼을 원한다면 RN을 고수하는 것이 낫다고 생각함. Kotlin이나 Swift로 앱을 작성하는 것이 이 복잡한 시스템보다 쉬움.
- '네이티브'라는 단어가 남용되고 있음.
- 예제 앱이 5년 전 것임. 누군가 이것을 사용하고 있는지 의문.
- 지난 몇 년간 많은 모바일 앱을 만들었는데, 항상 웹뷰 안에서 웹 기술을 사용하여 렌더링함. 사용자 경험을 매우 중요하게 생각하기 때문에, 현대 스마트폰에서는 React Native, Flutter, NativeScript와 같은 도구를 사용하는 것보다 웹뷰 안에서 렌더링하는 것의 이점을 볼 수 없음. Ionic과 같은 UI 라이브러리는 네이티브 UI 컴포넌트와 구별할 수 없으며, 이와 반대되는 실제 사용자 연구가 없음. 그렇다면 왜 이러한 크로스 플랫폼 도구를 사용하고 Svelte를 직접 웹뷰와 함께 사용하지 않아야 하는가?
- Svelte를 좋아하며, 그것의 독특한 컴포넌트 모델이 네이티브 모바일 앱 개발에 잘 맞기를 희망함. 도구 체인이 React Native와 많이 다른지 궁금함.