Korange

I'm making the final push towards ship.

I've almost finished the trailer video, but I forgot some features I needed to show, so I'm having to shoehorn them in.

Right now I'm mainly working on a demo page. Since my project is Windows software, it'll be a sort of landing page with a download button.

I made a mistake in Git and my directory got corrupted, so I'll git clone it again and work in a new directory.
I've also added the editor library I forked for this app and the Hackatime Project, where I was exploring creating an editor, to this SoM project.

I'm currently working on creating a trailer video. I thought it would be cool to have a trailer.
Suno.ai generated a song that I thought would be a great fit, even better than I expected, so I'll use that song. It's not for commercial use, so it should be okay.

I'm currently preparing for Ship.

It's now possible to add images using Markdown. A better implementation would require a large amount of replacement, which probably wouldn't be possible in time, so I forked the editor library as a temporary implementation and added the necessary functionality.

I've also fixed some minor issues, such as the feedback URL not working and the UI being fixed in Japanese due to lack of localization. I've also created a feedback form.

Im currently preparing for the beta release.
In a previous Devlog, I mentioned trying out Tauri, but it turned out to be difficult, so I went with Electron instead. (I’m aware that some people don’t prefer Electron apps, so Tauri will remain part of the future vision.)
Most of the Electron app implementation was copied from the previous codebase.

Additionally, I added desktop-specific implementations for the React app, the core logic package, and the built-in features package.
For example:

• Desktop-specific implementation of the file system provider
• Desktop-specific implementation of the notebook manager
• Handling parts that didn’t exist in the desktop version

I also worked on other features, such as:

• Adding a beta warning to the notebook list
• Hiding/deleting/handling many features that are postponed for now
• Previously, the title bar icons used <img />; I replaced them with a React component using SVG to allow color changes according to the theme
• Standardizing the header button components
• Disabled an unnecessary focus outline in the plain text editor
• Adding the notebook deletion feature (WIP)
• Adjusting the light theme (WIP)
• Various minor tweaks for the initial ship
• And more… I might have forgotten some things.

A problem I ran into today: after building the desktop version, the exe tries to load the app’s HTML, but:

• It’s loading files that aren’t referenced in the codebase
• Access is denied

I concluded that access was denied because the file didn’t exist in the first place. I also assumed that it was referencing HTML files not in the code because it was falling back due to the original files being missing. I tried many solutions, like correcting the path notation and using different functions.
But none of the solutions worked. I even added logging and window output to debug the file paths being loaded, but nothing was logged at all.

Something seemed off… and indeed, the issue was that the desktop package doesn’t build the source code contents when generating the exe. In other words, although I thought I was changing the process through repeated trial and error, I had actually been inspecting the same generated output all along. WTF

I've completed a rough implementation of the Scrap feature (infinite scrolling and other features are very difficult and time-consuming, so I implemented a rough implementation that rendered everything), made various adjustments, file uploads, and worked on components that had not yet been implemented and parts that I had been putting off.
I'm currently working on a desktop package using Tauri.
Also, I think the vscode source code will be useful for file system abstraction.

• Commit to Git
• Have the current codebase reviewed by AI (Coderabbit) to identify issues and implement fixes (adding type guards, making HTML standard and accessibility improvements, refining state, removing dead code, introducing only-allow rules, cleaning up code, and other fixes etc)
• Separate UI components into a different package so they can be used from plugins or other sources in the future
• Sidebar header (notebook selection) is now functional
• Made adjustments to many parts
• Created state for the folder tree to allow folder creation and deletion (this took a lot of time, and I’m not confident about the state design)
• Working on a new note type called Scrap
• etc.

I can now create folders and notes! (Until now, there actually wasn’t any UI for creating them.)
I tried to make a UI like in VSCode, where nested folders are listed and clicking smoothly turns the folder into an input box. But it turned out to be pretty challenging in terms of both implementation and UI design. In the end, it came out nicely, so I’m glad. (Though some details like existence checks are still missing—I’ll add those later.)

Right now, I’m reviewing and rebuilding the interface of the abstracted file system class.

Also, while talking with ChatGPT, I learned about something called JSDoc. I had thought it was just a relic from the pre-TypeScript era for explicitly stating type information, but being able to write natural language descriptions that show up when hovering over a function is super convenient!
I also want to get better at writing clean, maintainable code, so I bought a book called The Art of Readable Code (Japanese edition). Apparently, it’s quite famous.

Recent progress:

• Refined the editor system. Until now the editor’s width container was implemented by restricting max-width and setting margin-x to auto, but I changed it to use CSS Grid so that the editor component can overflow outside of the container when needed.
• Enabled horizontal scrolling in the plain text editor. For plain text editing, text wrapping alone is sometimes insufficient.
• Previously, the plain text editor had a structure with a Codemirror editor spanning the height of the entire document, but I changed it so that the Codemirror editor’s height matches only the visible area. This enables Codemirror’s virtual scrolling, so it can now handle large amounts of text smoothly.
• With the editor height fixed, the horizontal scrollbar can now be moved without having to scroll all the way to the bottom of the document.
• Started implementing the Markdown editor.
• Using ProseMark as the Markdown editor library, but encountered an issue where formatting syntax such as ** remains visible on the right side after rendering. At first, I thought it was my mistake, but it turned out to be a problem with the library package. I stopped using the npm package and switched to using the latest commit package via pkg.pr.new. Since this library is still in development, issues like this can happen. Until the library has a stable release, I plan to keep following development commits this way.
• Currently, the project has a main page where you can open notebooks and write notes, and a notebook selector for choosing notebooks. Since some of their required init processes differ, I changed it so that they are built as separate HTML files using Vite. In practice, both reference the same HTML in the source code, and the script loaded on that HTML file is swapped out.
• etc.

I have also come up with an idea for another project and feel like working on it too, but since I am not sure if that would make it in time for the Summer of Making deadline, it seems better to stay locked in on this one.

I'm continuing work on the editor! I think the progress is going well :)

Main things I did:

• Various adjustments to the plain text editor using Codemirror (such as styling to push line numbers outside, etc.)
• Created types and extension points for the editor component. This includes React components and information like whether the editor scrolls, or whether the editor component is placed inside a container.
• Tailwind wasn’t working properly because there were two packages storing React components. To fix this, I added @source to the CSS file so that it can read the class names of the referenced package.
• Added extra spacing below the editor, which improved the appearance.

I feel like I’ve built a pretty nice plain text editor! Tackling the important functionality of reading and writing files has made me feel like things have really moved forward.

Also, file saving is now debounced. (This was a behavior I had already decided on a while ago.)

The attached file is from a session a little while back, so things are slightly better now.

Ah!! My Unlogged Time has reached 11 hours!!

What’s worth mentioning about what I’ve done recently is the design of the “note types” and the development and design of their extensibility and various other things.

Specifically, I implemented:

• Added an init function to packages/core. This handles things like registering built-in note types to the notetypeRegistry that manages note types (and in the future, registering plugin note types as well).
• Added necessary functionality to notetypeRegistry, like retrieving a note type from a file extension.
• Created an icon object and a component to load custom icons (not from lucide-react) so that icons can be easily added or loaded from plugins or extension points.
• Updated note types so that each note type can have a different editor component.
• Built-in note types were previously in packages/core, but since note types now include editor components, they require a React dependency. I didn’t feel it was right for packages/core to depend on React, so I created packages/builtin and moved them there. (In hindsight, maybe it would have been fine to just keep them in core…)
• The editor pane in packages/app now loads the editor component from the note type.
• The folder feature I mentioned in the previous Devlog is now complete! It works stably.
• There are probably other small changes I’ve forgotten…

Since app components might need to be used by built-ins or plugins, we may need to add packages/ui.

I had planned to implement plugin functionality, but it seems difficult, so for now I’m focusing only on creating a codebase that will make implementing plugins easier in the future. Plugin functionality will come after the MVP ship.

Also, I’ve been developing somewhat aimlessly, and surface-level progress hasn’t been much… I usually set “daily work hours” as my goal, but maybe it would be better to set goals like “features to implement today.” Also, development and design might need to be more agile… :thinking: (The biggest reason development is slow is that I’m completely inexperienced with large-scale development. My brain’s RAM is slow :( I want to upgrade to DDR5.)

I also need to increase the frequency of Devlogs. If I get lazy and don’t write Devlogs, I forget the details of my development. Honestly, part of me likes saving things up and dumping them all at once, but if I forget details or accidentally go over 10 hours, that defeats the purpose. So I’ll post Devlogs more frequently from now on. Also, Devlogs don’t need to be ridiculously long blog-post-length entries; they can be short, like commit messages.

Aside:
I’m an individual developer, providing non-physical data to the world via the internet and other channels, but I have a fascination with shipping actual physical products.
I’m thinking that if this project gains some recognition, I’d like to create a merch store. Specifically, I’ve made an on-demand store before where you just upload images to create a store, but what I want is to actually hold inventory, ship items myself, and sell things I’ve designed from scratch, not just items with a logo. Doesn’t that sound fun?

I’ve been researching and discussing with ChatGPT, and today I properly learned the concept of OEM. The idea is to design and conceptualize products and then have a manufacturing company produce them. Of course, it will probably be expensive, but I want to do it someday.

…Daydreaming about this is fun, but what I can actually do now is type code and bring it to completion… development is patience.

I found out about a library called react-blessed and switched to it. It lets you use blessed as a React renderer.

As expected, Declarative UI is justice, and it’s supreme!!!!1!111!!!!1

Also, I’ve got quite a few ongoing tasks (menus, explanation pages, authentication, and various other things), and those are included in the time for this Devlog as well (writing devlogs kind of half-baked... 😅). I’ll write about them once they’re mostly done.

I've created an SoM project, so I'll record my work so far in the DevLog...

Currently, I can display the UI using bun, typescript, ssh2, and blessed.
Displaying blessed via SSH was quite difficult, but I managed to implement it by referring to other people's implementations on GitHub.

In the previous Devlog, I was laying the foundation for packages/core (shared logic), but now I’ve mainly started working on packages/app (the React app package).
Right now, I’m focusing on implementing “folders” in packages/app. Folders can now be displayed in the tree. You can’t create new folders yet, but that’s only because I haven’t made a proper UI/component for it—the underlying mechanism for creating folders is already in place.

✅ Migrated components and files into packages/app that can be reused as-is from the previous codebase
✅ Improved handling of “folders”
✅ Display folders in the sidebar tree
✅ Previously, the old codebase loaded all folders at once, but now they’re only loaded when expanded
✅ Updated the sidebar tab system to make it easier to extend in the future
✅ 404 page
✅ Handling for browsers that don’t support required Web APIs, plus related component updates
✅ Minimal PWA (WIP)
✅ And more...

Also, I mentioned before that I would rebuild the codebase from scratch, but for packages/app I’ve carried over a lot from the previous codebase.

Because I was unfamiliar with large-scale development, my code base had become a mess after numerous specification changes.

I lost hope in the current code base, which was riddled with technical debt, so I created a new code base.

I also created a new Git repository.

Oh no, my unlogged time exceeded 10 hours...
This time, I worked on the core design again. It took a lot of trial and error, but I've pretty much nailed down the design. Or rather, I've decided on it.

Things I've tried over the past while:
* How should I import/export packages/core when using it from packages/app? (Consolidate it in index.ts / Barrel export, etc.)
* Should core be an init function + a fairly independent singleton class file? Or should I create a class called Core and consolidate everything there? (In that case, packages/app does not import anything other than the Core class.)
* After much deliberation, I looked into the source code of the OSS I use and found that it uses something called a DI Library. Using this as a reference, I tried out TSyringe.
* I consulted ChatGPT extensively about the specifications until I hit the daily limit.
* And various other things...

In the end, for now,
* I barrel export separate files like initCore and NotebookManager, and use each one in the app.
* Each class file is a singleton.
* TSyringe doesn't seem necessary yet in this design, so I've removed it for now.

So, I'm moving forward with this. If there are no particular problems, I'll leave it as is.

Im rethinking the design.

Currently, Citronote uses a monorepo structure, with the following packages planned:

• packages/core – Contains core functionality and logic, used by both the app and mobile. User plugins generally interact with this.
• packages/app – The React app for desktop and web.
• packages/mobile (planned) – The mobile app using Expo (React Native).
• packages/electron – The desktop app that wraps the app with Electron.

At the moment, some logic still exists inside app, and the export approach from core is temporary. However, as I work on implementing the concept of note types, I've decided to improve the design of core.

Specifically, with the current design, the app’s note types would end up being hardcoded. But since I want users to be able to add note types via plugins in the future, I’ve decided to both redesign core and implement this with extensibility in mind.

Also, with this redesign, the app's features won’t be so tightly bound to the app itself - they'll be more flexible. That means it'll be easier to implement user plugin functionality, which is great! Before, I felt like I don’t know how to make extension points for plugins, it seems difficult, but now it feels like it might be possible.

I’ve been working on an editor pane that includes a Markdown editor, a plain text editor, and an image viewer. In the end, I decided to go with a Markdown editor library called ProseMark. It’s still under development, but I really like where it’s heading, so I wanted to give it a try.

Figuring out how to build the Markdown editor itself took me a long time.
In a note-taking app I made before, I used a library called EasyMDE, which is a fork of the well-known SimpleMDE editor. But honestly, I wasn’t too happy with how it worked. EasyMDE makes you switch between the raw editor and the rendered preview, and while that’s fine, I’ve always admired the smooth WYSIWYG style of editors like Typora or Obsidian.

So I went hunting for a proper WYSIWYG Markdown editor library. The first round of research didn’t turn up anything great.

At that point, I thought I’d just build one myself. I tried hacking around with an HTML contentEditable element to hide and show Markdown syntax depending on the cursor position. That turned out to be harder than I expected, so I gave up. My next attempt was to build it with Codemirror. There are some examples of Markdown editors using Codemirror v5, but the current major version is v6, which has a completely different API. This attempt went better than the first one, but it was still tough, and in the end I started looking for existing libraries again.

That’s when I discovered a library called HyperMD, which looked like a perfect fit for what I wanted. It worked really well, but then I noticed the last commit was seven years ago. It’s built on Codemirror v5 too, which doesn’t help.

I wondered if anyone had forked HyperMD and kept it alive. That search led me to ProseMark, which is basically a fresh take on HyperMD built on Codemirror v6. It’s still in development, so some features are missing and parts of the UX feel a little rough, but I see a lot of potential in it, so I decided to adopt it.

What’s cool is that ProseMark is basically doing what I once tried (and failed) to do - building a WYSIWYG Markdown editor on Codemirror v6. I really respect that, and if I get some free time, I’d love to contribute to the project.

✨️ The page for creating notebooks is (almost) complete.
✨️ I created a menu for clicking on a notebook.
✨️ I added the exists function and the ability to load binary files to the abstracted Filesystem class.
✨️ You can now add icons to notebooks.
🔷 I've made progress on developing a theme cache for the background during startup.
🔷 The focus ring style has been improved.
🔷 Some components have been standardized.
🔷 I've added a Zustand store for storing classes for currently open notebooks.
🚧 I'm working on PWA support.
💩 I was trying to implement a mechanism for opening popovers from tab components, but I couldn't figure it out, so I put it off.
🩹 I fixed an issue where elements would overflow and not fit on a single screen.
and more...

I haven't been able to work much lately, so I think I should take a little more time.

I’ve been hopping around and digging into different features.

I made a Git repo earlier, but since I didn’t really plan things out and just kept jumping between features, I’ll probably end up with an all-in-one commit that bundles all my recent work. If this were a production team project and I were the reviewer, I’d definitely be confused - but since it’s just me, it’s fine.

I don’t really remember everything I worked on, but looking at the git diff jogged my memory:

• ✅ Tweaked the handling for notes, notebooks, and folders I built before
• ✅ Added a “...” button to the sidebar—just the UI for now, but it could be useful for future plugin extensions
• 🚧 Started reworking the onboarding page. Halfway through I realized I needed a slide animation system, so I built one
• 🚧 Working on a UI for creating notebooks inside the notebook selector window—also uses the slide animation system
• 🚧 Building a new input box component
• ✅ Customized the scrollbar style since the default one clashed with the app’s vibe
• 🚧 Working on theme caching so the app doesn’t flicker on startup
• ✅️ We created the concept of the active notebook
• etc

Oh, and Hackatime says I’ve passed 100 total hours (across all projects). I’m calculating how much more work I need to do to get the prize I’m aiming for. Sadly, my summer vacation is almost over, so I’m not sure how much time I’ll actually have 😭 and what about homework?

As for what I can actually show in the attachment… I built a page component with horizontal slide animations. It looks simple, but things like easing and timing turned out to be trickier than expected. Switching from ease-out to ease-in-out made it look way better, which surprised me. (I took inspiration from GNOME and similar systems for the feel.)

I’ve been working on the note handles, revisiting the class design and such, and now the desktop version can also load notes :) It’s coming along nicely.

Also, I think the UI for the note list has gotten a bit better.

It’s still a long way from being finished, but I’d like to have a minimal MVP ready by the end of September. (I believe it’ll probably be extended until 9/30, but this island isn’t going to sink away before then, right!?)

Working on handle note/files.
I feel like the UI for the note list is a bit off 😭

Now can handle and display folders.
I also worked on context menus (WIP), theme support (WIP), and other miscellaneous tasks.
Also, I wrote before that I used Biome, but it was difficult, so I changed it to Prettier.

First Commit 🎉🎉🎉🎉🎉

🎉 I finally initialized a Git repo. And… this is where the story begins…! (yeah kinda late lol)

So, I’ve been dealing with some random little chores. Went through the file directories, tidied things up, deleted files I made during trial-and-error but don’t use anymore, and also got rid of empty folders.

Also I addd Biome for code formatting. Prettier is the famous one, of course, but i thought trying something new sounded cooler, so I went with Biome. Figuring out how to ignore files and folders was way harder than I expected (ChatGPT kept suggesting config files that don’t even exist :( )

And yup, finally made the Git repo. I posted on my Devlog a while back like “It may be time to init Git 🤔” and… it’s been two months…
I also got a bit stuck thinking about branch strategy. i usually go with Git Flow when I’m expecting the project to be kinda big, but there are a lot of people online who say Git Flow is bad, so I hesitated. In the end, I figured I can always change things later if stuff breaks, so I went ahead with Git Flow for now.

P.S. I found a Wikipedia article called “Analysis paralysis”… and wow, that’s totally me 🤦
https://en.wikipedia.org/wiki/Analysis_paralysis

Implemeting theme feature. I briefly considered trying Emotion, but ended up going back to Tailwind.

Part of the mechanism for managing and loading notebooks
(Im currently working on changing the theme to change my mood)

Object-Oriented Notebooks :)

Organizing the core logic into packages/core, changing the infrastructure (yet again)...

Working on a persistent store, a notebook infrastructure, and more

Tooltip!

I'm working on the notebook selector screen. I think the UI is pretty good.

I was pressured by explorpheus on Slack to post a Devlog, so here it is. — I guess I should post more frequently.

Well, recently I’ve been focusing on building the foundation of the project. Also, in the previous Devlog, I said I introduced Redux Toolkit, but I actually switched to Zustand.

-< Abstraction of Notebooks >-
First, this software plans to support two locations to store notes:

• Local: The “folder” on the PC itself acts as a “notebook.”
• Cloud: Notebooks are managed on a server (I’m not developing this now, but it’s part of the future vision, so I’m building the foundation early to make it easier to implement later).

Furthermore, this project is planned to support two platforms: browser and desktop (using Electron).
Here’s the problem: for the local storage, the way to manipulate the file system differs between browser and desktop. The browser uses the File System Access API, while the desktop version uses Node’s fs module via ipc.
To handle this efficiently and maintainably, it’s necessary to abstract away the differences between platforms and storage locations inside the app. This time, since there are two layers — platform and storage location on top of that — it was quite difficult. But I think it was a good learning experience for large-scale development.

-< Window Issue >-
Let’s consider the difference between a “native app” and an “Electron app.”
While it’s good to unify languages and platforms technically, what I thought from a UI/UX perspective is that Electron apps basically run on a single window and rarely use multiple windows.
For example, the software I use called “YukkuriMovieMaker” is made with .NET, so I think it’s a native app. It has windows like:

• “Settings”
• “About YukkuriMovieMaker”

These are implemented as separate windows, which is common. Electron apps tend to use modals layered over a single window instead.
Windows UI itself rarely layers things inside a single window; rather, it uses multiple windows for that.

I think this is because Electron is a framework to build desktop apps with web technologies, and the general web app principle is “one tab = one app session.” I’ve never seen a web app that opens multiple windows.
Also, many Electron apps are basically wrapped web apps originally made for browsers (e.g., Slack).

(I was thinking about this difference when comparing GDLauncher and MultiMC in the past.)

So, simply put, which do you think is more convenient: “multiple windows” or “one window with modals”?
I think multiple windows are more convenient. From a user’s perspective, it might be easier to rely on the OS’s native window features.

However, my app has both desktop and web versions. Since browsers cannot open new windows like desktops, it might be better to use windows on desktop and modals on browser accordingly.

That said, as I mentioned, web apps generally treat one tab as one session. In Electron, each window is a BrowserWindow that opens a specified URL and is equivalent to a tab.
Windows behave like separate tabs, so their state (like Zustand state or variables) are isolated and separate. The only way they can communicate is via ipc through the main process.
Writing this out, supporting multiple windows is really tough. It’s easier if the app’s core logic is in the main process, but since this app also supports the web app version, core features must live in the React app.

Anyway, unrelated to that, I recently needed to create a selection window separate from the main window, so I worked on the mechanism for that. While building it, I was also thinking about making it flexible enough to support the above window usage.

Honestly, I feel like I’ve spent too much time on design and not enough on coding this time, so I temporarily set that aside and created the mechanism for a “window that selects which main window to call.” (What was all that text before for???)

Oh, I’m still undecided on some things and don’t know how it will turn out.

-< So what did I actually do during this time? -->
Since I was lazy and didn’t initialize a Git repo, some things might be missing, but...

• Switched from Redux Toolkit to Zustand
• Used a provider-based design to abstract storage of notebooks and notebook lists (IndexedDB in browser, JSON files under appdata on desktop)
• Tried structuring code under a features/ directory
• Created a page/window for the notebook list menu
• Improved the desktop package’s support for multiple windows and organized the directory structure
• And more...

I doubt many people actually read Devlogs, but somehow I ended up writing a really long text. Probably it’s better to post short updates more frequently. The window issue and other topics might be interesting enough to write separately on a blog or something.

Before shipping, a quick intro:

Korange's Lab is a collection of small web services I created. One of them, Relaytale, lets everyone write a story together by adding one paragraph at a time in real-time. The first paragraph is randomly chosen from prepared starters.
(e.g., While walking down the street, I found a button with a sign that said, ‘Don’t push! Absolutely do NOT push.’)

Participants then take turns writing the next paragraph until the story reaches a set length. You can join with a Google account or HackClub Slack.

I originally made a similar app called “Collabtale” and always wanted to remake it. When I found the perfect theme for my development sprint — “build a real-time app” — I decided to create Relaytale.

The app currently has minimal features but I planned chat, emoji reactions, private rooms, and more. Due to the sprint deadline, I paused feature development and shipped what I had. The code got a bit messy from rushing, so refactoring or a rebuild is needed.

Technically, it’s a monorepo managed with pnpm, using TypeScript for both frontend and backend.
The frontend uses Nuxt and TailwindCSS, hosted on Netlify.
The backend runs on Hono, which handles authentication (via auth.js) and the core websocket server, hosted on Google Cloud Run.
This was my first time using Hono, and I love it! Sharing types and Hono RPC feel like magic — highly recommend it for TypeScript users.

As a fun add-on, I made an introduction video. It took looooonger than expected, but I finished it, so feel free to check it out if you have time 👇️

I did various things, such as introducing Redux Toolkit for state management, creating an electron package in a monorepo, migrating to pnpm, and trying out electron-builder.
This time, I've attached the current state of the installer.

Completed!!!!! ᕕ( ᐛ )ᕗ

I repeatedly added various functions and made modifications to both the front-end and back-end, and deployed the front-end on Netlify and the back-end on Google Cloud Run.

On the way... I made it in a hurry and haphazardly, so the code base is literally shit. A lot of bugs appeared.
However, since the deadline for YSWS is approaching, I decided to finish it in this state - it may still be unstable and have unfriendly UI, but the main functionality can continue without any problems :)

All that's left now is to publish it on GitHub and completely satisfy the other YSWS submission conditions and submit it!

However, to be honest, I don't see any hope for the future of the current code base, so I would like to slowly refactor it and improve it someday after submitting it. In fact, there are many things that I compromised on due to time constraints.

(P.S. I was surprised that the total work time for SoM exceeded 40 hours without me noticing - EVERYOHE, PLEASE VOTE!!!!!!!!! I WANT SHELLS!!!!!!!!!!!!!!!!)

I worked a lot today. I'm working on the front-end because I'm starting to get confused about what features are needed for the back-end.

I decided to use Nuxt for the front-end. With the help of ChatGPT and others, I added back-end integration in Nuxt style.

I'm currently working on the main feature of Relaytale, the page where you write the story! This uses Websockets a lot, and is one of the requirements for the Hackmate YSWS where I'll be submitting this app.

However, there are a lot of temporary, half-baked code in the codebase, and I'm starting to wonder if I can submit it by the YSWS deadline (although I would like to do it).

I also need multilingual support. Currently I've made the app in Japanese, my native language, but if I want to show it to people at the Hack Club, I need to add English.

(btw - Hono is great! It's fun to code, and the RPC function is magical)

I haven't posted a Devlog in a while.
Recently development was literally a series of Trial and Error, but it seems to be working out well.

At first, I tried to create the entire application, including the API, using Nuxt. (Authencation is @sidebase/nuxt-auth)
Later on, I felt that @sidebase/nuxt-auth was a little difficult, so I decided to use NextAuth(Auth.js) and Next.
Actually, before I decided to use Nuxt, I tried making it with Next and decided to switch to Nuxt, but I came back. (I took over some of the code base I created with Next and created a new Next project)
I tried to use Drizzle ORM, but I had some errors, so I switched to Prisma - which I am more familiar with.

BUT --- I'm not used to approach from Next.js, that is the Frontend and Backend boundaries become blurred. I was confused, I thought very difficult.
As a result I decided to seperate Backend API and Frontend. I decided to use Hono, which I was interested in, for the Backend
I haven't decided yet what to build the frontend with - maybe Next? Since I've decided to put authentication in the backend, maybe I'll go back to Nuxt.

By the way, the development experience at Hono was very good! It's much more fun to accumulate what you've accomplished than to worry deeply about one thing :)
I also created a Websocket authentication process on the backend. Since it is difficult to send cookies directly via Websocket, I issue a JWT token that is valid for one minute at a normal HTTP endpoint and send it via Websocket. (Thanks to JWT, the server does not need to have temporary token information! When I first learned about JWT, I thought it was just a modern token, but it's so useful.)

(I also tried Beeter Auth when I found sidebase too difficult, but it's been a long journey to get to this point.)

I’ve done various things, such as bringing back a navigation bar that had disappeared and porting components I built in React over to Vue.
Currently, I’m working on connecting a PostgreSQL database using Drizzle ORM.

I’ve been asking ChatGPT for a long time how to make each mini-service in a Nuxt site nicely independent at the codebase level, but the information it provided was full of mistakes and serious misconceptions, so it wasn’t helpful at all — LLMs tend to hallucinate and produce plausible-sounding but wrong answers… or maybe I’m just using it wrong?
Also, I accidentally deleted the Navbar component permanently along the way. Since this was still the very beginning of the project and I hadn’t even set up a Git repository, I’ll have to recreate it from scratch again 😭
In the end, it seems like making the codebase behave exactly how I envisioned would be too difficult, so I decided to abandon perfectionism for now and just build it using the standard Nuxt directory structure. (I wasn’t too happy about how the “services” would end up split between frontend and API routes, but then again there are plenty of examples of backends being implemented as separate projects in other languages, so maybe I don’t really need to worry about it that much… but though there are a few other reasons too.)

I plan to keep building small web services in the future, so I decided to create a website called “Korange’s Lab” to collect all the mini services I’ve made. (There are lots of benefits, like sharing authentication, reusing SaaS features, and encouraging users to explore other services :) ).

With that in mind, I’ve decided to include Relaytale in Korange’s Lab and develop both the core features of Korange’s Lab and Relaytale in parallel. Relaytale will be submitted to Hackmate YSWS!

At this stage, I’m building the authentication system using @sidebase/nuxt-auth. Actually, I’ve had this idea for the site for a while, and since I already have ui-design drafts, I don’t expect to run into many issues :)

Relaytale is a web app where people gather together to take turns writing chaotic stories (it's also a remake of something I made before).

I'm currently working on the first screen, but I might remake it.

Trying out Aptabase

Oh I almost forgot to record it...
I'm experimenting with the note component. It's hard to make the UI look good.

Building Theme Selection (Onboarding)

wip - It's hard to make it look good

I'm trying to build an onboarding screen. This is an mockup I made in Figma quite some time ago, but I'll probably change it.

I needed a separate page for onboarding and other things, so I installed react-router-dom.
I also experimented a bit with styling and design (like how to handle the root folder in the UI).

Optimized the process a little
(It may be time to init Git🤔)

The banner has been set!
I also organized the code a bit by componentizing it a bit.

Package/Repo configuration plan...

Tabs!

I made a simple concept. It doesn't start even if I commit it yet, and it doesn't have a function to record it.

I created a folder collapsing UI. I love how it works and how it looks :)

P.S. I want to publish an app on Google Play, but it seems that people under 18 can't register, so I'm having trouble :(
If anyone has managed to achieve this in some way, please let me know how you did it!

I'm currently thinking about and putting together the technical specifications for the project.

I have also started developing the UI, including the button and folder selection components, as well as the rough layout of the overall UI.

This is a project I had put on hold for a while because it was too complex, but I’ve decided to pick it back up again.
First, I changed the tech stack:

React → Vue
Three.js & Rapier → Babylon.js

I originally wanted to try using React for the first time, but found it difficult and didn’t have much time to spare, so I switched to Vue, which I’m more familiar with.
It was also challenging to get Three.js and Rapier working together smoothly, and building the “rails” (the structured foundation or framework to tie things together) for them was proving difficult. So I decided to take advantage of Babylon.js, which already functions more like a game engine out of the box.

In terms of features, I’ve been working on the structure for game object types and UI components. Since there are so many features to implement, it’s hard to decide the order of development—but for now, I’ve decided to start by building the user-facing UI.