In the previous episode, I described why I started okoze and what I want to explore through the project.

Now I need to decide how to build it.

The development environment does not have to be complicated. In fact, I would like to keep it as simple as possible at the beginning.

There are also some decisions that I do not need to make yet.

Rather than choosing everything in advance, I will make the minimum decisions necessary to start developing and make further decisions when I have enough information to make them.

There are two broad approaches I could take:

• a web application
• a standalone application

A standalone application would give me direct access to the operating system and would avoid some of the constraints of the web platform.

A web application, on the other hand, has several attractive advantages for this project.

It can potentially run on many platforms without maintaining separate versions for each operating system. It can also be used on smartphones and tablets.

If necessary, a web application can later be packaged as a standalone application.

There is another reason that is particularly important for this series.

A web application can be published directly through GitHub Pages.

This means that each working stage of okoze can potentially be made available as a live demo, without requiring readers to install anything.

For a development series, I think this is a significant advantage.

The main disadvantage is that a web application is not a single technology. It involves several layers, including the browser, JavaScript or TypeScript, Web APIs, and possibly additional tools and libraries.

For this project, however, I think the advantages outweigh the disadvantages.

So I will develop okoze as a web application.

I will use the machine I already have:

Mac mini M4

There is nothing special about this choice. I am simply using the machine available to me.

The application itself should not depend on this hardware.

I will therefore not try to make the development environment artificially identical to the environment used by other developers.

I will start with JavaScript.

JavaScript is the most straightforward choice for a small web prototype, and I would rather avoid introducing additional complexity before I know what the application actually needs.

However, I expect the program to become large enough that TypeScript will eventually be useful.

My current plan is therefore:

Start with JavaScript, then migrate to TypeScript before the program becomes too large.

This is a plan, not a commitment.

If the migration turns out to be more difficult than expected, I may move to TypeScript earlier.

If the program remains small enough that JavaScript is sufficient, I may not need to migrate at all.

I will make that decision based on the actual development experience.

I will use Visual Studio Code as my IDE.

It is widely used for web development and has good support for both JavaScript and TypeScript.

I will not spend much time explaining how to use Visual Studio Code itself. I will mainly describe the parts of the environment that are relevant to developing okoze.

For the local development server, I will use the Live Server extension for Visual Studio Code.

It provides a simple local web server and automatically reloads the browser when files are changed.

At this stage, I do not need a more sophisticated development server.

I will use a Chromium-based browser for development and testing.

Chromium provides mature Developer Tools, which are particularly useful for inspecting the application, checking logs and errors, and investigating the behavior of the program.

The application itself should not depend on Chromium-specific features.

Readers should therefore be able to use another modern browser when following the series.

The main graphical component of okoze will initially be based on the browser's Canvas API.

For the first prototype, I will use Canvas directly rather than introducing a graphics library.

This is partly because Canvas is a relatively low-level API.

At this point, I do not yet know exactly what capabilities the graphics part of okoze will need.

I could choose a graphics library now, but that would mean making the decision before I have enough information.

Instead, I will first build a small working application using Canvas directly.

Once I have implemented enough of okoze to understand the requirements, I will investigate the available graphics libraries and compare the alternatives.

In particular, I would like to measure the performance of different approaches with increasing numbers of graphical elements.

For example, I may compare:

• Canvas API directly
• a graphics library
• SVG-based approaches

The exact comparison will be decided later.

For now:

Start simple, and choose a higher-level graphics solution only when there is a reason to do so.

This is an example of a decision that I deliberately do not want to make too early.

The source code will be managed with Git and hosted on GitHub.

I also want the repository to serve as a record of the development process.

When a significant stage of the application is completed, I will create a Git tag.

For example:

episode-001
episode-002
episode-003

The live demo published on GitHub Pages will correspond to these stages.

This makes it possible to look at both:

• the application as it existed at a particular stage
• the source code that produced that version

The repository is therefore not just a place to store the latest source code.

It is also part of the development record.

I will make active use of AI when writing the code.

This is an important part of the experiment described in the first episode.

AI can now generate a substantial amount of code.

However, that does not eliminate the need for requirements, design, testing, and decisions by the developer.

In this project, I will use AI as a coding partner.

I will decide what I want to build, ask AI for help with implementation, inspect the resulting code, run it, test it, and decide what to do next.

The actual way I use AI will therefore also become part of the development record.

I do not yet know what the most effective way of working with AI will be.

That is another thing I want to discover through this project.

There is one important thing I should mention.

My main area of expertise is CAD and geometric processing.

I have been developing software for a long time, but I have relatively little experience developing web applications.

In other words, I know quite a lot about programming and graphics, but relatively little about the web platform itself.

As a result, some of the things I write about web development may be surprisingly basic or even somewhat naive.

That is intentional.

Rather than pretending to be an expert in an area I am not familiar with, I would like to record what I learn as I go.

I think this is also one of the interesting aspects of doing the project this way.

I am not starting with a complete knowledge of the technologies I will use.

I am starting with a problem I want to solve and learning what I need along the way.

So, at the beginning of the project, my development environment is:

This is deliberately a small environment.

Some decisions have been made.

Some have only been made temporarily.

And some have not been made yet.

That is intentional.

I do not want to spend a lot of time designing the development environment before I have started developing the application.

The next step is to set up this environment and actually write some code.

Then I can start finding out which of these decisions work well in practice.