rich_harris

10 ms·

31.
by rich_harris 3y ago
Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mi
32.
by rich_harris 3y ago
As we've taken to saying around the virtual Svelte offices: > The magic of Svelte isn't `let count = 0`, it's `count += 1` That part hasn't changed!
33.
by rich_harris 3y ago
> it looks like it’d be needing to do quite a lot of control flow analysis Implementation-wise, this is vastly simpler than Svelte 4, because everything is explicit. One thing we didn't really show today is how this works in your ed
34.
by rich_harris 3y ago
Svelte 3 came out in early 2019, and the framework hasn't really changed much in that time — one thing we can't be accused of is making changes for changes' sake. But since then, the front end community has discovered valuabl
35.
by rich_harris 3y ago
As swyx said, it's probably not a priority for us. You can basically get the same benefits by using Incremental Static Regeneration, which is turnkey if you're using Vercel (not through any tight framework<->platform integra
36.
by rich_harris 3y ago
<3
37.
by rich_harris 3y ago
Svelte 4 was a complete structural overhaul of the `sveltejs/svelte` repo — turning it into a monorepo, converting all the `.ts` modules into typechecked `.js` files, etc, modernising our dependencies and our workflows, dropping CJS an
38.
by rich_harris 3y ago
Alright, since HN is doing its tedious grumpy-old-man thing, let me just spell this out: Your old Svelte components will continue to work. There'll be some 'breaking changes' in the persnickety semantic versioning sense, but
39.
by rich_harris 3y ago
Because of a little thing called semantic versioning. A change can be 'minor' in the sense that it doesn't really affect how the vast majority of users use your package, but still have changes that are technically breaking.
40.
by rich_harris 3y ago
If those libraries were set up correctly, this would cause typechecking to fail.
41.
by rich_harris 3y ago
appreciate the insightful comment
42.
by rich_harris 3y ago
This is a non-issue in practice — complex types can be expressed in .d.ts files and imported. SvelteKit (not Svelte) has been doing this for a long time and it's fine.
43.
by rich_harris 3y ago
You are making judgements based on a draft PR. There is a ton of work still to do.
44.
by rich_harris 3y ago
Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions whenever this stuff comes up! If you're rabidly anti-TypeScript and think that
45.
by rich_harris 4y ago
Svelte creator and Vercel employee here. Vercel does indeed invest heavily in Svelte and SvelteKit, not least by employing me and Simon Holthausen (and potentially others in future), but there's no danger of lock-in — we're just t
46.
by rich_harris 5y ago
The short answer is that you'd use Svelte Cubed for the same reason you'd use Svelte (or indeed any component framework) itself: declarative code tends to be more robust, readable and maintainable than imperative code. There&#x27
47.
by rich_harris 5y ago
I understand this perspective! But as anyone who knows me will tell you, I would be the worst person in the world to try and build a business around Svelte. As others have said, the expectations from investors would make it far less likely
48.
by rich_harris 5y ago
Firstly, as the article emphasises, _diffing_ is far from the only issue with virtual DOM. And this isn't about microbenchmarks; plenty of people have run up against React's performance limits in real world applications and have h
49.
by rich_harris 5y ago
FWIW, this Twitter thread addresses this issue: https://twitter.com/Rich_Harris/status/1305925515472261122 . I certainly didn't _invent_ the term 'treeshaking', I merely (unwittingly) helped populari
50.
by rich_harris 6y ago
Yes
51.
by rich_harris 6y ago
Not concrete plans but I expect it will happen, yes (at the very least in the sense of having an `adapter-deno` to allow the built app to run in Deno; running SvelteKit _itself_ in Deno is a separate issue)
52.
by rich_harris 6y ago
Not currently, but this will be implemented soon (and certainly before 1.0) https://github.com/sveltejs/kit/issues/231
53.
by rich_harris 6y ago
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 so
54.
by rich_harris 6y ago
oh, does PHP include a client-side router these days? that's exciting!
55.
by rich_harris 6y ago
Added a paragraph to the blog post: > Think of it as Next for Svelte. It's a framework for building apps with Svelte, complete with server-side rendering, routing, code-splitting for JS and CSS, adapters for different serverless pla
56.
by rich_harris 6y ago
That's a Svelte issue rather than a SvelteKit issue. It's on our _radar_, though I don't know if I'd say it's on our _roadmap_ just yet
57.
by rich_harris 6y ago
This blog post gives a bit more information on that: https://svelte.dev/blog/whats-the-deal-with-sveltekit , though the section on Snowpack is out of date. Basically, SvelteKit is serverless-first (whereas Sapper made y
58.
by rich_harris 6y ago
I think you're thinking of module bundlers, which need to be able to resolve the import statically in order to do code-splitting etc. There's no such limitation at runtime.
59.
by rich_harris 6y ago
This is a nonsense claim. We don't provide an 'officially sanctioned' way to test components because we think that unit testing components is usually a waste of time. But Svelte is no less testable than any other framework
60.
by rich_harris 6y ago
Rollup isn't going anywhere! When you poke behind the scenes of newer build tools, like Snowpack and Vite and the custom compiler that powers Remix Run, you'll find Rollup doing a lot of the heavy lifting. And it's the prefer

More ›