What are the security implications of running React on the ZK website? Is that going to mean additional concerns (eg cve tracking as well as source security bugs, tracking the "latest react" version and so on...). I believe right now we just have very simple static pages which require very minimal oversight?
Regards, Patrick On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk < [email protected]> wrote: > Thanks everyone for your reviews! > > The only approach I considered for updating the documentation version is a > manual one. It looks like this: > 1) Checkout to the `website` branch. > 2) Build the latest change for the current version, right before the > update. > 3) Move the build to `public/released-docs/` and rename the directory to > the corresponding version. > 4) Update the `CURRENT_VERSION` constant, so now it matches the new > version. > 5) Open a PR. > > The Java API docs are built by maven as far as I can tell, so it's not > related to the website actually. > > Regarding the automatization of this process, I've never done anything like > this before. Therefore, if you have any suggestions - I'm open to it, I > think it should be possible since the workflow is not complex at all. Most > likely a small bash script could be enough. > > Best Regards, > Yurii > > On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár <[email protected]> wrote: > > > Exactly. My 2 cents are: > > > > 1. Storing the entire website at a single location is desirable. Given > the > > proposed > > technology changes there’s no clear separation possible without > duplicating > > website core logic components which will be a maintenance nightmare in > the > > long term. > > > > 2. Separate ‘website’ branch or versioned branches. As Patrick mentioned > > the docs are versioned and the ability to accompany doc changes with > > code changes in the same PR is a big advantage. > > > > Andor > > > > > > > > > > > On Mar 30, 2026, at 19:52, Patrick Hunt <[email protected]> wrote: > > > > > > One reason I remember the docs/api/etc... are part of the source is > that > > > they are versioned along with it. PRs -- doc changes along with code > > > changes also part of the release process. > > > > > > Patrick > > > > > > On Mon, Mar 30, 2026 at 5:39 PM Christopher <[email protected]> > wrote: > > > > > >> I think it looks great, but I would really like to see the SCM source > > >> for this new site, so I can understand the maintenance/build workflow > > >> for it, before I'd have any useful opinion other than regarding > > >> aesthetics. > > >> > > >> I definitely concur with moving the docs out to the site to centralize > > it. > > >> > > >> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk > > >> <[email protected]> wrote: > > >>> > > >>> Thanks for your comment, Patrick. > > >>> > > >>> Why React? > > >>> Building a website nowadays is not just HTML + CSS, because doing it > > this > > >>> way turns the developer experience into a nightmare. With React we > > >>> effortlessly have consistent UI components across all pages, > including > > >>> buttons, tables, markdown rendering, colors, and much more. We also > add > > >> the > > >>> interactivity much more easily with React. A static website doesn't > > mean > > >> it > > >>> lacks interactivity; it often has significant interactivity, > especially > > >> in > > >>> the documentation section. The difference is that we don't need any > > >> runtime > > >>> environment, we just return the files generated at build time, which > > are > > >>> ultimately just HTML, CSS, and JS. The website also has dark mode > > >> support, > > >>> search in the documentation, smooth transitions between pages (no > hard > > >>> reload), so it gives smooth and better user experience overall. I > hope > > >> this > > >>> answers your question. Moreover, the website will work absolutely > fine > > >> even > > >>> for those who have JS disabled, this is called progressive > enhancement. > > >>> Initially, the server returns HTML and CSS. The browser renders them > > and > > >>> tries to fetch the JS files. If it doesn't succeed, the page remains > > >>> accessible, though it obviously lacks interactivity. I hope this > > answers > > >>> your questions, if not, feel free to ask more about it! > > >>> > > >>> Is it hard for ZK devs to update the content? > > >>> Not at all! I tried to make it so the learning curve for non-JS devs > is > > >>> almost 0. For the documentation you still just need to edit the MDX > > >>> (Markdown Extended) files and run the build command. I will also add > a > > >> bash > > >>> script to automate the build process. For the landing pages, you > still > > >>> mostly only need to modify the markdown files. Only the main page > isn't > > >>> markdown, modifying something small wouldn't be a problem. In the > worst > > >>> case, if something more complex is required, you can handle it with > the > > >> AI. > > >>> Nevertheless, the website hasn't been updated for years, so it > wouldn't > > >> be > > >>> a big loss :) > > >>> > > >>> Best regards, > > >>> Yurii > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt <[email protected]> > wrote: > > >>> > > >>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk < > > >>>> [email protected]> wrote: > > >>>> > > >>>>> Hi there, > > >>>>> > > >>>>> I am proposing an upgrade to the ZooKeeper website and > > >> documentation. We > > >>>>> are moving to a modern React.js stack, which allows landing pages > and > > >>>>> versioned documentation to live in a single application sharing the > > >> same > > >>>> UI > > >>>>> components, libraries, colors, etc. > > >>>>> > > >>>>> The plan is to move all website and documentation source code to > the > > >>>>> website branch and remove the zookeeper-docs Maven project from the > > >>>> master > > >>>>> branch. This decouples the Node/JS build environment from the core > > >> Java > > >>>>> repository. > > >>>>> > > >>>>> Versioned docs will be managed via archived folders within the > > >> website > > >>>>> branch. Documentation updates would move from master to PRs against > > >> the > > >>>>> website branch. Also I'm not planning to keep the app as a maven > > >> project, > > >>>>> since it's fully JS based. To keep it simple, I will write a bash > > >> script > > >>>>> that installs the dependencies, runs the tests, and the build. > > >>>>> > > >>>>> What do you think about moving the docs out of master to centralize > > >> the > > >>>>> site? > > >>>>> > > >>>>> Preview: https://zookeeper-website.vercel.app/ > > >>>>> > > >>>>> > > >>>> Looks pretty slick - nice update and visual refresh! Question > though - > > >> why > > >>>> React? This is a static website, what are the pro/con of React > based? > > >> Can > > >>>> you explain the impact on common use cases like making updates? ZK > > team > > >>>> includes a number of people, not all of whom might know React, how > > hard > > >>>> will it be for them to make changes? Impact on the release process? > > >>>> > > >>>> Regards, > > >>>> > > >>>> Patrick > > >>>> > > >>>> > > >>>>> Best regards, > > >>>>> Yurii Palamarchuk > > >>>>> > > >>>> > > >> > > > > >
