Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SvelteKit Is in Public Beta

svelte.dev

Post reply on HN
Print view View original

51–60 of 119 posts

Re: SvelteKit Is in Public Beta

#51

Post by skybrian »

pier25 wrote: post #31
SiVal wrote: post #22

What is SvelteKit? The linked page assumes I already know and have just been waiting for an announcement. I have heard a bit about Svelte. I love the analogy with spreadsheets, where original spreadsheets reevaluated every cell whenever any cell changed. Modern spreadsheets maintain a dependency graph, so when something changes, only the direct dependencies are even evaluated. If any of them change, then only their d…

It's an application framework for Svelte which replaces Sapper. It uses Vite[1] for development and has been designed from the start to be able to produce static sites a la Gatsby or Next (Sapper wasn't great at that). Svelte Kit runs SSR on Node JS servers like Sapper did, but also on cloud functions and I think even Cloudflare Workers which do not run Node. [1] https://vitejs.dev/

That doesn't help. What is Sapper? This is defining web tech in terms of other web tech.

Re: SvelteKit Is in Public Beta

#52

Post by DrStartup »

Web dev with Svelte brings me back to the early days of web development - php, MySQL, jquery and XMLhttprequest. I personally have never understood all the tooling required to build a modern day react app, and oh how I have tried. Svelte dev as a way-of-thinking-framework is as close to the fundamentals as I think you can get. The dx is amazing and sveltekit takes it to the next level. #sveltalowda

Edit: embarrassing typo

Re: SvelteKit Is in Public Beta

#53

Post by slim »

from the documentation:

  There are two basic concepts:
There are two basic concepts:

Each page of your app is a component

You create pages by adding files to the src/routes directory of your project. These will be server-rendered so that a user's first visit to your app is as fast as possible, then a client-side app takes over

looks like you reinvented php, no?

Re: SvelteKit Is in Public Beta

#54

Post by rich_harris »

slim wrote: post #53

from the documentation: There are two basic concepts: There are two basic concepts: Each page of your app is a component You create pages by adding files to the src/routes directory of your project. These will be server-rendered so that a user's first visit to your app is as fast as possible, then a client-side app takes over looks like you reinvented php, no?

oh, does PHP include a client-side router these days? that's exciting!

Re: SvelteKit Is in Public Beta

#55

Post by F117-DK »

rich_harris wrote: post #54
slim wrote: post #53

from the documentation: There are two basic concepts: There are two basic concepts: Each page of your app is a component You create pages by adding files to the src/routes directory of your project. These will be server-rendered so that a user's first visit to your app is as fast as possible, then a client-side app takes over looks like you reinvented php, no?

oh, does PHP include a client-side router these days? that's exciting!

lol

Re: SvelteKit Is in Public Beta

#57

Post by jiofih »

slim wrote: post #53

from the documentation: There are two basic concepts: There are two basic concepts: Each page of your app is a component You create pages by adding files to the src/routes directory of your project. These will be server-rendered so that a user's first visit to your app is as fast as possible, then a client-side app takes over looks like you reinvented php, no?

No. PHP hasn’t been “one file per page” in at least 15 years, and that’s hardly a defining trait for either of these two things.

If this is your only thought about it, you have a lot of catching up to do!

Re: SvelteKit Is in Public Beta

#58

Post by jiofih »

msoad wrote: post #44
qbasic_forever wrote: post #17

Earlier quoted context omitted.

No, go back about a week to the thread here on esbuild: https://news.ycombinator.com/item?id=26399377 Esbuild is a go-based tool that takes the place of babel, webpack, tsc, etc. and is much, much faster than webpack. Vite adds a nicer dev experience on top of esbuild (hot module reloading, etc.).

not tsc. There has been attempts to build a faster tsc but I have not seen any results yet.

It takes the place of TSC as a compiler which is a significant speed-up. You still need tsc for the actual type-checking.

Re: SvelteKit Is in Public Beta

#59

Post by searchableguy »

msoad wrote: post #44
qbasic_forever wrote: post #17

Earlier quoted context omitted.

No, go back about a week to the thread here on esbuild: https://news.ycombinator.com/item?id=26399377 Esbuild is a go-based tool that takes the place of babel, webpack, tsc, etc. and is much, much faster than webpack. Vite adds a nicer dev experience on top of esbuild (hot module reloading, etc.).

not tsc. There has been attempts to build a faster tsc but I have not seen any results yet.

I only know of one active attempt at: https://stc.dudy.dev/docs/status from the author of swc. You may ask kdy to test but the product is closed source unlike swc.

Re: SvelteKit Is in Public Beta

#60

Post by rich_harris »

idreyn wrote: post #36

> Even though it was far from ready, SvelteKit was the only framework that matched our esoteric requirements. (Anyone who has worked in a newsroom and done battle with their CMS will know what I'm talking about.) I would be interested to hear more about the esoteric requirements; whether they're performance-related, have to do with what's representable in the CMS, or something else. At any rate, those NYT covid track…

things like:

• we can't have any dynamic pages, everything has to be static HTML

• we don't control the actual page; our job is to create a fragment of HTML that the CMS stitches into the body, then associate that fragment with some publish metadata...

• ...but during development, we need a simulacra of the NYT article template

• we have to be able to create AMP versions of almost every page

• our old app was already fairly Svelte-centric, and we wanted to reuse as much as possible

• we wanted to use client-side navigation to avoid page reloads (while capturing custom navigation analytics) e.g. because it makes no sense to make people load MapboxGL repeatedly

It's possible that we could have coaxed one of the existing static site generators into fulfilling all these requirements, but it seemed like we'd be in uncharted territory without the benefit of having the SSG maintainer on staff!

Post reply on HN