Skip to content

marketing: new website#3272

Merged
ad-tra merged 50 commits intomasterfrom
new-site
Feb 3, 2026
Merged

marketing: new website#3272
ad-tra merged 50 commits intomasterfrom
new-site

Conversation

@ad-tra
Copy link
Copy Markdown
Member

@ad-tra ad-tra commented Jan 4, 2025

No description provided.

Copy link
Copy Markdown
Member

@Parth Parth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I think a mild readme in pub site would go a long way describing the overall build, tools used, etc.
  • I would prefer to move the public_site into the docs folder.
  • how much effort would light mode / dark mode take? can happen after merge.
  • we should think about what deployment will take, can happen after merge.

Cargo.toml Outdated
"utils/dev-tool",
"utils/releaser",
"utils/winstaller",
"public-site/trunk",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to call this component trunk?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it does make sense for me

}
}
TabContent::Image(img) => img.show(ui),
#[cfg(not(target_family = "wasm"))]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you do this slightly differently you may deliver #2701

tracing-test = "0.2.5"
indexmap = { version = "2.5.0", features = ["rayon"] }
futures = "0.3.30"
web-time = "=1.1.0"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the specific pin?

) -> Result<Vec<u8>, reqwest::Error> {
let response = client.get(url).send()?.bytes()?.to_vec();
Ok(response)
fn download_image(client: &reqwest::Client, url: &str) -> Result<Vec<u8>, reqwest::Error> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolve once someone has checked to make sure this still works fine for the editor.

I recall images being vaguely broken in someway, if it's because of our inability to get them can we just include_bytes! them?

If it's something else maybe graphics related wanna just leave some context.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also see that reqwests has some wasm things going on if it is a networking issue

Copy link
Copy Markdown
Member Author

@ad-tra ad-tra Mar 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it broke the editor. but i fixed it and also fixed it on wasm so we can include images in the demo

strip-ansi-escapes = "0.2.0"
chrono = "0.4"
rand = "0.8.4"
getrandom = { version = "0.2", features = ["js"] }
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this remove rand? rand does support wasm iirc. Rand has cryptography implications iirc. Will continue to review.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same for git-lfs for these assets, maybe all pngs in this folder. Or you can pursue more aggressive compression. The overall repo should be fast to clone. There's some historic cleanup we have to do anyways. Cloning the repo is something a lot of scripts / CI / installers do.

.gitattributes Outdated
Comment on lines +5 to +7
*.jpg filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.jpeg filter=lfs diff=lfs merge=lfs -text
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these are ideally constrained to the public_site directory I don't want to break workspace logo or something like that

jsonwebtoken = "8.2.0"
x509-parser = { version = "0.15.0", features = ["verify", "validate"]}
db-rs = "0.3.1"
db-rs = {git="https://github.com/lockbook/db-rs"}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0.3.2 was published you can probably refer to this normally now

@Parth
Copy link
Copy Markdown
Member

Parth commented Mar 26, 2025

@ad-tra can you go through and resolve what you feel like you've completed? I checked a few things and found mixed results

@Parth
Copy link
Copy Markdown
Member

Parth commented Mar 26, 2025

@tvanderstad can you do a pass over the editor bits?

Copy link
Copy Markdown
Contributor

@tvanderstad tvanderstad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this feels like it creates a small mess in order to deliver the feature quickly. I'm on board if we can align on a target state and a timeline to achieve it, and I'm down to do my part.

Here's a pitch to get us started:

  • Let's aim to drop WASM support for lb-rs and workspace, where the undue portion of the mess is concentrated imo, and instead ship just the editor and canvas modules (with simple wrappers if necessary).
  • I can start by factoring dependencies on lb-rs and workspace out of the editor. I'll just have it accept an optional FilePathResolver of some kind so we can resolve relative links in our apps and not depend on lb-rs in WASM (a feature I want to add anyway). I'll move any workspace helper functions to wherever I need to to make it happen. I'll aim to finish by the end of this quarter (2025 Q2).
  • You can apply the same pattern to canvas like we did with collaborative editing, then revert the lb-rs and workspace changes that were needed to support those in WASM, aiming to finish by end of Q3.

These timelines are approximate. Basically I see some of the changes as tech debt - the conditional compilation forces me to basically maintain two programs simultaneously which has been a bad time in the past - but we only pay interest on that tech debt when we're maintaining or building on that code. For example, if we want to up our persistence game and persist scroll positions in open files, we'll be reminded that PDFs are only present in the workspace content types enum for some targets. So here I'm saying Q2 or Q3 as a guess for "when is the next significant change to something affected by the debt" or possibly "when is the next engineer to onboard to the code affected by the debt".

bincode = "1.3.3"
time = "0.3.20"
diffy = "0.3.0"
db-rs = {git="https://github.com/lockbook/db-rs"}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this intended to stay this way? also, nit: formatting

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not intended, the change has been released

where
F: Future,
{
block_on(future)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I prefer to qualify instead of import a raw fn like this. There are a lot of block_on's happening around here

Suggested change
block_on(future)
futures::executor::block_on(future)

let start = Instant::now();

// let guard = tokio::time::timeout(std::time::Duration::from_secs(1), self.db.read())
// let guard = web_timetimeout(std::time::Duration::from_secs(1), self.db.read())
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: probably-unintended comment change

Comment on lines +73 to +74
#[cfg(not(target_arch = "wasm32"))]
thread::spawn(move || {
Copy link
Copy Markdown
Contributor

@tvanderstad tvanderstad Apr 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we have used something from futures, the way you managed the blocking behavior in lb-rs, to make the functions in this file async whether they're wasm or not? Then we wouldn't need two versions and I imagine this diff would be much cleaner (if yes I can make the change later)

@Parth
Copy link
Copy Markdown
Member

Parth commented Apr 17, 2025

Alternatively -- we could explicitly support wasm. I think there are situations where a web app makes sense and it would be annoying to factor all those things out of the editor and canvas for effectively no reason long term.

I think this forces us to do things the wasm way for the wasm situation, but my ideal investment would be to understand if these are just fundamentally the right ways to do these things anyways? Is it more correct for something like lb-rs (which has no main method) to just depend on a general futures implementation rather than forcing a tokio one, for instance.

But broadly I'm aligned on mess reduction happening in this quarter if this is merged.

I think this would still be a reasonable state for the standalone editor, lb-rs would go to resolve a link and find that you're not logged in and would not resolve the link if it's lb://.

@Parth
Copy link
Copy Markdown
Member

Parth commented Apr 17, 2025

And I'm down to make the lb-rs support of wasm my problem.

@Parth
Copy link
Copy Markdown
Member

Parth commented Apr 21, 2025

we chatted after standup and basically I think both things are going to happen

  • for standalone editor he'll abstract out lb, because
  • lb will also just support wasm
  • canvas can go either direction

but either way you should rebase and merge this

@Parth
Copy link
Copy Markdown
Member

Parth commented Apr 21, 2025

@tvanderstad I'm assuming you're certifying the editor changes

@Parth
Copy link
Copy Markdown
Member

Parth commented Apr 21, 2025

@ad-tra I would ideally merge this after wed's release

@Parth
Copy link
Copy Markdown
Member

Parth commented Jul 30, 2025

nix-release depends on public-site/favicon.svg existing, I can update this before you merge but we must correct it before a release.

@Parth Parth mentioned this pull request Feb 1, 2026
@ad-tra ad-tra merged commit 07f12e4 into master Feb 3, 2026
1 check passed
@ad-tra ad-tra deleted the new-site branch February 3, 2026 05:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants