9P by neo 8달전 | favorite | 댓글 4개
  • Svelte 5가 Runes라는 기능을 도입하여 JavaScript의 반응성을 향상시킴
  • 2019년 Svelte 3은 Javascript를 Reactive 언어로 바꿨음
    • 컴파일러를 이용하여 선언형 컴포넌트를 최적화된 자바스크립트로 변환
  • Runes는 이 Reactivity를 모든 곳에 적용
    • let count = $state(0); 처럼 함수 형태로 적용
    • Compile-time Reactivity 에서 Runtime Reactivity로
  • Runes를 통해 반응성이 .svelte 파일의 경계를 넘어서 확장되어, 컴포넌트 간에 로직을 캡슐화하여 재사용하는 과정을 단순화
  • Svelte의 새로운 버전은 예전에 Knockout 이 이용 했던 Signals 기반으로 구동. 직접 작용이 아닌 내부 구현으로 돌려서 조금 다르게 구현
  • $derived와 $effect runes를 도입하여, 이들이 Evaluate될 때 표현식의 종속성을 결정하며, 런타임 반응성을 향상
  • Runes는 여러 기존 개념을 불필요하게 만들어, Svelte 프레임워크를 단순화하고 앱을 더 쉽게 구축하고 유지할 수 있게 될 것
  • 대부분의 사용자들에게 대체 가능한 제품을 목표로 삼고 있으며, 새로운 기능들은 선택적으로 사용할 수 있도록 하여 기존 컴포넌트가 계속 작동하도록 보장
  • 아직 Svelte 5 공개일자는 결정되지 않았고, 현재 진행중인 작업임

qwik에게서 많은 영향을 받은 것 같네요

Hacker News 의견
  • 기사는 Svelte 5의 출시와 특히 새로운 기능 'Runes'에 대해 논의한다.
  • 일부 댓글러들은 Svelte의 새로운 기능을 Vue와 Solid의 상태 및 파생/계산 변수와 비교한다.
  • 반응형 신호의 효과에 대한 논쟁이 있으며, 일부는 이것이 다른 변화에 영향을 미치는 변화의 혼란을 초래할 수 있다고 주장한다.
  • 일부 사용자들은 새로운 'Runes' 기능에 대해 우려를 표현하며, 이것이 이전보다 더 일반적인 코드처럼 보이며, 혼동을 초래할 수 있다고 주장한다.
  • 변화에 대한 불편함의 감정이 있으며, 일부 사용자들은 Svelte가 너무 복잡해지고 간단함을 잃어버릴까 두려워한다.
  • 한 댓글러는 Svelte가 전통적인 구문을 유지하고 이를 새로운 기능과 유사하게 작동하도록 백그라운드에서 변환할 수 있다고 제안한다.
  • Svelte의 고유한 강점인 사용자 정의 컴파일러를 가지고 언어처럼 동작하는 것에 대한 논의가 있으며, 일부는 이것이 전통적인 JavaScript 프레임워크를 닮아가고 있다고 우려한다.
  • 일부 사용자들은 다른 라이브러리들이 독립적으로 동일한 반응형 개념을 재창조하고 있어 호환성이 떨어지고 미래에 프레임워크를 변경하는 것이 더 어려워지는 것에 대해 실망감을 표현한다.
  • 몇몇 댓글러들은 $:의 제거에 대해 기쁘게 생각하며, 이것이 Typescript 사용자를 돕고 구문 혼동을 피하는 데 도움이 될 것이라고 말한다.
  • Svelte가 긴 배열을 어떻게 처리하고, 세밀한 재계산/업데이트만 해당 뷰 요소를 할 수 있는지에 대한 질문이 있다.
  • 한 사용자는 Svelte 4, Svelte 5, 그리고 다른 프레임워크들 간의 비교를 위한 링크를 공유한다.
  • 일부 사용자들은 Svelte가 '기본적으로 반응성'에 대한 입장을 바꾸는 것을 비판하며, 이것은 신뢰의 손실이며 Node.js 생태계의 재발명과 재발견 경향의 증상이라고 주장한다.
  • 마지막 댓글은 Svelte가 React Hooks에 더 가까워지고 있지만 컴파일 단계를 사용하여 이들을 최적화한다고 제안한다.

슬쩍 보니까 기존이랑 방향성도 달라 보이고 이질감도 확 드네요. 굳이 싶기도 하고 덜 간결하기도 하고 해커 뉴스 반응과 마찬가지로 조금 우려되는 부분입니다