Book updates

[diversable]

In this (larger) commit, several things have been updated in the book as discussed in issue #2007.

1. the DX section has been moved right after the "getting started" section
2. a new section has been added to "getting started" that's all about describing the Leptos community, and where to find the leptos-related crates ie. in the "Awesome Leptos repo
3. this last commit was the biggest one: I have drawn out the inherent structure of the book and explicitly split the book into 2 parts: part 1 on CSR and part 2 on SSR - this structure was already implicit in the text, I've just made it a little more explicit so that people feel like they've accomplished something in part 1 (CSR) before moving onto part 2 (SSR).

This last commit required editing a few sections to make the explicit separation work. I hope you like it, and that it wasn't too much of a large change in one pull request.

(I used to be an English academic & professional editor, before being struck by a debilitating disability and eventually moving into tech; I couldn't help but add a bit more structure to the text)

I've also added a few words here and there in response to questions about the book on Discord - mostly trying to clarify the differences between the CSR and SSR modes.

[reedwoodruff]

A couple of suggestions 👍

[gbj]

Thanks for all your work! I left a bunch of notes in comments while reading through it.

Higher-level notes:

• I think the restructure makes a lot of sense.
• Thanks for the added content, this is really great.
• I tend to avoid "universal" as a term for SSR/hydration. I understand it's used fairly widely, but to me it conveys both too little information ("universal" doesn't tell me "oh, this renders to HTML on a server") and claims too much (there's no sense in which actually "universal"). You may have a broader experience/perspective than I do and if you think it's a useful term for communicating what's going on to people than I'll yield to your judgment. (Also, maybe I just have too much painful baggage from trying to set up Angular Universal in early 2020 :-p)

I really appreciate your energy for this work. Thanks again!

[gbj]

a great option if you just want to make a snappy website with Leptos

a great option for building a CRUD-style website

I think these two lines could be communicating the difference between the two options a little more clearly, or maybe I mean more technically. Looking at the current version of this in the book I see that I say nothing about the difference between CSR and SSR, so I think the idea of expanding it is good. If I were to describe the distinction between the two, I'd say:

• CSR with Trunk: Compiles your application to WebAssembly that runs in the browser like a typical JavaScript single-page app (SPA). This builds fast, has a simple mental model, and is great for apps using a pre-existing server or API. Its drawbacks are slower initial load times and worse SEO.
• Server-side rendering and hydration with cargo-leptos: Compiles your application both to be rendered to HTML on the server, and to become interactive in the browser. This enables close integration with an Actix or Axum server and the best performance for initial load times and SEO, but has a slower iteration loop (because you need to recompile both the server and browser halves) and some added complexity around hydration.

[diversable]

In addressing this note, I've tried to:

• first, give a quick intro to which option to use in a particular case
• then, describe some technical details of CSR & SSR respectively
• last, list both the advantages and disadvantages of each option.

let me know what you think

[diversable]

• I tend to avoid "universal" as a term for SSR/hydration. I understand it's used fairly widely, but to me it conveys both too little information ("universal" doesn't tell me "oh, this renders to HTML on a server") and claims too much (there's no sense in which actually "universal"). You may have a broader experience/perspective than I do and if you think it's a useful term for communicating what's going on to people than I'll yield to your judgment. (Also, maybe I just have too much painful baggage from trying to set up Angular Universal in early 2020 :-p)

Thanks for the notes!

re: the terms "universal" & "isomorphic"

Now that I've reviewed the websites of major full-stack frameworks (Dioxus, Perseus, Next.js, Remix, Sveltekit, SolidStart, etc), it makes sense to drop "universal" and stick with the term "full-stack", so that we're in line with others.

We might also consider removing the term "isomorphic", since in the JS community the term "'isomorphic" tended to cause a lot of confusion. See this thread from the React.js project about dropping 'isomorphic' in favour of 'universal' -- I think we should just stick with "full-stack" and "SSR" for now, imho. What do you think?

Adaptable?

With full-stack wasm already supported in Leptos, future wasi support, and the new, incoming renderer for v0.6, we may need to think up a better / different term to describe Leptos' rendering capabilities though... (?)

The WASM & WASI communities tend to use the term "portable" most often on their websites, but perhaps there's a more fitting term for Leptos? Using something like 'adaptable rendering' / adaptable SSR might work, perhaps, but there are probably better options.. or we could just stick with full-stack.

If you have any ideas, I'm all ears

[gbj]

Awesome! Thanks, I will merge this and then move the book over to the new repo.

For context re: "isomorphic": I am ultimately fine with any term here that you and others decide is reasonable. I tend to use "isomorphic" in the specific sense of "having the same shape," so I say server functions are "isomorphic" because they have the same "shape" when called on either the server or client -- likewise with SSR + hydration, the view tree/tree of components and elements has the same shape on the server and client.

But mostly I'm just fond of it because I've been reading ancient Greek for a long time and so the name makes perfect sense to my brain (isos = equal/same, morphikos = relating to a shape). I recognize that I've had an... unusual path here and it may not make the same sense to other devs 😅

[diversable]

Awesome! Thanks, I will merge this and then move the book over to the new repo.

For context re: "isomorphic": I am ultimately fine with any term here that you and others decide is reasonable. I tend to use "isomorphic" in the specific sense of "having the same shape," so I say server functions are "isomorphic" because they have the same "shape" when called on either the server or client -- likewise with SSR + hydration, the view tree/tree of components and elements has the same shape on the server and client.

But mostly I'm just fond of it because I've been reading ancient Greek for a long time and so the name makes perfect sense to my brain (isos = equal/same, morphikos = relating to a shape). I recognize that I've had an... unusual path here and it may not make the same sense to other devs 😅

I don't know you were a reader of classical languages - very cool! I spent several years reading Latin, myself..

I don't think we need to rip out references to "isomorphic", but the potential for confusion is something to keep in mind.

As you get closer to releasing the new renderer, then we can figure out the best way to describe it in a way that intuitively makes sense..