▲
GN⁺ 2025-02-19 | parent | ★ favorite | on: Svelte 5는 Javascript가 아님 (hodlbod.npub.pro)
Hacker News 의견

  • 처음에는 runes에 대해 별로 흥미가 없었음. 그러나 .svelte 템플릿에 반응형 외부 컴포넌트를 가져올 수 있고, 내부적으로 반응성을 캡슐화할 수 있을 때 의견이 바뀌었음. 이는 vitest 테스트를 작성할 수 있으면서도 반응성의 이점을 얻을 수 있다는 것을 의미함. 이는 정말 강력하고, AFAIK, 프론트엔드 세계에서 독특함

    • 대부분의 프론트엔드 개발자들은 테스트를 전혀 하지 않음. Typescript는 정확성을 보장하기 위해 사람들이 사용하는 도구이며, 그럴 만한 이유가 있음. 그러나 svelte 사용자들은 항상 typescript에 대해 좁은 시각을 가지고 있었고, 그럴 만한 이유도 있음
    • 개인적으로 테스트 가능한 프론트엔드 코드를 작성하는 것을 선호하며, Svelte 5는 그런 면에서 혁신적임. 브라우저에서 반응형이면서도 단위 테스트만큼 좋음
    • 이 모든 것을 말했지만, 블로그 게시물은 진실을 말하고 있음. 프록시를 추가하는 것은 매우 불편하게 느껴짐. React와 Vue는 추상화 위에 추상화를 추가하기 시작했을 때 나를 잃었고, 프록시는 그 시작점이었음
    • Svelte 5는 JavaScript가 아님이 <i>Svelte 5를 좋아하는 이유</i>임
    • 프론트엔드/웹을 합리적으로 할 수 있는 두 가지 주요 방법이 있다고 생각함
        1. 정적 HTML 또는 서버 렌더링된 템플릿, 아마도 HTMX
        1. JavaScript로 컴파일되는 언어/플랫폼. 최소한 TypeScript이지만, HTML과 CSS가 실제로 꽤 좋다고 생각하기 때문에 JSX, React, Tailwind 등은 <i>제외</i>되며, Svelte 5와 몇몇 다른 프레임워크는 실제로 바닐라 TypeScript보다 개선됨
    • Svelte 5는 카테고리 2에서 명확한 승자임
    • 멋진 HTML 템플릿, 쉽고 합리적인 상태 전파, 모듈식 코드를 쉽게 작성할 수 있는 기능을 가지고 있음. CSS와 잘 작동하며, 종종 간단한 일회용 앱과 도구를 한두 파일로 만들 수 있으며, 더 크고 진지한 애플리케이션도 가능함. Svelte 4보다 덜 마법적이고 놀랍지 않으며, 솔직히 사용하기 즐거움. 다행히도 IndexedDB에 대해 신경 쓰지 않음
    • 오늘날 JavaScript 한 줄을 작성할 이유를 전혀 모르겠지만, 각자 자기 방식대로 함

  • 상업적으로 배포된 SvelteKit 애플리케이션을 적극적으로 개발하고 있으며, 경험에 대한 생각을 공유하고 싶음

    • SvelteKit에 처음 끌린 이유는 그 단순함이었음. 프로젝트를 설정한 후, 현대적인 프레임워크의 이점을 복잡함 없이 활용하면서 한 번에 하나의 HTML/JS/CSS 파일을 작업할 수 있었음. 이는 웹 개발 초기 시절, Apache 서버에 HTML 파일을 떨어뜨리는 것만으로 모든 것이 실행되던 시절을 떠올리게 했음
    • 그러나 Svelte가 그 간단한 패러다임에서 벗어나는 것을 보는 것은 실망스러움. 처음부터 Rich Harris는 Svelte의 사용 용이성과 단순함을 주요 판매 포인트로 내세웠음. 현재의 SvelteKit 버전은 나쁘지 않지만, 이전 버전을 더 선호했음. 그때는 +page와 같은 라우팅 구조를 다룰 필요가 없었음. Svelte 파일을 원하는 곳에 배치할 수 있었고, 현대적인 프레임워크의 이점을 누리면서도 매끄럽게 렌더링되었음
    • 이러한 변화는 이전에 필요하지 않았던 복잡성을 추가하며, Svelte의 매력을 처음부터 멀어지게 할 가능성이 있음. 이미 알고 있는 것을 바탕으로 선택했음

  • EmberJS가 사라진 것은 아쉬움. API는 지난 10년 동안 꽤 안정적이었음. 아이러니하게도 지난 10년 동안 EmberJS 앱을 작성한 사람은 React, Svelte, Vue 등으로 동일한 작업을 한 사람보다 마이그레이션에 덜 어려움을 겪을 것임

    • 안타깝게도 Ember 팀은 초기에 몇 가지 이상한 결정을 내렸고, 일반 JavaScript에 비해 쉽게 이해할 수 없었음 (대부분은 이제 수정되었음)
    • JavaScript인지 아닌지는 API의 안정성에 비하면 별로 중요하지 않음
    • 개인적으로 JavaScript의 문제는 너무 자주 변화한다는 것임

  • 저자가 게시물 상단에 나열한 두 개의 Github 링크는 동일한 문제를 가리키며, 그 문제에는 해결책이 있음 (use $state.raw)

    • Svelte 2 또는 3 버전부터 Svelte의 팬이었음. 이는 바닐라 HTML/CSS/JS를 작성하는 것과 가장 가까우면서도 프레임워크의 이점을 누릴 수 있었기 때문임 (그리고 Sass와 TypeScript를 사용함). 환상적임
    • Svelte 5는 runes가 이상해서 불안하게 느껴졌음. 프로젝트를 업그레이드하고 다른 프로젝트에서 작업한 후, 그렇게 나쁘지 않음. Svelte 5는 상태 처리의 옛 방식과 새 방식을 혼합하는 것을 허용하지 않으며, 오류 메시지는 대부분 유익함
    • 이 댓글에서 htmx와 바닐라 JS가 객관적으로 더 낫다고 말하는 사람들을 보는데... 아니? 당신이 하는 일에는 그렇겠지만. 개인적으로 Svelte는 React보다 여전히 이해하기 훨씬 쉬움. 벤치마크를 신경 쓰는 사람들에게는 Svelte가 SolidJS만큼 빠름 (React 사용자들은 Solid로 쉽게 전환할 수 있을 것 같음, 문법이 비슷하게 느껴짐)

  • Svelte 5는 JavaScript가 아닌 <i>최악의</i> 방식임. js의 문제를 해결하지 않고, 일부 프론트엔드 문제에 대한 누출된 추상화를 제공함. Solid가 Svelte보다 더 나은 방향이라고 생각함. Solid는 새로운 언어에 의존하지 않기 때문임. 그러나 js가 이상적이지 않기 때문에 js가 아닌 것을 만들려는 본능이 있음. Elm은 svelte의 전신임. 그러나 더 나은 것을 만들 수 있다고 생각함...[0]

  • Svelte 4에서 스토어가 정말 싫었기 때문에 Svelte 5를 사용하기 시작했음. 새로운 프로젝트에 Sveltekit과 Svelte 5를 사용하고 있으며, 말해야겠음... React의 생산성은 여전히 무적임, Sveltekit과 Svelte 기술이 기술적으로 더 나은데도 불구하고

    • 정말 짜증났던 몇 가지: 모든 페이지가 +page.server.ts 또는 +page.svelte 또는 그 변형으로 이름이 지정되어 있어 코드를 쉽게 검색하기 어려움. Svelte의 도구는 tsc 및 ESLint와 별도로 존재하여 CI에 통합하고 개발에서 사용하는 것이 더 어려움
    • 이전 버전과의 이상한 호환성 문제도 있음. 예를 들어, 대부분의 Svelte 패키지는 여전히 스토어를 사용하므로, 두 가지 버전의 세계와 싸워야 하며, 코드 작성이 때때로 정말 혼란스러움. 또한, Svelte HMR은 여전히 초기 단계인 것 같음, 그래서 Svelte 모듈이 다시 로드될 때 상태를 망칠 것임
    • Svelte를 정말 좋아하고 싶음. 렌더링 속도가 상당히 빠르고 그 뒤에 있는 아이디어가 마음에 듦. 그러나 React의 생산성은 무적임

  • 콜백으로 클로저를 전달할 때 예상치 못한 동작 때문에 Svelte가 JavaScript가 아니라고 말하는 것은 이상하게 느껴짐. 더 나은 제목은 "Svelte 5가 나를 놀라게 해서 싫다"일 것임

  • 순수 JavaScript를 사용할 수 있는 컴포넌트와 앱을 빌드할 수 있는 라이브러리를 찾고 있다면 Lit를 확인해 보세요: Lit

    • 깊은 반응성을 위해 신호에 대한 추가 패키지가 있으며, 다가오는 Signals TC39 제안과의 통합을 목표로 하고 있음: Signals
    • Lit는 Photoshop, Reddit, Home Assistant, The Internet Archive와 같은 주요 앱에서 사용됨

  • 합리적인 프론트엔드 경험을 원한다면? 바닐라 Javascript, 웹 컴포넌트, htmx, Blazor를 사용하세요

    • JS 프레임워크는 어떤 이유에서든 광기임