Readit Newsnaansequitur commented on Thoughts on Svelte tyhopp.com/notes/thoughts... · Posted by u/naansequitur
> Svelte gives you an elegant way to use CSS in your components with <style> tags, why not implement transitions and animations in CSS there?
Because CSS has no hooks into HTML lifecycle. If you want to nimate something that appears in the DOM, or disappears from the DOM elegantly, CSS ain't it.
That's why almost every single framework outside Svelte struggles with animations and employs increasingly bizarre and brittle workarounds to make them work.
Author here, thanks for the context.
Added an update to the end of the article linking to this comment - https://tyhopp.com/notes/thoughts-on-svelte#update-2023-03-2...
naansequitur commented on Thoughts on Svelte tyhopp.com/notes/thoughts... · Posted by u/naansequitur
I switched my game's UI from Vue2 to Svelte maybe a year ago, and I agree with almost all of the article.
One thing I think the author overlooks: the appeal of Svelte's built-in animations and transitions is that they work correctly when the element's lifecycle is being managed by Svelte. E.g. with code like this:
{#if showFoo}
<div transition:fly={{ y: -50 }}> Foo! </div>
{/if}
Author here, this is a great point.
Added an update to the end of the article linking to this comment - https://tyhopp.com/notes/thoughts-on-svelte#update-2023-03-2...
naansequitur commented on Adobe to acquire Figma for $20B bloomberg.com/news/articl... · Posted by u/caoxuwen
The forward looking statements disclaimer at the end of their announcement post is such a sharp tone shift it's almost funny - https://www.figma.com/blog/a-new-collaboration-with-adobe/
naansequitur commented on Show HN: A static site generator built for longevity prpl.dev... · Posted by u/naansequitur
I love this. I have used Eleventy, Hugo, Gatsby, and Jekyll. All of them feel like overkill. I want to write my own HTML. I want to write posts (and maybe some simple pages) in markdown. And I want to be able to render a list of posts/individuals posts. This hits all of those in a really simple package. Nice work!
Thanks for the kind words!
naansequitur commented on Show HN: A static site generator built for longevity prpl.dev... · Posted by u/naansequitur
Or just write HTML, save to file, done.
I take that approach too if the site is small enough.
The challenge is if the site starts to get into the hundreds of pages and you want to be able to reuse templates and/or render lists of content. Then you reach for a static site generator.
naansequitur commented on Show HN: A static site generator built for longevity prpl.dev... · Posted by u/naansequitur
Really like what you are going for here. I've actually been working on a similar system of a minimalist static site generator off and on for about a year. Looking forward to having a more in depth look at your approach.. and congrats for putting it out there, I've been letting my imposter syndrome keep me from publicly showing my system off. I really dig your templating system, I ended up going with Handlebars but I always planned on removing it at some point. Are you using grey matter for parsing the markdown metadata or did you create your own parser?
Hey thanks! Can definitely empathize with the imposter syndrome, it's a tough hurdle to clear.
For the templating system I decided to also add an option to define your own if you don't like the [] syntax (https://prpl.dev/api#options). Figured since the system is regex-based instead of AST-based there's no reason not to expose it as an option to users.
For the metadata I implemented a basic parser. Here's a link to that part of the source code, it's not the most efficient nor does it cover all the edge cases, but it's simple enough it can be easily updated (https://github.com/tyhopp/prpl/blob/master/packages/core/src...).
Good luck and hope I can see your system on HN someday too
I agree that it can quickly cause confusion, but I can’t really think of a situation where it can’t be avoided.
I find it useful for simple things but try to avoid it when the dependency graph gets more complicated.
I haven’t built any large-scale Svelte applications but since reactive labels are by definition local to the component (it’s a compiler feature, and each component is compiled independently), I’m not sure why it would cause more issues at scale.
EDIT: Maybe they’re thinking of the reactive store syntax, which is harder to avoid but much less of a brainteaser. But that’s really a completely different feature that happens to use the same character.
For the part about increasing potential for bugs at scale, my mind was on scaling one or more teams and projects. Might have been better to use some other word than scale since it's so overloaded.
I find it difficult to think of patterns to introduce that would help teams align on when and how to use reactive `$` statements.
It's not a Svelte-specific problem by any means, but I do think Svelte's reactive statements would cause more pain than it would help ease as teams and projects get larger.