Roadmap

[sathirak]

• [ ] Revamp UI
• [ ] Add go backend
• [ ] Add better markup support
• [ ] Image left-right float feature in markup
• [ ] Fix slowness in content page loading

[wineTGH]

I think it's best if I respond here so everyone can participate in the discussion.

We need to be able to host multiple wikis, meaning we need to manage multiple domains and admins and editos and all that stuff

Still don't really get it. Multiple domains is a job for the reverse proxy, not the backend. Everything else can be implemented via +page.server.ts. Both editor and admin page can be done in one place. Background tasks (sending emails for example) can be done with something like graphile. If you're worried about performance, because it's selfhost, the load will be smoothly spread across instances. No one will even notice that it's written in js. Am I missing something?

My point of all this is that developing, deploying and maintaining two codebases is much harder than one. Especially if they essentially do the same job: Go backend takes data and gives it to Svelte, Svelte takes it and gives it to you in a nice wrapper. It would be easier to use htmx then. The wiki itself isn't very dynamic, so....

[wineTGH]

Revamp UI

BTW, I can make some sketches for a new UI

[sathirak]

Good point, if svelte can handle all background processes on node in the backend, that's easier for us. However, the only concern is Node handling too much stuff in the backend. Which can ultimately be a performance issue hence why I thought of using go, since its compiled. But, if its easier for us then we can go with NodeJS backend.

We'll then make the thing completely in Svelte kit and see, okay.

[sathirak]

Also thanks a lot for your contribution, once you send me the UI stuff we can start on the CSS part

[wineTGH]

Also thanks a lot for your contribution, once you send me the UI stuff we can start on the CSS part

Before I can do something, I think we need to stabilize routes in project. So, here is my suggestion:

• routes/
  • +page.svelte (Index page with list of available wikis on instance)
  • wiki/
    • [name] (Index page of opened wiki)
      • [page] (Page of topic from wiki)
        • contribute (Editor)
        • history (Git like view of all changes to the page)
          • [commit] (Git diff like view of specific change)
        • discussion (forum like view of all discussions about this page)
          • [id] (Specific page of one discussion in form of forum thread or discord forum, IDK)
  • settings
    • TODO: Figure out settings routes
  • login
  • signup

[sathirak]

The structure I have in mind right now is similar, yet the discussions part is somewhat later in the roadmap

The settings page does not need routing, it just needs some tabs and stuff.

We do need another set of special pages too. Like a page that shows a map of the world of that place so navigation can be really easy.

Also need to tell you that current the Wiki page is rendered in Markdown, this is not what other wikis are using they are using Wikitext. I still don't know if we should go forward with Markdown or make a need markup language for this

[wineTGH]

The settings page does not need routing, it just needs some tabs and stuff.

In my opinion, it would be easier to do this on route level, not client. Because, it will be easier to maintain the state of pages and what will be changed and saved. Also, settings will automatically handle gestures on phones, because changing tabs would be as simple, as going back in browser's history. And, as a side effect, application will be capable to work without JavaScript.

Also need to tell you that current the Wiki page is rendered in Markdown, this is not what other wikis are using they are using Wikitext. I still don't know if we should go forward with Markdown or make a need markup language for this

I think markdown is perfectly fine for this usecase. Markdown has all blocks needed for wiki. And markdown is very extensible, so we can add additional stuff along the way.

[sathirak]

In my opinion, it would be easier to do this on route level, not client. Because, it will be easier to maintain the state of pages and what will be changed and saved. Also, settings will automatically handle gestures on phones, because changing tabs would be as simple, as going back in browser's history. And, as a side effect, application will be capable to work without JavaScript.

Yeah, I need this site with as less as JS as possible, needs high performance to it

I think markdown is perfectly fine for this usecase. Markdown has all blocks needed for wiki. And markdown is very extensible, so we can add additional stuff along the way.

found a bit of issues in markdown, will see, Markdown mostly works fine