Hey all, Elder.js author and maintainer.<p>Elder's main "opinionated-ness" comes from the fact that we're going to put SEO decisions above all others.<p>This includes doing things such as:<p>* partial hydration<p>* no client-side routing wiz-bang<p>* 0kb JS if there are no hydrated components<p>* and several other tradeoffs.<p>It was also built as an SSG first and it is really good at building very large sites (faster than Hugo). [0]<p>Happy to answer any questions. Here is an overview of the "whys" behind many of the uncommon decisions Elder.js made. [1]<p>---<p>[0] <a href="https://github.com/Elderjs/elderjs/discussions/166" rel="nofollow">https://github.com/Elderjs/elderjs/discussions/166</a><p>[1] <a href="https://nicholasreese.com/lessons-from-building-a-static-site-generator/" rel="nofollow">https://nicholasreese.com/lessons-from-building-a-static-sit...</a><p>Edit: format/add links
This guide is nicely written but uses jargon that people who haven’t been keeping up with client and server-side JavaScript frameworks won’t be familiar with, including “route,” “slug,” and “hydration,” not to mention “Svelte” and “SEO.”<p>It seems fine for its intended audience, but if they wanted to help out beginners who somehow stumbled onto this page, adding some outgoing links to definitions where these terms are introduced might be useful.
This is cool. I just shipped an app using Svelte [1] and I liked working with the framework. I would be interested to work with it more.<p>My app replaces Safari's new tab page with a wallpaper and weather widget. Obviously performance is crucial for this - your wallpaper needs to appear immediately after you hit Cmd-T.<p>Svelte was a nice way to get the benefits of a component-based framework while still shipping only a tiny JS bundle to customers. It has some rough edges, but it's cool to see the community fill out the gaps with tools like this.<p>[1]: <a href="https://apps.apple.com/us/app/beautiful-new-tabs/id1567068235" rel="nofollow">https://apps.apple.com/us/app/beautiful-new-tabs/id156706823...</a>
Quite the fan of Elder.js; I build my personal site using it (<a href="https://alexanderobenauer.com" rel="nofollow">https://alexanderobenauer.com</a>), where the entire site is built once, each time I push a change, then hosted on static hosting (Netlify).<p>The flexibility on how routes map to various files and templates is wonderful. Some routes are simply markdown files (copied directly from my notes app) that are then rendered into the right template file.
Hi Nick, just saw your svelte summit presentation you gave and was pretty impressed with Edler.js!<p>I have a simple site, basically 5 different templates. 2 of those templates will be used for content of ~500 pages each. So Elder was exactly what I was looking for.<p>However:<p>I want to re-hydrate my server-side rendered app/dynamic-parts <i>including client-side routing</i>.<p>Elderguide (and in the YT talk) mentions that for more complex SPA-y stuff I shouldn't use it. I played around with Elder but finally settled on Routify, because it gives me re-hydrated client-site routing out of the box. SvelteKit I haven't looked into at all because they released it just when I was done with my app ;-)<p>Would you mind elaborate how Elder's feature differ from SvelteKit?<p>Thank you!<p>PS.: Even if my use-case might isn't a fit, I think the use-case's where Elder would be my first choice are pretty clear.
> A Highly Optimized Build Process: that will span as many CPU cores as you can throw at it to make building your site as fast as possible. For reference, Elder.js easily generates a data intensive 18,000 page site in 8 minutes using a budget 4 core VM.<p>How does this compare to something like Hugo?
Big fan of Svelte an and was super-exited to find a static site generator that uses Svelte templates. Actually just released a redesign of my personal site using Elder.js today and am looking forward to using it for more projects in the future.<p>My site: <a href="https://apop.tech" rel="nofollow">https://apop.tech</a>
GitHub repo: <a href="https://github.com/apop880/apop-tech" rel="nofollow">https://github.com/apop880/apop-tech</a>
Previous built static sites with Jekyll (ruby) and most recently moved to NextJS + strapi.<p>This project looks like exactly what I was really after, 100% seo optimised / prioritised + all SSG. Will definitely give this a shot for the next project.<p>Appreciate the effort!
Do you support full pre-rendering?<p>Let's say I have 100 blog posts - can each of them be pre-rendered into HTML and stored on a CDN? Thereafter if I change a sentence in one of them, can it only recreate the one HTML that was changed?
I still find front end JavaScript development to be a chore, the least appealing part of any project idea, despite actually liking Working with HTML and CSS… it’s not even really JavaScript as a language.<p>It’s the ecosystem I don’t like. I read about “opinionated frameworks” and for a backend framework that tends to be something like Django or Rails, frameworks built to give you everything top to bottom, with clear layering and extension points. However for front end frameworks opinionated seems to mean “has more indecipherable lisp/scheme function/macro style logic” that does what the original author designed it for wonderfully but is a royal pain to extend, modify or really build off in any way other than just forking it.<p>I’d call this a “framework for sites where SEO is critical” not really an “opinionated framework” it’s more of a “single issue framework” to borrow a political term”<p>The only “opinionated framework” I’ve ever used in the front end/JavaScript world that felt like a cohesive, truly opinionated framework in the backend Django/Rails kinda way is EmberJS. Which I highly recommend to people who hate the whole JavaScript ecosystem churn. About the only negative I can highlight was poor IDE tooling with older versions which the most recent releases have improved on their end, but is for the most part an issue of IDE developers like JetBrains not considering EmberJS as important as the Angular family and the React, Vue, and other JSX based system family. Which I can understand for the most part due to business realities, but also this is hardly a good reason not to try something when the tools have full auto-reload and progressive compilation to efficiently test things in the browser as you make changes in any text editor you like.
This is very appealing considering the limitations of client side hydration svelte still has – though I wonder where this stands in relation to the upcoming release of SvelteKit.
How does this compare to something like SvelteKit with an adapter to generate a static site? I don't know much about Svelte, so maybe my question is weird.