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.
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.
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
This is an open source project I've worked on over weekends for a long time. The goal is to create a tool well suited for websites you expect to be around for 5 or 10+ years.
Would love any thoughts you have on it.
The reason why I decided to build this is all other (JS-based) static site generators I tried had one or of these problems:
- Built on an underlying framework like React, Vue, etc.
- Relies on complex build tools like Webpack, Babel, etc.
- Depends on a massive tree of modules that force constant maintenance
- Has interfaces, source code and documentation that cannot be understood in one sitting
- Requires that your site source be organized in a way that looks nothing like your output
- Forces a huge leap from hello world to a real world implementation
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.