Elder.js – An Opinionated, SEO Focused, Svelte Framework
elderguide.com
elderguide.com
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
Looks awesome, can’t wait to try it out.
We're building ElderGuide.com (a nursing home directory) which has 18k complex pages in about 1 minute 22 seconds.
Re: https://elderguide.com is that where the Elderjs name comes from?
https://swyx.io/ and source code: https://github.com/sw-yx/swyxdotio/
and it is working great for SEO/performance despite me layering on some extra js for tweets and youtube links and the like.
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.
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?
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?
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.
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.
I highly recommend Svelte, though.
"beginners" is a very broad term. You have to write for _somebody_ or your text engages no one.
If even the front end framework Svelte is new to you, that's hint you'd likely learn more by checking out Svelte.
It's not realistic to expect a project to spell out everything for a complete beginner.
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.
[1]: https://apps.apple.com/us/app/beautiful-new-tabs/id156706823...
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.
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.
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.
---
How does this compare to something like Hugo?
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.
edit: a word.
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).
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.
In that example most of it was waiting on the remote database. (I’m ans SQL newb).
That said, Elder.js makes it easy to see what is causing performance hits with full perf tracking.
These days that same site is 1 min 22sec.
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.
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).
Your calculation seems wrong.
(8×60×1000)/18000 = 26.666667 milliseconds per page
My site: https://apop.tech GitHub repo: https://github.com/apop880/apop-tech
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.
Appreciate the effort!
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?
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]
It allowed for highly complex scenes, great static lighting and short loading times but it lacked in detail and dynamic elements.
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.
That said, I think it'd be really difficult to work around Elder.js' opinions.
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.
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.
Lots of Svelte users asked how I built the site so I figured it was worth open sourcing.
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.
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
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 an excellent and concise way to sum it up.
> opinionated — I don’t believe that your use case exists.
> elegant — The only use case is making me feel smart.
> lightweight — I don’t understand the use-cases the alternatives solve.
https://programmingisterrible.com/post/65781074112/devils-di...
So far the links from the JS ecosystem seem to be confusing Google's algos, but we'll give it more time to see how it plays out.
between the two they honestly reflect all the most relevant site rendering strategies today.