Korange

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.