Pretty happy user here as well! I actually used your source code as reference to build my personal site [redacted], so thanks for open-sourcing!
One issue I have with elderjs (with the version that I'm using - haven't been up to date), is that hot-reloading with rollup seems to cause issues with css. The experience is not as smooth as per say nextjs fast-refresh, but I'm content with it for my use-case.
I'm a bit confused about these benchmarks, especially those regarding Hugo. I remember watching a video[0] all the way back in 2015 where Hugo was able to create 5000 pages in roughly 6 seconds. It feels odd that it would take more than 13 times as long to build twice the amount of pages now. Considering that the benchmark you linked to was using newer hardware, and a faster version of Hugo. I guess the benchmark itself might be very different, but it still feels like a huge performance drop.
Anyway, Elder looks very promising, and I like the idea of using Svelte a lot more than working with Hugo templates. What do you think is the main thing that limit the built time for smaller sites?
To be honest, I'm not familiar with the specifics of the benchmark. I was surprised as well.
Currently I think the biggest limiter for small sites is that we sequentially fork the processes and wait for each to bootstrap.
I'm sure we could eek out a huge gain by rewriting it and optimizing, but at this point it is faster than anything else in the ecosystem and throwing more CPU cores at a problem is cheaper than throwing more development hours at the problem. :)
I guess I am not caught up on hip terminology. Can you explain what this means to someone who authored his first web site in 1993 on a NeXT Cube what that means?
In front end JS frameworks there is a tendency to render your site on the server, then also ship JS to the client which then takes over the rendering of the page and adds interactivity.
As you can guess this adds a lot of overhead.
Partial hydration allows the developer to specify which parts of the page have interactivity and only those parts of the page are made interactive.
I was just surveying the terrain for an SEO-dependent static site with headless CMS, so it's nice to have a framework with that particular focus to consider as part of that mix. Thanks!
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.”
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.
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.
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.
Quite the fan of Elder.js; I build my personal site using it (https://alexanderobenauer.com), where the entire site is built once, each time I push a change, then hosted on static hosting (Netlify).
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!
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.
However:
I want to re-hydrate my server-side rendered app/dynamic-parts including client-side routing.
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 ;-)
Would you mind elaborate how Elder's feature differ from SvelteKit?
Thank you!
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.
To be honest, I've only briefly played with SvelteKit as it still isn't finalized.
Here are the main parts where Elder.js stands out
pros:
* Purpose built for large sites with SEO in mind.
* Hooks and plugin ecosystem for common issues. Responsive images, sitemaps, critical path css, etc.
* 0kb JS and partial hydration.
* Blazing fast builds.
* Async shortcodes make working with and future proofing static content a breeze.
cons:
* The complex Rollup implementation needed for partial hydration leads to less optimal dev experience. HMR isn't a possibility as it currently stands. Until `esbuild` is stable reloads won't be as fast as with Vite.
* Unfamiliar way of handling routing / no dynamic routing. (PR to simplify this is basically done [0])
* No client side routing.
* Less optimal for "apps" and logged in experiences until this PR is merged. [0] This should happen in the next week.
> 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.
Eight minutes!? That’s over 100ms of CPU time per page. I’m baffled and more than a little horrified that you would call that highly optimised. I would honestly expect anything calling itself highly optimised to be doing that in closer to 8 seconds. 1.7̅ms is ample for something carefully put together, probably even in JavaScript and with a database (fetch everything up front in one or so queries), though it’ll certainly be easier in a language like Rust. I admit I’d be decidedly impressed by a reasonably-featured JavaScript SSG doing 18,000 pages in 8 seconds; but more practically, in a JavaScript ecosystem, I’d be targeting definitely under a minute.
I will admit I’ve grown used to Rust code and code that’s been designed to be fast. (Zola’s not that, by the way; it makes many decisions in favour of subjective ergonomics and flexibility at enormous runtime cost, as well as doing a lot of theoretically-unnecessary cloning and such all over the place, which could speed things up a lot if it were sorted out somehow (I haven’t contemplated the matter). For my own website with some admittedly very complex templates, and that’s probably Zola’s slowest part, it’s scaling at about 2ms per page with a warm disk cache. Actually, it does some multithreading, but much of the most expensive stuff in the process isn’t parallelised, so repeated runs average using almost a quarter of my 16-thread laptop. I feel I should multiply that 2ms by something, but I’m not sure quite what!)
Edit: Later on the page: “As of October 2020, ElderGuide.com has ~20k pages and builds in 1 minute 22 seconds.” 4ms wall time (16ms if still operating on four cores) is much more encouraging. I guess the page could do with revision. Later still, “Build times on our ~20k page site are routinely less than 10 minutes on a modest VM.” which seems to be the first set of figures again.
General rule of thumb with databases is to reduce the number of queries. Fetch large batches of information. This can be difficult to arrange with how such systems are commonly built and/or coded; some sort of intermediary between the consumer and the database can be warranted, which you can tell, “oh btw, these are the items that I’m going to want, d’you mind just fetching them all now so you can hand them directly to the consumers when they ask for them rather than issuing a new query for each?” In a well-done system like this, the database will be a minor component in the performance—templating and other JS-side transformations are much more expensive than fetching easily-identified rows from a database that’s been designed to handle zillions of requests per surprisingly-small-unit-of-time.
I’m curious what fraction of the 1m22s it now takes is waiting for the database.
Building performance tracking into the product? Good job! That shows me that you’re genuine in caring about it, which is still more encouraging. I’m going to investigate Elder.js.
> much of the most expensive stuff in the process isn’t parallelised
Are you sure? Markdown and template rendering of all pages/sections and image processing is done in parallel. I expect those to be the most expensive stuff. The things that are currently done sequentially are taxonomies (an oversight, the pages in them are rendered in parallel) and the search index generation (oversight as well).
No, I’m not sure; I apologise for being wrong (since you know what you’re doing). I just went searching for signs of threading and rayon and thought I was only finding it on the earlier parts of the process and image stuff. But I wonder why repeated runs of `zola build --drafts` on my site with no images for it to process average less than 25% of total CPU usage? I would have thought >170ms was long enough for it to hit its stride inside each process.
That's pretty impressive. Hugo appears to have a steady growth in overhead right up until the point where elde.js overtakes it when the number of pages hits 10,000.
SvelteKit's offering is great. Much better than Sapper. For Vite the HMR on SvelteKit is better than Elder.js but SvelteKit doesn't offer Partial Hydration.
The main difference is Elder.js is designed for static sites and offers tools to help make building large static sites easier.
For instance, when it comes to building non-trivial static sites, there is a lot of data massaging that needs to happen and be in sync across the entire project. A good example is when reading from a headless CMS or generating a sitemap.
With Elder.js, you can massage this data once and add it where you need to via a hook and it will be available on all pages.
SvelteKit is less opinionated. It is apples and oranges.
Can't you do partial hydration by setting certain components to not hydrate inside the <script context="module'>? Thats what it says in the docs but it might not be the same thing in my understanding (which is limited). Also aren't app-wide stores basically the least trivial way of keeping data in sync across an app? Certainly not difficult in SvelteKit as it is - in fact I can't imagine it being any easier.
No, SvelteKit does not have support for partial hydration.
What you're describing is the no js option in SK. That doesn't allow you to selectively add some JS, it's either all or nothing. You set this option on a per page basis, not per component.
The massaging of data that Nick talks about here has to do with data that is needed to build the actual pages, not runtime data (which you could use Stores for).
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.
Previous built static sites with Jekyll (ruby) and most recently moved to NextJS + strapi.
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.
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?
Elder.js is designed to render the entire site at a time. 100 pages should take substantially less than 10s in most CI/CD pipelines.
We refer to what you are looking for as incremental builds and it is honestly a pretty difficult problem as it requires tracking data dependencies. Here is an overview of the complexities. [0]
"Opinionated" means the software has made very deliberate design tradeoffs and is very inflexible/resistant to changing that. This is done to optimize certain objectives like software scope or increasing productivity by enforcing certain methods.
So in this case they cited "no client-side routing wiz-bang" -- that's one of their opinions and won't be introducing any support for that sort of thing.
The classic example is Python's motto "There's Only One Way To Do It", which was in a response to Perl's "There's more than one way to do it."
Another example is Ruby On Rails...it has a strong opinion on how the application should be structured -- must be MVC, most of your code should be in a model, convention over configuration, etc.
Generally, rather than trying to be a generic framework/tool/system allowing all approaches and preferences and practices, it is optimized for / selects a certain subset toward a (hopefully) stated goal and subset.
It is "opinionated" in the sense that it has an "opinion" on what's the right way to accomplish a certain outcome, and thus it preselects/premakes some choices for you.
The implicit tradeoff is that it may not be as good at general problems / all approaches, but may be better or easier or both for specific goals / approaches.
> and doesn't allow the developer using it a choice in those matters.
I never took "opinionated" software as "no configuration". For me it's always been "custom defaults". It might provide some configuration, it might not, but what makes it opinionated is the fact that the defaults are not generally applicable, but rather tailored for a specific use case.
An example of an opinionated game engine would be idTech 5 (Rage engine). It is built around MegaTexture: a huge, non-repeating texture that maps the entire world, backed by a robust caching system.
It allowed for highly complex scenes, great static lighting and short loading times but it lacked in detail and dynamic elements.
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.
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.
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”
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.
Was just going to say: I have only experienced one thing that branded itself opionionated, which was a CSS (reset) file.
So many unexpected behaviours that were really hard to diagnose.
I am now very wary of things calling themselves opinionated.
Though, simultaneously, where does being 'opinionated' start?
Like, we are all building on top of other things, where, inevitably, certain decisions have been made for us. You have to decide whether you can live with those decisions (people say Go, as a language, is quite opinionated), or whether you are going to fork the language and make your own, hehe
When I see opinionated I assume that the developer made a decision that they like, but they know some people won't like. They are saying up front that they aren't trying to satisfy everyone. They're doing it this way, so don't open up issues asking them to support doing it another way.
Opinionatedness is a good thing when a problem has no consensus solution, yet a decision needs to be made.
If the author correctly identifies the problem and is right about the hard part of the solution and manages to convince other people, the community will accept the unimportant parts as default and discard the important but wrong (by consensus, made possible by the opinionated solution) parts.
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.
Elder's main "opinionated-ness" comes from the fact that we're going to put SEO decisions above all others.
This includes doing things such as:
* partial hydration
* no client-side routing wiz-bang
* 0kb JS if there are no hydrated components
* and several other tradeoffs.
It was also built as an SSG first and it is really good at building very large sites (faster than Hugo). [0]
Happy to answer any questions. Here is an overview of the "whys" behind many of the uncommon decisions Elder.js made. [1]
---
[0] https://github.com/Elderjs/elderjs/discussions/166
[1] https://nicholasreese.com/lessons-from-building-a-static-sit...
Edit: format/add links