svelteKit의 짧은 역사

목차



십월



  • @sveltejs/kit on NPM - 0.0.8 - 2020년 10월 13일

  • - 2020년 10월 19일

  • Svelte, a bright future with Snowpack - 2020년 10월 24일

  • The Next Svelte May Be Serverless-First - 2020년 10월 28일

  • 11 월 12 월



  • - 2020년 11월 5일

  • What's the deal with SvelteKit? - 2020년 11월 5일

  • - 2020년 11월 6일

  • SvelteKit and the future of web development - 2020년 11월 12일

  • @sveltejs/kit on NPM - 1.0.0-next.1 - 2020년 12월 3일

  • 1월~2월



  • Svelte adapter for Netlify (@1.0.0-next.0) - 2021년 1월 24일

  • Ben McCann on Sapper and SvelteKit - 2021년 1월 25일

  • SvelteKit, the first ‘serverless-first’ framework? - 2021년 2월 2일

  • NPM의 @sveltejs/kit - 0.0.8



    Rich Harris, Conduitry - 2020년 10월 13일

    Here be dragons, etc etc.

    This is a more fleshed-out version of snowpack-svelte-ssr that aims to replicate Sapper's functionality in its entirety, minus building for deployment (which can be handled by 'adapters' that do various opinionated things with the output of snowpack build).

    It's currently missing a ton of stuff but I figured I'd throw it up on GitHub anyway partly for the sake of 'working in the open' but mostly because I need an issue tracker to organise my thoughts.

    There are no tests yet or anything like that. Some of the code has just been straight copied over from the existing Sapper repo, but a pleasing amount of it can safely be left behind.

    This [Snowpack] thing is really neat. It has some bugs and missing features, but identifying those is the whole purpose of this experiment, and so far I've been able to MacGyver my way around them.

    Clone this repo, npm install, and npm link. That will create a global link to the svelte bin. You can then either npm run build or npm run dev, if you intend to make changes and see them immediately reflected.

    Then, clone the corresponding svelte-app-demo repo and follow the instructions therein.





    리치 해리스 - 2020년 10월 19일



    Q: Do I have to use this workflow?



    아니요, 절대 아닙니다. 구성 요소 자체를 기술적으로 사용하는 것이 기술적으로 가능하더라도 전체 경험을 실제로 소유하고 싶어하는 Angular 및 Ember와 같은 것들 사이의 프레임워크 영역에는 이러한 분할이 있습니다.

    반면에 React 및 Vue와 같은 것은 실제로 구성 요소 프레임워크일 뿐이며 앱을 직접 빌드해야 합니다. 이것이 바로 Next, Gatsby 및 Remix와 같은 것이 존재하는 이유입니다. 나는 Svelte가 둘 다 되기를 원합니다.

    몇 초 만에 이 앱 템플릿을 사용하여 광범위하게 생산성을 높일 수 있지만 어떤 이유로든 이 템플릿으로 충족되지 않는 특정 요구 사항이 있는 고급 사용자인 경우 이러한 요구 사항은 Svelte 프로젝트에서 계속 충족됩니다. .

    사람들이 자신만의 맞춤형 통합, Eleventy와 같은 플러그인 또는 Routify 및 ElderJS와 같은 Svelte 기반 프레임워크를 구축할 수 있다는 것은 매우 중요하며 이는 변경되지 않을 것입니다.


    Svelte, Snowpack과 함께하는 밝은 미래



    Carlosvin - 2020년 10월 24일

    As you might know, this blog is powered by Sapper. I am already quite happy with it, so when I hear this announcement, I felt like when they cancel a TV Series that I am enjoying.

    Happily, there is a good reason, there is going to be a better Sapper, I think they will call it SvelteKit, it is solving some issues and improving some aspects of Sapper, but the main benefit, in my opinion, is that you won’t have to choose between Sapper or Svelte when you start a new application, everything will be supported by the Svelte ecosystem.



    차세대 Svelte는 서버리스 우선일 수 있습니다.



    브루노 쿠리올 - 2020년 10월 28일

    Harris then demoed svelte@next, the Svelte version that is being experimented upon — we will refer to that from now on as Svelte Next. Like Sapper (and Next.js), Svelte Next adopts a file-based routing. Harris created in the src/routes directory the components implementing the routes for the demoed application.

    An index.svelte file implements the home page while an about/index.svelte implements the /about route. Layout components ($layout.svelte) may implement commonly occurring parts of pages (e.g., a header or a footer) and keep the pages’ implementation DRY.





    리치 해리스 - 2020년 11월 5일






    리치 해리스


    @rich_harris






    요리에 대한 블로그 게시물: svelte.dev/blog/whats-the… tl;dr• Sapper가 다시 작성됩니다• Svelte 앱을 빌드하는 기본 방법이 됩니다• 맛있는 새 기능• 정말 멋집니다 💨(Snowpack 덕분에)


    오후 14:39 - 2020년 11월 05일









    SvelteKit과의 거래는 무엇입니까?



    리치 해리스 - 2020년 11월 5일

    스노우팩



    Snowpack is at the vanguard of this movement, and it's what powers SvelteKit. It's astonishingly fast, and has a beautiful development experience (hot module reloading, error overlays and so on), and we've been working closely with the Snowpack team on features like SSR.

    The hot module reloading is particularly revelatory if you're used to using Sapper with Rollup (which has never had first-class HMR support owing to its architecture, which prioritises the most efficient output).



    롤업



    That's not to say we're abandoning bundlers altogether. It's still essential to optimise your app for production, and SvelteKit uses Rollup to make your apps as fast and lean as they possibly can be (which includes things like extracting styles into static .css files).



    서버 렌더링



    The other foundational assumption is that a server-rendered app needs, well, a server. Sapper effectively has two modes:

    • sapper build, which creates a standalone app that has to run on a Node server
    • sapper export which bakes your app out as a collection of static files suitable for hosting on services like GitHub Pages.


    정적 파일 및 서버리스 플랫폼



    Static files can go pretty much anywhere, but running a Node server (and monitoring/scaling it etc) is less straightforward.

    Nowadays we're witnessing a shift towards serverless platforms, in which you as the app author don't need to think about the server your code is running on, with all the attendant complexity. You can get Sapper apps running on serverless platforms, thanks to things like vercel-sapper, but it's certainly not what you'd call idiomatic.

    SvelteKit fully embraces the serverless paradigm, and will launch with support for all the major serverless providers, with an 'adapter' API for targeting any platforms that we don't officially cater to. In addition, we'll be able to do partial pre-rendering, which means that static pages can be generated at build time but dynamic ones get rendered on-demand.





    Anthony Campolo - 2020년 11월 6일

    The Svelte core team is shifting its efforts to a project known as SvelteKit. It's important to emphasize that the people building Svelte, Sapper, and SvelteKit are all basically the same people. So really nothing drastic is changing here and it's more of a rebrand and namespace migration. Or is it?

    In addition to the new name, there is also going to be a larger focus on serverless technology with Svelte now being referred to as a "serverless-first" framework. But to me the most significant change by far is the removal of Rollup and its replacement with Snowpack.

    SvelteKit is very new, so new it currently exists mostly in the form of the blog post linked at the beginning of this article. But you can download it and start using it, albeit with many, many caveats attached to it.



    Rich Harris가 SvelteKit과 웹 개발의 미래에 대해 이야기합니다.



    Svelte 라디오 - 2020년 11월 12일

    SvelteKit is, in one way it's a successor to Sapper. And you could even think of it as Sapper 1.0, if you like. But in another larger sense, it's our kind of vision for the way that you should build Svelte apps in future.

    It’s something that we've been kind of talking about in a peripheral sense for a long time, we've been talking about how we can evolve Sapper to take advantage of some of the recent trends in front end development, particularly the rise of serverless and more recently, the rise of unbundled workflows.

    But it all sort of came to a head recently, you know, the pace of development on Sapper had hit a bit of a low, at least until Ben McCann really picked up the baton and started churning through issues. And people were getting a little bit frustrated, I think with the progress. And Anthony is one of those people because he uses Sapper very heavily in his job.

    At a certain point, we're like, “What if we just started from scratch?” Like the big rewrite, as opposed to trying to get all of these ideas into what was honestly kind of a watery codebase. I sort of proposed this very hesitantly in the discord thinking everyone was going to yell at me. And instead everyone was like, “Oh, yeah, let's do that.”



    NPM의 @sveltejs/kit - 1.0.0-next.1



    Rich Harris, Conduitry - 2020년 12월 3일

    Here be dragons, etc etc.

    This project aims to replicate Sapper's functionality in its entirety, minus building for deployment (which can be handled by 'adapters' that do various opinionated things with the output of snowpack build).



    Netlify용 Svelte 어댑터(@1.0.0-next.0)



    Jasper Moelker - 2021년 1월 24일

    netlify.toml에서 사용자가 정의한 netlify 구성 가져오기




    module.exports = async function adapter(builder) {
      let netlify_config
    
      if (fs.existsSync('netlify.toml')) {
        try {
          netlify_config = toml.parse(fs.readFileSync('netlify.toml', 'utf-8'))
        } catch (err) {
          err.message = `Error parsing netlify.toml: ${err.message}`
          throw err
        }
      }
    
      else {
        throw new Error(
          'Missing a netlify.toml file. Consult https://github.com/sveltejs/kit/tree/master/packages/adapter-netlify#configuration'
        )
      }
    
      if (!netlify_config.build || !netlify_config.build.publish || !netlify_config.build.functions) {
        throw new Error(
          'You must specify build.publish and build.functions in netlify.toml. Consult https://github.com/sveltejs/adapter-netlify#configuration'
        )
      }
    
      // ...code blocks listed below
    
    }
    


    정적 호스팅을 위한 게시 디렉터리




    const publish = path.resolve(netlify_config.build.publish)
    


    클라우드 함수용 함수 디렉터리




    const functions = path.resolve(netlify_config.build.functions)
    


    정적 및 클라이언트 파일을 정적 호스팅 디렉토리에 복사




    builder.copy_static_files(
      publish
    )
    
    builder.copy_client_files(
      publish
    )
    


    클라우드 함수 디렉터리에 서버 파일 복사




    builder.copy_server_files(
      `${functions}/render`
    )
    


    렌더러를 Cloud Functions 디렉터리에 복사




    fs.copyFileSync(
      path.resolve(
        __dirname,
        'files/render.js'
      ),
      `${functions}/render/index.js`
    )
    


    _redirects 파일의 서버리스 렌더링 기능에 대한 포괄 경로




    fs.writeFileSync(
      `${publish}/_redirects`,
      '/* /.netlify/functions/render 200'
    )
    


    프리렌더




    builder.log.info(
      'Prerendering static pages...'
    )
    
    await builder.prerender({
      dest: publish
    })
    


    Sapper 및 SvelteKit의 Ben McCann



    Svelte 라디오 - 2021년 1월 25일

    Q: On a high level, what is the difference between Sapper and SvelteKit?



    제 생각에 가장 큰 변화는 개발자 경험입니다. SvelteKit은 Snowpack 및 esbuild 위에 구축되므로 컴파일 시간이 훨씬 빨라지는 것을 확인할 수 있습니다. 그리고 그것은 더 큰 Sapper 프로젝트에서 문제가 되는 것입니다.

    Sapper를 사용하여 새 사용자로 시작할 때 반드시 알아차리지 못할 수도 있습니다. 그러나 프로젝트를 확장하기 시작하면 Sapper를 사용한 컴파일 시간이 조금 더 길어질 수 있습니다. 우리의 희망은 이러한 모든 문제를 해결하고 SvelteKit을 사용하여 정말 매끄러운 경험을 만드는 것입니다.


    최초의 '서버리스 우선' 프레임워크인 SvelteKit?



    Jasper Moelker - 2021년 2월 2일

    To ensure Svelte runs seamlessly on all [serverless platforms], Svelte will provide an adapter for each. Each adapter does three things:

    1. Copy to the serverless hosting directory Svelte’s:
      • compiled client-side JS bundles
      • other static files
    2. Copy to the serverless functions directory Svelte’s:
      • server-side JS bundles
      • platform specific render function
    3. Create the redirects configuration with a catch-all route to the serverless render function.

    The adapter takes platform specific configuration (files) into account.

    좋은 웹페이지 즐겨찾기