Earlier quoted context omitted.
3kB
as compared to nextjs’ ~150kb baseline? (not a real number im just guesstimating)
79.46 kb which includes React. That's never where the bloat comes from.
SvelteKit 1.0
191–200 of 296 posts
Re: SvelteKit 1.0
#192While I like Svelte, I fear it looses some of the flexible API-building enabled by React. Specifically: since it uses a templating system, you can't pass around interface definitions easily: - https://github.com/sveltejs/svelte/issues/3480 (no dynamic slots) - https://github.com/sveltejs/svelte/issues/5381 (can't wrap children) You can always find workarounds for these cases, often using ` `, but React's Javascript/T…
Not sure what you mean by `React's Typescript-centric design`, React used Flow from the very start and also had PropTypes for plain JS. Typescript support came much later.
Re: SvelteKit 1.0
#193While I like Svelte, I fear it looses some of the flexible API-building enabled by React. Specifically: since it uses a templating system, you can't pass around interface definitions easily: - https://github.com/sveltejs/svelte/issues/3480 (no dynamic slots) - https://github.com/sveltejs/svelte/issues/5381 (can't wrap children) You can always find workarounds for these cases, often using ` `, but React's Javascript/T…
Not sure what you mean by `React's Typescript-centric design`, React used Flow from the very start and also had PropTypes for plain JS. Typescript support came much later.
I was thinking about the full power of JavaScript while still being perfectly typesafe.
I edited the comment to hopefully better reflect that.
Re: SvelteKit 1.0
#194Earlier quoted context omitted.
You seem to be conflating a few different concepts. Store are absolutely reactive across all components and pages. They are prefaced with $, and there are a bunch of native stores that you can use such as $page. You can even create variables reactive to one another by declaring a variable like so: $: y = x * 2 Using the export let x = default; option is for passing data from the parent component/page to a child. If y…
For instance I had a variable in a store. On my page, I had a script tag pulling from the store. The variable was reactive within the script tag. I export let that into the template via “data” props. I changed the value of the variable within the script tag. The template did not reflect the new value.
I'm really struggling to follow what you're trying to do - but why do you not just use the same writable store in both your page and template/component?
Also, maybe look into store subscriptions and/or reactive declarations for what you're trying to do.
Regardless, it sounds like you really need to just read the docs or do a tutorial.
Re: SvelteKit 1.0
#195Earlier quoted context omitted.
What would be an example of large scale for a front-end app or site?
complex dashboards like CircleCI or client portals like maybe your bank or health insurance portal many pages and lots of functionality with lots of data floating around like Reddit, Twitter literally everything/anything like Facebook, GitHub, etc For simple apps, I'd go with a PWA if possible. For single, mostly informational, pages you usually just need a static site. For a company blog, some of these tools could b…
BTW, is CircleCI still using ClojureScript + React or they've changed their stack?
Re: SvelteKit 1.0
#196This is how I move fast and break nothing. By having fullstack type-safety from database all the way to the frontend with auto-completion. My current stack: + SvelteKit (could be Next, Nuxt, Solid or any other TypeScript framework) + tRPC (typed calls between frontend and backend, https://trpc.io ) + trpc-sveltekit (glues SvelteKit and tRPC, https://github.com/icflorescu/trpc-sveltekit ) + Prisma (ORM, https://www.pr…
You should also mention Zod, which acts as the type safe glue between the different boundaries. I have been using Google Sheets as a kind of hacky database. By defining the schemas in Zod I am able to automatically validate my sheets data and coerce the string cell values into their proper types. Zod schemas can be used all over the stack, imported for form validation, and avoid heaps of duplication and tests.
While Zod is hyped by Next.ja developers (I think mostly because Theo Brown has such a huge reach), I think Ajv is better, because it lets you generate OpenAPI documentation and it fully json schema compliant.
I really like nextjs for its opinions on the frontend part, but it is lacking these strong, but great opinions on the backend. Wish love to see some design decisions from fastify adopted here. Matteo did really do some great stuff.
Re: SvelteKit 1.0
#197I've been waiting for this for months! Credit to the team. Looking forward to the weekend to play around with it. Also, super excited for svelte 4
Re: SvelteKit 1.0
#198While most of the comments here seem positive… A custom template language is like another programming language to learn (to make mistakes in). I prefer JSX/TSX which is closer to reusing HTML.
Speaking as nearly-exclusively a JSX/TSX user, it is not really true that it is closer to HTML than Svelte's templating. People who like and use Svelte report the opposite.
Agree with this. Iterating with Array.map and returning nodes to compose, say, unordered lists in JSX is most decidedly un-HTML-like.
I can see the drawback to learning yet another templating language, and on this point I’d just say “to each their own”. I feel like either approach is fine. Svelte’s templating is pretty minimal, so there isn’t much to learn.
Re: SvelteKit 1.0
#199Earlier quoted context omitted.
3kB
as compared to nextjs’ ~150kb baseline? (not a real number im just guesstimating)
It’s not directly comparable. Svelte apps have an extremely minimal runtime, because Svelte compiles components into largely freestanding chunks of code.
The benefit is that for smaller apps, SvelteKit can be extremely lean, but the cost grows as the number of components and pages increases, since a number of attributes can’t draw from a larger, monolithic runtime (or set of runtimes).
You do have to build moderately large apps to hit the point at which it’s a drawback however.
Re: SvelteKit 1.0
#200Earlier quoted context omitted.
Yes, it's easy to get confused with folders and folders of +page.svelte [slug].svelte would be better [slug]/index.svelte [slug]/[category].svelte Etc There is a vscode extension that helps a little bit, but it's still the one thing I am not fond of.
The src/routes/posts/[slug]/+page.svelte thing is pretty recent, it used to be just src/routes/posts/[slug].svelte. I'm not exactly thrilled with the new naming...
I left the framework for this reason. When I asked about it, I was told "this is what Next will be doing soon". I need more reasoning than that, and it was indicative of the decision making process. Turned me off. Aside from that, Svelte is SUPER fast and easy to use. I may give it another go at some point.