Over the last 3 to 4 years, we've witnessed an explosion in the number of frontend and full-stack frameworks and libraries. This boom has added significant variety to an already diverse ecosystem, introducing technologies like Solid, Svelte, Qwik, Astro, Remix, Vite, Lume, HonoX, Tailwind CSS, Panda CSS, StyleX, and Shadcn UI, among others.

In addition to libraries and frameworks, we've seen the emergence of new and impressively fast JavaScript runtimes, such as Deno, Bun, and WinterJS.

Serverless computing and edge development have also surged in popularity, particularly within the JavaScript community. Platforms like AWS, CloudFlare, and Vercel offer runtime environments specifically tailored to these paradigms, including AWS Lambda with Node, CloudFlare Workers & Pages, and Vercel's Edge Runtime.

In frontend development, we've observed a revival of old paradigms, such as SSG (Static Site Generation), SSR (Server-Side Rendering), and more recently, RSC (React Server Components) and HTML streaming. While some of these concepts aren't new to other programming languages like PHP, they represent fresh approaches within the JavaScript ecosystem.

Another technology that has significantly impacted the industry is Generative AI, influencing the adoption of new technologies (especially HTML streaming) and shaping new paradigms and patterns for developers to learn and adopt.

Given the rapid introduction of these technologies, it's understandable that many of us experience information fatigue. The list of concepts to grasp is extensive, and technology evolves faster than our ability to integrate it sustainably. The new code you write today may well become obsolete in 5 years or less!

Next.js: A sweet and convenient trap

Here's the lowdown on Next.js from a dev's perspective. We're in a golden era of web development, with more tools and frameworks at our disposal than ever before. In this sea of innovation, Next.js stands out, especially for those of us knee-deep in React. It's packed with features that make you want to dive right in. But, it's not all sunshine and rainbows.

The catch with Next.js? It's a bit too cozy with Vercel. Sure, Vercel's free plan is great for starters, but once your project picks up steam, the costs can sneak up on you. As a React developer, I appreciate everything Next.js offers, but the moment you try to step outside the Vercel ecosystem, you hit a wall. It feels like you're boxed in, specially when features like image optimization don't work as good as it does in Vercel, or are simply not supported.

I get it, Vercel is a business and they need to make profit, and they have open sourced the Build Output API, which is a step in the right direction, but the feeling of being locked in doesn't go away. Whenever a big update drops, you're left wondering how it'll affect your project if you're not fully on board with Vercel.

There's some hope with SST and OpenStack working to offer more flexibility, but it's not perfect. Hosting Next.js yourself, say with Docker, means missing out on some features and optimizations (e.g. caching of optimized images).

Then there's the dev server debate. Next.js comes with its own, but Vite is taking the developer world by storm by being adopted in every other major framework and tool. Vite is fast, flexible, and its plugin system is very good. It's hard not to envy Vite users when you're looking for a streamlined and efficient development environment. Parcel is also worth mentioning, looking awesome and all-batteries included since version 2.

In a nutshell, Next.js is great if you're all in with Vercel, but the moment you want more freedom, you start feeling the constraints. It's a bit like being given the best tools for a job but only being allowed to use them in one specific room. We're all searching for that perfect balance of features, flexibility, and freedom. For now, Next.js is a compelling option, but with a few strings attached.

What If I want to deploy certain serverless functions to AWS and others to CloudFlare? Not possible with Next.js alone, you need to integrate CDK or Wrangler in your project and make REST API calls from your Next.js project, making Server Actions pointless.

Other frameworks

Other frameworks like Remix and Astro are cool, but they don't offer all features Next.js has.

Astro, for instance, is more focused on offering Static Site Generation rather than dynamic and interactive (although it is still possible).

Remix announced they are studying the possibility to support RSC, but I don't expect it any time soon (probably after React 19 becomes stable).

I personally love React Server Components and the files & layout system of the App Router, but unfortunately I didn't find other frameworks offering something similar yet.

Remix and Astro are projects to follow closely. They have a great developer experience and a good freedom/democracy when it comes to platform interoperability / exportability. Things may get interesting during this and the next year.

The State of React: just why??

The React team recently announced the upcoming changes that we can expect for React 19.0.

There hasn't been any new React release since Summer 2021, everything has been cooked internally as canary releases that have been adopted by "stable" Next.js releases (sold as production-ready 👀): specially React Server Components and Server Actions.

I am not very happy with these (kind of opaque) decisions. Communication and documentation has been poor in the last years, to the point that the community didn't know at the beginning if RSC & Server Actions were part of React or only specific to Next.js.

I've been also considering changing to Vue, Solid or Svelte, even Astro, but professionally I am still using React every day, so It wouldn't make sense for me to do the switch, I would just consider any of them for small experimental side projects.

The fatigue I talked about in the intro is real, and changing to a new framework wouldn't be productive for me. At the end all you want is to ship great things rather than spending most of your time worrying about the technology: researching, learning, prototyping and then start over again because it didn't work as expected. Learning and research is also part of our job as developers, it is also important, but it becomes problem when it affects our productivity.

All I hope is that, from React 19 on, things start to get easier and more clear for us, and the React team goes back to a normal pace of release cycles.

Build your own framework

So, after all that's been said and done, you might be feeling like stepping off this wild ride and starting fresh. Why not build your own framework? Just the essentials, nothing more, nothing less.

Honestly, there's never been a better time to do it. As web developers, we've got more resources, tools, and community support than ever before. And it looks like it's only going to get easier from here.

If there's something I miss from my PHP days is having a composable framework like Symfony, the PHP framework. You can adopt Symfony entirely as your only framework or just use some of its components as dependency. You can also build another framework on top of Symfony components, like Laravel did. We should have something similar for full-stack web development in TS/JS.

The thing is, we've been missing the right set of tools to truly go head-to-head with something as feature-rich as Next.js, especially when it comes to stuff like RSC support.

Projects and initiatives like Vike and Vinxi (both powered by Vite) are making efforts in that sense, even though they're still in the early stages. I specially like Vinxi: it offers full freedom in terms of routing (you can decide how to organize your files and which router library to use) and it recently added support for RSC with its own implementation (very similar to Next.js's). Vike felt more restrictive.

What I don't like from both is their documentation and how complex is to understand what their code is doing. I'd rather have a paper / documentation / example-first approach for projects like thes, rather than code-first.

First define your target architecture, how should it work, document it, then implement it. Iterate.

The idea behind "build your own framework" is to exactly no depend on other frameworks, and to not be forced to the ways and conventions of specific libraries.

PizzaJS 🍕

So here comes my concept, how my ideal framework should be, my journey to shape and bring to life the "Symfony" counterpart of the JavaScript/TS world.

For some months I've been in a research phase, and I even got a name!

I named it PizzaJS, because everyone loves Pizza. The funny part is that I want Pizza's different pieces to be named after the ingredients of a pizza: Basil, Mozzarella, Pomodoro, like the colors of the italian flag 🇮🇹 as well.

I am taking inspiration from Symfony, Next.js, Vike, Vinxi and also Hono/HonoX (and will probably using parts of them as well).

The Pizza Philosophy

1. Documentation-first: First the concept and theory, then the code. PizzaJS will first have the documented theory of how it should work, backed by coded proofs of concepts.

2. Universal and Interoperable: It should be compatible with all major JS runtimes and cloud services: Node, Deno, Bun, Winter, Edge, etc.

3. Modular, Composable and Pluggable: Developers should be able to decide to integrate all components or just some of them. They should also be able to replace any component with their own custom implementation.

4. Unopinionated: Components shouldn't be tightly coupled to each other (e.g. the server component shouldn't directly depend on the router one). Developers should have the freedom to replace one component with another library / implementation.

5. Familiar: It should feel familiar to use the framework or some of its components. Don't reinvent the wheel. Use (and respect) Web standards and community conventions as much as possible. Build on top of Vite as well.

6. Extensible: The framework should support extensibility via a Vite-compatible plugin API. It should also be able to pass configuration to Vite. Initially with a React flavor only, but the components should be agnostic enough to bring other frameworks to the pizza party.

7. No surprises: I take the principle of least surprise/astonishment very seriously. No surprises, no magic or black boxes. No side-effects or pollution of native APIs (like redefining how fetch works). Again, respect web standards and how they are intended to work.

8. Declarative: Explicit and declarative rather than of by convention. Devs should know what their code is doing all the time, and where/how it will be executed.

9. Multimodal: SPAs, MPAs, PWAs, SSG, SSR, RSC, HTML Streaming... all should be eventually supported in a declarative way.

10. Performant and Compact: I'd rather have a minimal set of dependencies, small bundle size, and well tested code that is able to scale, backed by data and benchmarks.

It is a very ambitious project that I have a lot of uncertainties about, but the journey it's what matters. For sure I will learn a lot about JS framework internals, runtimes, etc., things I wouldn't learn much about if I stayed in my comfort zone as a full stack dev.

I want (or will try) to document my journey about going framework-free in this blog. I will be talking about both JS and CSS frameworks/libs, and probably about new promising HTML technologies as well.

Stay tuned here and on https://github.com/pizzajsdev

The UI also looks much better, especially on mobile. The styles have been reworked so the look and feel are more similar to StoryBook's UI.

You can read more and watch a small video clip with the changes here https://github.com/itsjavi/storylite/releases/tag/v0.6.0

Written in TypeScript and powered by the blazing-fast Vite, StoryLite offers a streamlined way to preview your components in an isolated environment without the overhead of a full-fledged Storybook setup.

You only need to configure a Vite server with the StoryLite plugin, instantiate the StoryLite React app and voilà!

Thanks to the power of Vite, StoryLite also supports Static-Site generation (SSG) out of the box!

Inception and Motivation

The idea for StoryLite sprouted from a simple need: to have a quick and hassle-free way of visually testing my React components during development. While Storybook is an incredible tool, its complexity and setup sometimes felt like overkill for smaller projects or when a rapid iteration cycle was crucial. I wanted a solution that would provide a similar experience but without the configuration overhead. StoryBook has also a lot of package dependencies.

Getting Started with StoryLite

Getting StoryLite up and running in your React project is a breeze. With a few simple steps, you can start previewing your components in isolation from your full app:

1. Installation: You can install StoryLite with the package manager of your choice, with one of the following commands:

    # npm
    npm i -D @storylite/storylite
   
    # yarn
    yarn add -D @storylite/storylite
   
    #pnpm
    pnpm add -D @storylite/storylite
   

2. Install Vite: Install Vite and the React plugins (if you don't have these dependencies already in your project).

    # npm
    npm i -D vite @storylite/vite-plugin @vitejs/plugin-react-swc
   
    # yarn
    yarn add -D vite @storylite/vite-plugin @vitejs/plugin-react-swc
   
    #pnpm
    pnpm add -D vite @storylite/vite-plugin @vitejs/plugin-react-swc
   

3. Configure Vite: Create a vite.config.ts file at the root of your project. This is where you can tell Vite and the StoryLite plugin where to find your stories. Here's a basic example:

    /// <reference types="vite/client" />
   
    import storylitePlugin from '@storylite/vite-plugin'
    import react from '@vitejs/plugin-react-swc'
    import { defineConfig } from 'vite'
   
    export default defineConfig({
      plugins: [
        storylitePlugin({
          stories: 'stories/**/*.stories.tsx', // relative to process.cwd()
        }),
        react(),
      ],
    })
   

4. Configure typescript: You need a couple of changes in your tsconfig.json for TypeScript to detect the types correctly, especially the stories collected by the Vite plugin at run-time. Merge the following with your own config:

    {
      "include": ["src",  "stories", "storylite.tsx"],
      "compilerOptions": {
        "types": ["@storylite/vite-plugin/virtual"]
      }
    }
   

5. Add the entry points: Create index.tsx and index.html in your project (or somewhere else) with the content you can find in this demo (you can customize it to your needs): https://stackblitz.com/edit/storylite-demo?file=src%2Findex.tsx,index.html

   The StoryLiteApp component is a full-screen React Single-Page app (it uses a hash-based router), and it can be mounted anywhere you wish.

   If you already have a Vite project or an index.html file in the root of your project, it's recommended that you setup StoryLite in a new package (if you are in a mono-repo) or in another directory.

   Remember that you also need react and react-dom as dependencies.

6. Run StoryLite: Launch the StoryLite development server using Vite's lightning-fast build system. For that, we can add two simple scripts to our package.json :

    {
      "scripts": {
        "stories:build": "vite build",
        "stories:dev": "vite --port=7007 --host=0.0.0.0 --open"
      }
    }
   

   Then, run npm run stories:dev , yarn run stories:dev
   or pnpm stories:dev

7. Preview Your Components: Visit http://localhost:7007 in your browser to explore your component stories. You can also use any other port in your script.

8. Generate a static version: When you run stories:build , you will be generating a static version (SPA) of your StoryLite instance, with your stories. That's useful if you want to host it somewhere, like in your Github Pages.

All these examples are compatible with StoryLite >=0.9.* at the time of writing this article.

You can check the example code in the repository as well: https://github.com/itsjavi/storylite/tree/main/packages/examples/react

The Current State: Version 0.9.0

As of now, StoryLite has reached version 0.9.0. While it may not yet offer the full spectrum of customization options that Storybook boasts, it certainly provides the essentials to get you started on the right foot. With this version, you can effortlessly create and visualize your component stories, making development and debugging a smoother experience.

Porting your stories from StoryBook won't be much of a problem, since StoryLite is almost fully compatible with CSF 3.0.

Current Limitations

• Only compatible with React (for now)

• No support for StoryBook features like "auto docs", "code snippets", "knobs", "controls", "actions" or "events"

• No support for MD/MDX files (yet)

• Styles are not mounted/unmounted per component, they can only be global at the moment (loaded by your entry point).

While it would be nice to support a wide variety of tools, we want to keep things as simple as possible.

What's Next for StoryLite

The journey of StoryLite has just begun, and there's a lot to look forward to in upcoming releases.

CSF: My plans include finishing the story definition API to close the final gaps with the StoryBook's CSF 3.0 spec and StoryBook's compatibility, ensuring a seamless migration process for those transitioning.

Props editor: The Controls panel (where we can adjust the props) is also a must-have and will come in the next versions.

Test runner: My dream is to bring component testing to the browser, by using Jest and maybe React Testing Library. I would like to facilitate this via the CSF's play() function.

Finally, I would also like to rework the Addons and the Addons API, so you could bring your own and fully customize the toolbars, in a similar approach to StoryBook's.

Join the StoryLite project

StoryLite is a project fuelled by the developer community. Your feedback, suggestions, and contributions are invaluable in shaping the future of this tool.

Whether you have ideas for new features, encounter bugs, or simply want to share your success stories, I encourage you to join the discussion and development process on GitHub: github.com/itsjavi/storylite.

While the scope of this library is to support React components (and probably RSC), you are welcome to contribute to adding support for other frameworks and environments.

Final Thoughts

In conclusion, StoryLite is here to simplify and streamline your component testing workflow. If you're looking for a lightweight, TypeScript-powered alternative to Storybook, give StoryLite a try.

Happy coding!

To avoid this, many developers opt for using error codes instead of error classes. These error codes are simply strings or numbers that represent the type of error that has occurred.

When using error codes, it's common to pass additional information about the error in the error message. But testing the error message makes tests a little ugly and has some drawbacks:

• You have to use RegExp to test the error message

• Many errors may have similar error messages, leading to misleading tests with false positives/negatives

• When error message changes, you have to change your tests

This is where the options parameter of the JS Error class comes in. It allows us to pass additional information about the error that can be useful in understanding why the error was thrown.

You can pass an options object as a second argument of the Error constructor. It can have a cause property that can be of any type or another Error.

This pattern of throwing errors with a cause is widely used in JavaScript, and testing the value of the cause can make your tests more robust.

Unfortunately, Jest's built-in matchers do not provide a way to test extra properties of an Error, and that's where extending the Jest matchers in TypeScript comes in handy.

All you have to do is to define your custom matchers in your setupTests.js file, by calling expect.extend()

// setupTests.js
const catchError = (callback) => {
  try {
    callback()
  } catch (error) {
    return error
  }
}

/**
 * @type {ExpectExtendMap & MatchersExtend<any>}
 */
const customMatchers = {
  toThrowWithCause(received, cause) {
    const err = catchError(received)
    const passes = (err instanceof Error) && (err.cause === cause)
    const actualCause = String(err ? `got: ${err.cause}` : 'no error was thrown')
    console.log('Error Cause', actualCause)

    if (err && err.cause === undefined) {
      console.error('Error was thrown, but cause was undefined. Error:', err)
    }

    return passes ? ({
      pass: true, // not.toThrowWithCause
      message: () => `Expected callback not to throw an Error with cause '${cause}'`,
    }) : ({
      pass: false, // .toThrowWithCause
      message: () => `Expected callback to throw an Error with cause '${cause}', but ${actualCause}`,
    })
  },
}

expect.extend(customMatchers)

You also need to extend the Jest types:

// setupTests.d.ts

export {}
declare global {
  namespace jest {
    interface AsymmetricMatchers {
      toThrowWithCause(cause: string | Error): void
    }

    interface Matchers<R> {
      toThrowWithCause(cause: string | Error): R
    }

    type MatcherNames = keyof Matchers<any>

    type MatchersExtend<R> = {
      [Key in MatcherNames]: (
        received: any,
        ...params: Parameters<Matchers<R | void>[Key]>
      ) => R | void
    }
  }
}

And then you can use it in your tests like this:

const myParser = (version: string) => {
  throw new Error(`Invalid version ${version}`, { cause: 'INVALID_VERSION' })
}

it('throws an error if the version is wrong', () => {
  expect(() => myParser('0.,4')).toThrowWithCause('INVALID_VERSION')
})

By using custom matchers to catch the error, we will not only make it more reusable, but we will also make our linters happy since it's considered a bad practice to catch errors manually inside tests.

Since macOS Big Sur, there is a new Virtualization Framework that software like Docker can use to access the computer resources more effectively. This, when combined with the new VirtioFS introduced in macOS Monterey 12.2 will make your containers fly like never before.

I especially notice the difference when starting my NextJS apps (it went from ~20 secs to ~3) or when installing dependencies (time is drastically better here).

With 3 NextJS apps running, I can see how much better my resources are used:

CPU (Idle containers: 3 - 5 %)

Allocated Memory (8.02 GB of the maximum configured for Docker, 8.00 GB)

Before this, Docker was using qemu and it was eating a lot of memory (more than the limit I configured).

All you need to do, if you have macOS 12.2 or greater, is to enable these experimental features in your Docker for Mac settings, and restart it:

Setup a monorepo with NPM or Yarn

You can setup monorepos in various ways: with npm, yarn, pnpm, nx, lerna, bit.dev, etc. but since my project doesn't need to maintain/publish packages to the npm repository, I chose to go simple and try with npm and yarn.

To add monorepo support in npm or yarn, you simply have to add a workspaces entry to your package.json file in the root directory of your monorepo project, like this:

{
  "private": true,
  "workspaces": [
    "packages/*"
  ]
}

Initially, I wanted to have apps/* and packages/* separately, but that was just making my tooling & scripts more complicated, unnecessarily. So I decided to put everything (NextJS apps and shared packages) under packages/*, for simplicity.

Now here comes the tricky part, because I had a very hard time understanding how could I reuse my packages (written in TypeScript and CSS modules) in my NextJS apps.

The npm workspaces documentation is very deficient and doesn't tell anything about how to import your packages. So I thought I could just include them as a dependency, using local package resolution:

{
   "dependencies": {
      "@myorg/designsystem": "file:../designsystem"
   }
}

Then you run npm install and your local package is hard-linked in the node_modules folder of the package that requires it.

With yarn, instead of the file resolution, you would use workspace:*.

The difference between yarn and npm when it comes to workspaces is that yarn is more efficient: it keeps a single node_modules folder in the root, instead of one per package (like npm does). Yarns also prune the dependencies automatically.

The only problem with having a single node_modules is when you or some of your dependencies require a different version of React. When some of your packages need a different version of a dependency that is shared with other of your packages, you end up with the same package in the root node_modules and in your package's node_modules folder that needs a particular version.

This can cause problems, especially in NextJS apps, which don't like to have another version of React in the parent node_modules, so you need to take special care of that.

So, after understanding how dependencies were working for each package manager, then the problem came when I tried to import the source files (in TS) of my packages. The compiler will complain that there is no loader configured for that (sorry, what??).

Yes, I had to compile my packages to JS before they could be used by the others. Somehow I felt this wasn't the right approach and that it wasn't going to work for me, as it was making my developer experience very bad and frustrating.

If you try to import TypeScript files directly, that won't work, unless you enable NextJS experimental features to include external files and configure your tsconfig.json files to include all packages TS/TSX. I tried that and it felt ugly and hacky. CSS Modules don't work with this approach.

The official Vercel approach for monorepos

I was about to surrender and abandon the idea of having a monorepo with my related NextJS apps, and then I found this official Vercel example of how to configure workspaces with yarn.

It saved my life. You only need to configure your workspaces with yarn, and use the next-transpile-modules NextJS plugin to start being able to import your packages directly.

No manual compilation steps, no need to add it as a dependency, and no need for tsconfig.json changes! All works out of the box: JS, JSX, TS, TSX, including JSON and CSS Modules.

This is the configuration I used for my NextJS apps:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true
}

const sharedPackages = ["../designsystem", "../core"]

const withTM = require("next-transpile-modules")(sharedPackages) // monorepo support

// withTM needs to be the further-most plugin you wrap your config with.
module.exports = withTM(nextConfig)

After this, you can import your packages using their package name:

import { Button } from "@myorg/designsystem/forms"

You only need to have a index.ts or index.js file in the root of every package (even if they just have an empty export), in order for the next-transpile-modules to work, but you can organize your code in folders, you don't need to export everything in the main index file.

I still need to figure out whether this will also work inside NextJS server-side scripts (e.g. importing node js/ts files of my packages in pages/api/* files), but for now this solution covers all the needs I had of reusing my components in different NextJS apps.

It works so seamlessly that every time you change your packages, NextJS will detect that and make a hot reload while you are developing, which makes the developer experience really great.

Deploying the apps of your monorepo on Vercel

Once you are done, to deploy every NextJS separately in Vercel, you only need to configure the root directory in your Vercel app's settings. For example, if your app is under packages/myapp, this should be the value in the Vercel settings.

You also should set up the Git Ignore Build Step section, to ignore the build if the files of your app directory didn't change, by adding git diff HEAD^ HEAD --quiet ..

Otherwise, new deployments will be triggered even if you changed files of other apps. If you changed a component dependency that is under another package folder, then you will need to trigger the build manually or write a more advanced git check.

To know more, check this guide on Vercel's website and this other article from them.

There is little to no documentation about how to mock TypeScript interfaces in Jest and what I found was most of the time misleading or not what I was looking for.

First I used jest-mock-extended but I was not very convinced and I ended up playing around with jest until I came up with a working solution.

I think that this could be applied to both NodeJS and browser JS apps. First, you obviously need jest and ts-jest as devDependencies.

Now let's say I have this code under src/DomainModel/Reply and I want to test a class called ReplyService, mocking its dependencies.

src/DomainModel/Reply/ReplyInterface.js

export interface ReplyInterface {
    text: string;
}

src/DomainModel/Reply/ReplyRepositoryInterface.js

import {ReplyInterface} from "./ReplyInterface";

export interface ReplyRepositoryInterface {
    findOneByIntent: (intentName: string) => Promise<ReplyInterface>
}

src/DomainModel/Reply/ReplyService.js

import {ReplyRepositoryInterface} from "./ReplyRepositoryInterface";
import {ReplyInterface} from "./ReplyInterface";
import {ReplyNotFoundError} from "./ReplyNotFoundError";

export class ReplyService {
    constructor(
        private replyRepository: ReplyRepositoryInterface
    ) {
    }

    public async getReply(intent: string): Promise<string> {
        let reply: ReplyInterface

        try {
            reply = await this.replyRepository.findOneByIntent(intent);
        } catch (e) {
            if (!(e instanceof ReplyNotFoundError)) {
                throw e
            }
            reply = {text: `Sorry, I cannot help you with '${intent}' in this moment...`};
        }

        return reply.text;
    }
}

Here you can see that ReplyService has a dependency on ReplyRepositoryInterface but, how can we mock this interface to test our service in isolation as a real unit test?

To mock a TypeScript interface in jest, you only need an object that has the same functions as the interface. In our case, we need to mock a function that returns a promise. We can do that with jest.fn():

const replyRepositoryMock = {
  findOneByIntent: jest.fn().mockReturnValue(Promise.resolve({text: replyText}))
};

And this is how one of the tests would look like:

src/DomainModel/Reply/ReplyService.test.js

import {ReplyService} from "./ReplyService";

test('getReply returns the expected reply text', () => {
    const intent = 'baz'
    const replyText = 'ok'

    const replyRepositoryMock = {
        findOneByIntent: jest.fn().mockReturnValue(Promise.resolve({text: replyText}))
    };
    const replyService = new ReplyService(replyRepositoryMock);

    return replyService
        .getReply(intent)
        .then(reply => {
            expect(replyRepositoryMock.findOneByIntent).toBeCalledWith(intent);
            expect(reply).toBe(replyText)
        })
});

Jest is very flexible and it also allows you to mock entire packages, like axios:

src/Infrastructure/UltimateAi/IntentSearchService.test.js

import {IntentSearchService} from "./IntentSearchService";
import axios from "axios";
jest.mock('axios');

test('example axios mock', () => {
    const resp = {
        data: {
            intents: [
                {name: "Foo", ratio: 0.7},
                {name: "Bar", ratio: 0.2},
                {name: "Baz", ratio: 0.5},
                {name: "Foo2", ratio: 0.71},
                {name: "Bar2", ratio: 0.2},
            ]
        }
    };

    const axiosMock = axios as jest.Mocked<typeof axios>
    axiosMock.create.mockReturnValue(axiosMock)
    axiosMock.post.mockResolvedValue(resp)

    const client = new IntentSearchService(axiosMock)
});

As you can see you can mock pretty much anything with Jest, it's pretty simple and you don't need any other libraries to accomplish the same.

First of all I have to say I am not a React JS expert and this article may contain mistakes or things that can be improved, but it is what worked for me so far.

Before jumping directly into learning how to manage location data with a global state like with e.g. Redux, I wanted to see how can I do it with only what React + React Router offer out of the box.

Setup

You can bootstrap a new app using Create React App or you can use an existing one. Either way, you'll have to install React Router:

npm install react-router-dom

At the moment of writing this article, I am using react-router-dom@^5.2.0.

Wrapping your application

Next thing to do would be to wrap a component with a Router component. In my case I wanted to wrap my whole app with a HashRouter component (there are many types of routers), which changes the location hash.

import React from "react"
import ReactDOM from "react-dom"
import "./index.css"
import App from "./components/App/App"
import * as serviceWorker from "./app/serviceWorker"
import { HashRouter as Router } from "react-router-dom"

ReactDOM.render(
  <React.StrictMode>
    <Router basename="/">
      <App />
    </Router>
  </React.StrictMode>,
  document.getElementById("root"),
)

// ...

This will enable us to use React Router specific hooks such as useLocation, useHistory, etc. in our App component, since we can only use them in the children of Router components, not outside.

Make sure you set up the basename attribute correctly, depending on the router type you chose.

Be aware that if you are using BrowserRouter, which changes the URL with the HTML5 History API, you may not be able to share permalinks since it may need server-side changes.

I had that problem when hosting my app in Github Pages: if you refresh a page containing a route, it will show a Github 404 error page. My solution was to use a HashRouter instead.

Render a component based on a route

In order to match a route and render a specific part of your application, you need to have a Switch component. In my case, I added it as part of my App component, because I only need one switch.

Whenever you define a Switch, you are telling the Router what to render in each path, whenever your location changes:

import { Route, Switch } from "react-router-dom"
import PokedexPage from "../pages/PokedexPage/PokedexPage"
import PokeDetailsPage from "../pages/PokeDetailsPage/PokeDetailsPage"
import BoxesPage from "../pages/BoxesPage/BoxesPage"

function App() {
  return (
    <Switch>
      <Route path="/pokedex">
        <PokedexPage />
      </Route>
      <Route path={`/pokemon/:slug`}>
        <PokeDetailsPage />
      </Route>
      <Route path="/">
        <BoxesPage />
      </Route>
    </Switch>
  )
}

export default App

As you can see, I defined many routes as /pokedex, another one with a parameter named /pokemon/:slug and at the end the home page as /.

Inside a route component, you define what will be rendered in each route.

Let's take a look at the PokeDetailsPage component:

import React from "react"
import { Link, useParams } from "react-router-dom"

function PokeDetailsPage() {
  let { slug } = useParams()

  return <div>
      <p>Pokemon: {{ slug }}</p>
      <Link to={"/pokedex"}>Go back</Link>
    </div>
}

export default PokeDetailsPage

In this page we retrieve the path parameter :slug, we render it and we display a link to the Pokedex page.

But wait, why nothing happens when we click the Go back link? The answer is that we didn't make our components dependent on the location state.

Location-aware components

One simple way to make our app to be re-rendered on location changes is to add a key attribute to the top most element that will need re-rendering. The key should represent the state of the location.

For example:

// ...
import { Route, Switch, useLocation } from "react-router-dom"

function App() {
  const loc = useLocation()
  const locationState = loc.pathname + "@" + loc.hash + "@" + loc.search.toString()

  return (
    <Switch key={locationState}>
      <Route path="/pokedex">
        <PokedexPage />
      </Route>
      {/*...*/}
    </Switch>
  )
}
// ...

In this case, every time the location hash or query string changes, a page component of the Switch will be re-rendered.

This is of course not optimal because it basically renders the whole page again, but it is a quick way to make your application aware of the location changes.

I am sure there are more efficient ways to accomplish the same. What do you think?

I hope that at least this article was useful for you to get things done and working, which was my intention.

In Domain Driven Design, the Domain Model represents the processes and rules of your application and its main business, is the central and most important part of your application.

There are many ways to implement this concept, some of them being the Hexagonal Architecture or the Onion Architecture.

In this article I will talk a special variant of the Hexagonal Architecture, which I personally find more convenient, because it feels more natural when developing and is easier to understand: the Onion Architecture, proposed by Jeffrey Palermo in 2008.

Hexagonal vs Onion Architecture

Whilst the Hexagonal Architecture has really no layers necessarily and talks about ports and adapters (which in my opinion they are kind of an inflexible concept), the Onion Architecture encourages you to do a better separation of concerns and good use of the Dependency Injection (DI) and Inversion of Control (IoC) patterns from the start.

In the Onion Architecture, the dependencies are always pointing inwards. The inner layer is the Domain Model and the outer one is the Infrastructure layer, which takes care of communicating with the external world.

Between the Domain Model and Infrastructure layers, you can have as many layers as your application or team needs, but in this article, I will only cover the Application and Presentation layers additionally.

As you can see in my proposal, the Presentation layer shares the same "level" as the Infrastructure one. Why is that? Because of the golden rule.

The main rule

The main rule of the Onion Architecture is pretty simple: the outer layers can use elements from the same layer or inner layers, but not the other way around.

On the diagram, Presentation cannot be at a lower level than Infrastructure or vice-versa because they cannot use each other.

Code is always coupled towards the center which is the Domain Model and, since the Domain Model is the center, it can be only coupled to itself.

The parts of the software that are more subtle to change are or that we have less control about are in the most outer layers, while in the inner layers we have the most meaningful parts of our application.

The Onion Architecture relies heavily on the Dependency Inversion principle: the Domain Model (the core) needs implementation for its interfaces, and if those implementing classes reside at the edges of the application, we need some mechanism for injecting that code at runtime.

If you are a PHP developer like me, you'll know that Symfony is the most indicated framework to accomplish that.

In the JavaScript world it's not so easy unless you use TypeScript and interfaces and do the dependency injections manually or with a library.

The Domain Model Layer

The first and most important layer is the Domain layer, the inner most one. This is the life of your application. It represents your app's domain, the business logic and its functional implementation, everything it can do.

Classes (that we will call services from now on) created in this layer are business-logic related: e.g. a service that defines all operations we can do on an entity.

It consists of the following types of objects:

• Domain Services: Each component of the domain represents a private service that matters only within the domain, e.g. a state machine manager.
  • Interfaces that represent the outside world
  • Factories
  • Value Objects (a.ka. DTOs or classes with no business logic, only properties)
• Repository Interfaces
• Entities / Domain Objects (similar to Value Objects)
• Collections
• Object Factories
• Domain Events, e.g.: an order got paid.
• Domain-level Exceptions

All these types of objects together represent the business logic of the project.

Domain Model Layer Rules

1. This layer MUST NOT have interaction with the outside world or any other layer. That means that code from the other layers MUST NOT be used here.

2. The only responsibility of the domain layer is to define how your business work, not how data is queried or persisted, that's why we SHOULD NOT use repositories directly here but define and use their interfaces instead.

3. Database layer abstractions occur in the Infrastructure layer, the Domain Model only defines its interfaces, which is the one the business code should always refer to when writing strict type-hinting.

The Application Layer

The application layer is where all our application features or "use cases" live.

It basically wraps around the domain layer, adding specific business rules on top (e.g. how much fees should the app charge to a customer, etc).

These are features and rules that are not necessarily part of the Domain Model, but that define the app's business. This layer is also called "Domain Rules" or "Domain Services".

May consist of the following types of objects:

• Use Cases or Application Services: wrap around the domain layer, adding extra logic or conditions specific to the use case.
• Application Events, something that happen internally in the application itself, e.g.: a specific method was called, the app has started/finished doing something, etc.
• Application Event Subscribers
• Application-level Exceptions

Use Cases are Application Services that wrap around the domain layer with. They are typically used via Use Case Request and Response value objects.

Product features like "confirm a payment", "create an order", etc. should be defined here.

Use Cases can also be seen as all the possible actions that an actor can perform in your service.

Application Layer Rules

1. The application layer SHOULD only know about the Domain Model layer and nothing about the Presentation or Infrastructure ones.

2. Use Case(s) SHOULD have a single purpose, therefore they MAY have just one method, e.g execute.

3. Use Cases SHOULD always use value objects as method arguments and as return values.

4. If there is no returned value, it SHOULD be declared explicitly, e.g. as void.

5. Use Cases SHOULD only throw Application-layer exceptions, catching the expected ones from the Domain Model.

6. Multiple small Domain Model components/services SHOULD be used instead of having large Use Case classes.

7. Use Case(s) SHOULD NOT extend other Use Case nor depend on another Use Case: they SHOULD be independent. Services or Components of the Domain Model are the way to go for code modularization/reusability.

The Presentation Layer

This is the outermost layer (together with Infrastructure) and it is the window of the external clients to your application. It defines the interface of your application for the outside world.

It may consist of the following types of objects:

• HTTP controllers which handle HTTP requests and responses
• Forms or HTTP Request transformers (e.g. transforming requests to value objects to be used in the use cases)
• Input Validation
• Security (Authentication, Authorization, Roles)
• Response factories (from use cases, exception to response converters, etc.)
• CLI commands (console)
• Message Queue producers (outgoing messages).
• Message Queue consumers (incoming messages), consuming the Domain Events of external services.

Presentation Layer Rules

1. The Presentation layer SHOULD only know about the Application or DomainModel layers and nothing about the Infrastructure one.

2. HTTP Controllers are just a presentation layer of the Use Case(s).

3. HTTP Controllers SHOULD catch Application layer exceptions and resolve them into an HTTP response with a proper HTTP status code.

The Infrastructure Layer

The infrastructure layer is where we will implement the adapters of the interfaces of the other layers, most of them being typically in the Domain Model.

This layer mainly has everything related to external parties, e.g:

• DB adapters / repository interface implementations
• HTTP clients for external services
• Wrappers for vendor libraries or implementations of their interfaces

Infrastructure Layer Rules

1. This layer will mainly need code from the Domain Model, but will probably not use any of the other layers. To keep code clean, it's recommended to use only the Domain Model layer.

2. Domain Model repository / API client interfaces SHOULD be implemented here.

Code organization example of an onion-based Symfony app

This is an example structure similar to the one I use on my Symfony applications in my current company. It's not perfect but after some years using the Onion structure we've made some changes to make it more evident where to put everything.

/tests
/src
    /Application
        /UseCase
            /CreateOrder
                CreateOrderRequest
                CreateOrderResponse
                CreateOrderUseCase
    /DomainModel
        /Order
            /Service
                OrderCodeGenerator
                OrderStateMachine
            /Factory
                OrderFactory
            /Entity
                OrderEntity
            /Event
                OrderCreatedEvent
                OrderShippedEvent
            /Repository
                OrderRepositoryInterface
    /Presentation
        /Http
            /Transformer
                RequestDataTransformer
                ExceptionResponseTransformer
            /EventSubscriber
                ExceptionSubscriber
            /Controller
                CreateOrderController
            /ResponsePayloadFactory
                CreateOrderPayload
        /Cli
            /Command
                CreateOrderCommand
        /Mq
            /MessageProducer
                OrderCreatedMessageProducer
            /MessageConsumer
                PaymentTransactionMessageConsumer
    /Infrastructure
        /Repository
            /Mysql
                OrderRepository
        /PaymentProvider
            /PaymentProviderClient
        /FileStorage
            /FileSystemClient
            /S3Client
        /Symfony
            /Authentication
        /(any vendor library)
            /MyVendorLibraryExtension
    /Support
        TokenGenerator
        DateFormatter

Conclusion

After more than 10 years of experience as a PHP developer, this is the cleanest structure I've worked with, and believe me, PHP projects can get really messy very quickly.

One of the most important things in a team, an organization is that you have common software development guidelines where you explicitly define what's the Target Architecture(*) of your different services, well-explained documentation that everyone understands and adopts in their daily work. It should be the reference in everyone's code reviews and it should be something you all agreed on as a group.

(*) A Target Architecture provides the details of a future state of a software architecture being developed within an organization.

There also is this video from Eric Normand, where he explains the Onion Architecture more in detail in a very friendly way while driving his car 😎.

References

• Hexagonal Architecture (Wikipedia))
• The Onion Architecture by Jeffrey Palermo
• Three Layered Architecture in Symfony
• phpat is a library that will help you respect your architectural rules in PHP projects.
• The Clean Architecture - Another approach similar to the Hexagon and Onion architectures

With this tool you will be able to work in an isometric grid and create mock-ups of your isometric tiles, that you can later edit in your favorite pixel art editor.

The expected workflow will be: you create a shape (or a composition of them) in this editor and then you copy-paste it in your favorite pixel-art editor, e.g. Aseprite.

You will be able to compose them in multiple layers, resize, change colors, stroke, rotation, tile size, etc.

If you are familiar with 3D editors, this tool will be very intuitive to use.

I spent a whole week working on this project but at least now it is a little usable.

I hope to make it more useful in the future, adding more features, making it more usable and efficient, but that depends on the expectation and interest I see in your comments :)

You can find this project on my Github:

Editor home page: https://itsjavi.com/isometric-tileset-studio

This year Apple will likely release new mac models (14" and 16" MacBooks and probably a new iMac) that will only integrate Apple Silicon chips (rumors talk about M1X or M2, doubling power), removing the option of Intel macs forever.

What does that mean for people that use Windows over Bootcamp to use Windows-based software or games?

Of course, Apple will probably still have old Intel-based models available for a while, but we might not see Windows compatibility for a while in Silicon macs.

The decision depends on Microsoft, whether they want to make their ARM-based Windows 10 compatible with the M1 chip or not.

Then they'll have to negotiate with Apple to upgrade Bootcamp in the next macOS versions to support Windows for ARM.

Right now Windows for ARM has some other important limitations: it is only compatible with 32-bit applications, although they're already working on an ARM64 version. Some users made it work on M1 chips via Parallels, but support is far from perfect.

For gamers, it means that even if Windows ends supporting M1 chips and macOS, all the Windows games will also need to be compatible with ARM processors, and here comes the biggest issue: there is still a very little catalog of games compatible with ARM desktop processors. We might see this trend changing in the upcoming years, but support is still in the early stages.

If you are a game developer, you won't have many problems with Silicon macs, because most game development IDEs support or will support soon compiling games for x86/AMD64 CPUs. The only issue would be testing those builds.

If you are thinking about buying a new Apple computer with a Silicon chip for gaming, maybe it's still not a good option. Investing in a dedicated console or a budget PC with a decent graphics card might be a better option right now.

There is an ongoing transition that will probably take some years to become more matured and supported by the app and game developers of both ARM-based macOS and Windows.

If you want to start game development it’s not always easy to decide which engine fits best your needs.

That’s a process that has taken me almost 4 years of basic experience with engines like Melon JS, Unity, LÖVE, Game Maker Studio and now Godot. I can say I have touched all of them for a while, not very deep, but deep enough to realize which one was the best fit for me and the kind of games I want to do: 2D, sprite-based, grid-based movement (like a classic RPG).

What's the best engine? nothing in the internet will provide you the right answer: it depends on the kind of game you want to make, your experience as a programmer and what engine you feel more comfortable with.

In this article, I am always talking from my experience and probably many of the mentioned engines here may fit better for your games than others, but it doesn’t necessarily have to match my preferences. This article comes from a game dev beginner's perspective who is also a full-time Senior Software Engineer with more than 10 years of experience.

Said that, let’s begin talking about the game I was trying to develop and about the pros/cons I have found in every engine I tried to develop it with.

My project

I always loved Pokémon since I was a child. In fact, my nickname is based on the franchise.

I wanted to start game development making something that I already know well and that I’d love making: that’s right, I wanted to remake a Pokémon game, in my case Gameboy Color’s classic Gold and Silver.

New Bark engine in Unity 2020

I started in 2D to avoid having to learn all about 3D which seems more complex to me than using sprites in 2 dimensions. When I master 2D I might consider learning 3D later.

My idea is to create an engine that I can reuse later on to make my own monster-collecting games (not tied to Pokémon).

The first thing was obviously to choose the game engine. It was not an easy task (even less a few years ago): it involved a lot of googling things like “what’s the best engine for 2D game development”.

Initial project scope

My initial scope of the game was always simple: instead of thinking about all the aspects of the game I wanted to introduce or all that I need to do and frustrate myself, I always tried to create and fully cover in detail the first town of the game in every engine. That would cover these aspects:

• The tile-based map, including indoors (houses).
• The player animation and grid-based movement + running
• Collisions with tiles and other objects.
• Interacting with objects: dialog boxes, printing text char by char and auto-advancing to the next line.
• Teleport to another part of the scene with a fade-in/out transition: going inside and outside houses.
• Basic game save/loading (player position)
• Changing the background music depending on the area the player is in.
• Sound effects (interacting with dialogs, collisions)

Example in Unity (frame-rate looks jumpy because of the GIF)

The tested engines

MelonJS (5.0)

MelonJS is a good engine to play with if you have a Web / JavaScript developer background. It provides you the basic blocks to build very simple games but it’s not aimed for making big complex games.

PROS

• Familiar languages. Quick to start with if you come from a Web / JavaScript developer background.
• Compatible with browsers. You can run your game in the browsers or package it inside an Electron app for desktop.
• Ok for simple games like Flappy Bird
• Open source and free, community maintained.

CONS

• It doesn’t have a dedicated IDE to work visually with the engine.
• You have to write almost everything from scratch since the engine provides the very basic building blocks.
• Not recommended for complex professional games.

LÖVE (11.0)

With LÖVE I had a similar feeling as with MelonJS. There are not many differences apart from the language (Lua) and the way it packages and executes the games: In Android you have to install a separate app in order to execute LÖVE games. That’s something I didn’t like.

Maybe LÖVE has a more mature API than MelonJS that lets you build a bit more complex games, but still: no IDE, a lot of code required for getting started with a simple game.

So it has basically similar PROS/CONS to MelonJS.

Unity (v2017–v2020)

I tried to use Unity before any other, but the complexity of the IDE scared me a bit in the beginning and I opted for more simple engines.

I came back to Unity after discovering that I was not going to go any further with the previously mentioned engines. So I gave it another try starting from the 2017 version until v2020.

My first impression after learning the basic concepts of game development with the other engines was: wow, this feels very powerful and I have a good language like C#.

Starting a 2D game of my characteristics in Unity is not an easy task. Back then in 2017, there were no 2D pixel-perfect tools or tilemap editor, so everything looked a bit glitchy.

I had to watch lots of tutorials for a year in order to have the first town of the game working with dialogs and grid-based movement but nothing more.

I needed code for almost anything, I had to write my own physics engine because the built-in one is not so flexible, so I could not use it for grid-based movement and collisions because I always had problems (e.g. bounciness, stuck pixels, etc.).

PROS

• Industry-standard for many kinds of games (mostly mobile and PC / console casual games). If you master this engine you probably can apply for a job in lots of game dev companies.
• Robust OOP Language which is used in many other areas not only game development: C#
• The engine evolves very quickly. The jump from 2018 to 2020 was huge. Lots of things have changed.
• Future looks promising for 2D game development, but still uncertain.
• You can use the engine for free, even commercially up to a certain amount of sales. That’s great for learning the engine.

CONS

• Still feels incomplete for 2D development after all these years. I feel that 2D features are not a priority for Unity, they still seem more focused on 3D: 3D games, CAD (for automotive, construction etc) and VR/AR right now. It’s not clear nor transparent the direction they are taking for 2D game development.
• Learning curve is high, even more for 2D game development, since Unity was initially intended only for 3D. This has improved a lot in the last years but there are still many lacks that are covered in other engines very well.
• Lack of information and tutorials for classic 2D games without modern physics. This has been a major handicap and time-consuming for my case. Something so basic like transitioning from one room/scene to another with a transition, there are not good examples for that.
• The Animator frame function callbacks are not reliable like in other engines.
• Convoluted event system. They are complex to set up and you don’t have a way to have a clear overview of what happens when.
• The built-in components are very generic, they allow you to make any game you want but at the cost of also having to write a lot of code. The package system has been a good addition though.
• Migrating your game to a new version may break it. The amount of changes introduced from 2018 to 2020 is huge (and they are still in progress like the DOTS engine). It makes you think if it’s a good moment to learn this engine or wait.
• Many 2D-related bugs that you don’t really know if they will ever fix them.
• Not having a dedicated language for game development makes the usage of C# very convoluted in many cases like the mentioned game event handling.

… and I probably found more obstacles that made me give up with Unity… after trying GameMaker Studio 2.

GameMaker Studio 2.2

I won’t extend so much with this engine because I only have used it for less than 6 months, but here are my impressions:

PROS

• The engine, at first sight, seems a good choice for 2D game development. Many basic aspects of 2D development are covered here while they are lacking in other engines like Unity. Lots of aspects seem very convenient.
• Learning curve is low: I wrote the same basic town in 1 month instead of 1 year that took me doing the same in Unity.
• Good for quickly prototyping games and for learning the basics concepts of game development.
• You can make your games without writing a single line of code: using Drag-and-Drop components. That’s good for non-developers to write casual games.
• If there is any error in your whole code or some reference missing, the editor complains before running your game. That’s good in case you changed script names or refactored code.
• Undertale and Swords of Ditto were made with this engine, so it’s possible to create full complex games that can be commercialized if you don’t care about the cons.

CONS

• If you are not a developer, the engine teaches you bad practices that you will probably drag for years in your developer career. So, if you never worked with an object-oriented programming language I recommend you to avoid starting with GameMaker but start simple with an engine that has OOP like LÖVE (it uses Lua) or even MelonJS (now that Javascript supports proper classes). Later on you can try GameMaker if you want, then you will be able to notice the difference.
• GML has no OOP (Object-Oriented-Programming). Every data structure has to be in integer-indexed arrays. Managing your variables using enums and arrays is a no-go for big projects. Although OOP will be partially introduced in v2.3 and will feel similar to Javascript objects and functions, it still needs a long way to go to be mature.
• Porting code from Unity / C# to GML was not easy due to the huge differences in the way GameMaker is doing things.
• Some built-in components are opinionated (not flexible enough), meaning that they will somehow dictate how your game has to work.
• There is no built-in 2D lighting system. You have to write it from scratch or use assets from the marketplace or the community. That might be ok if you don’t need this feature for your game or you make your shadows/lights with translucent layers.
• As soon as your project gets big it becomes unmaintainable: lots of windows here and there, lots of scripts, lots of data structures as arrays and enums
• Hard to refactor code: you have to do it everywhere manually, the IDE doesn’t detect the usages of your scripts, variables, etc. that you are renaming.
• It has a trial, but after that you have to pay for a license. Not nice if you just want to learn this engine before deciding to use it commercially.
• You need to log in with your account in the IDE in order to use it, so you cannot use it offline. If your network is slow, the IDE can take a lot of time to start.

Then I started following HeartBeast tutorials and videos on YouTube and decided to give Godot Engine a try.

Godot Engine 3.2

I have heard about Godot years ago but I thought it was like another indie game development engine and I was afraid that It wasn’t going to be enough for what I wanted to achieve.

Well… I am discovering that I was wrong.

In May 2020 I started watching HeartBeast’s Godot tutorials on YouTube and, after trying all the other engines I have to say it has been very easy to learn, also because HeartBeast is a very good teacher.

Let’s say that Godot has the good stuff that I found in GameMaker and Unity combined together, plus it has a dedicated OOP gaming language that it may not be as powerful as C# but it does what it should do and it’s improving very fast.

My first impression of this engine is: wow, they got things right like I expected them to work, everything is so intuitive and works so conveniently together.

In less than one month I achieved half of what I did in GameMaker, but the quality of my code and the scenes feels much much better.

It also takes me more time because I am writing the game in a modularised component-based way: similar concept as React JS where each component can be reusable and can potentially work on its own. That combined with signals/events is very powerful.

So here is my (preliminary) opinion on Godot:

PROS

• Free and open source. Community driven. You clearly see the direction this project is taking, you can tell by the Github Issues/PRs/Milestones. So there are no surprises.
• Multi-platform without the need for extra licenses: Desktop, Browser or Mobile.
• Transparent founding system. With all the donations they hire people to take the engine to the next level. That’s something I like and the support of the community is impressive.
• Intuitive IDE. If you tried Unity and GameMaker, you will love Godot. In the beginning, you will be a bit lost to know what’s everything, but with some tutorials, you get it quickly.
• Faster than the competitors. Running my simple town is much much faster than with Unity or GameMaker.
• It also has live code editing like Unity.
• Huge set of reusable components, which are highly flexible and customizable compared to the other engines. This saves you lots and lots of code.
• I didn’t try animations much deeper than just sprites, but they seem more powerful than in Unity or GameMaker. Function callbacks in the Animation timeline are reliable and called when expected if you don’t have important frame drops.
• A great and friendly community with tutorials that still work even after minor version updates. I have found some outdated tutorials, but not so many compared to the other engines and the things I had to change to make them work were not hard to find.
• I love the node/scene system and concept. You can build perfectly decoupled and reusable scenes, helping you write better games more than with any other game engine. You can build much cleaner games by having each level (composited by multiple scenes) working as a standalone mini-game. That’s perfect for testing and learning how coupled are the different parts of your game.
• Another thing that I really love, that in other engines is more convoluted: The signals system (events). They are so visually intuitive that you feel encouraged to use them from day 1. That also helps writing better & decoupled code.
• It has a dedicated OOP language, written specifically for game development: GDScript. Although the engine also supports VisualScript (like GM Drag and Drop), NativeScript (for more low-level code) and C# !! Even If I like C# a lot, I stay with GDScript because it feels much easier and convenient for the engine, plus it seems to get new features before C#.
• Documentation of the Godot engine API is just great, extensive and well explained. You don’t have to leave the IDE to check the docs or wait for a webpage to load inside a frame.
• Shaders are very easy to integrate and learn to write in this engine. It has a visual diagram tool to build them if you don’t want to write their code.

CONS

• I wish I knew this engine before. Unity and GameMaker are better known because the most part is the hype and marketing behind them. Godot community doesn’t invest much in that, but rather focuses on the quality of the engine and spends the most part of the budget on that. I little more promotion and marketing for Godot is needed I would say.
• GDScript feels great but it there is some stuff that I would like to see improved (and actually it is being in the works): Ability to export any data structure in the inspector, variable groups and hints in the inspector, type hinting for any class.
• The IDE has serious performance issues when playing animated textures in the 2D view. It’s being investigated but I have to hide the layer so my laptop doesn’t burn.
• The TileSet editor seems very powerful but it has UX/usability problems, same for the 2D view TileMap editor. Various proposals are being considered.
• There is no built-in sprite editor but that’s ok for me since I can also work with Aseprite. Using Aseprite and GameMaker sprite editor at the same time was tedious because of the different keyboard shortcuts.
• The engine it’s not compatible with any console and it probably won’t because it’s open-source, so it is meant for developers that intend to release their games for Desktop, Browser or Mobile only. By the time your game becomes popular, probably you will have enough budget to hire people to port it to consoles using another engine.

Conclusion

I know, this is a long post to read, but thank you for taking your time.

I wanted to provide you all what I experienced using these engines (or a summary of what I can remember) so with all that information you will have a better understanding of what can you expect and the struggles you will find if you want to do similar 2D games as I do.

Of course, choosing the best game engine that suits your needs it’s always up to you.

In my opinion the clear winner here is Godot, at least for now. It seems to have everything I need, It has a quick learning curve, good tutorials, encourages good practices, … and more that I have to discover.

I will keep posting Godot tips and tutorials here as well as some of the progress of my games, mostly the parts that I think you might find interesting or that were the most challenging for me.

I end this article with this thought: if you have a game idea, don’t try to do everything the first day because you’ll get frustrated. Set yourself small scopes and goals for your game. Keep trying, do little by little every day or weekend, at your own pace and the most important thing: Never give up!

When you build a tile-based game it’s what you usually want for your UI: too look pixel-perfect with that retro look.

Here is the example in Unity:

In the Panel component in Unity, you have the option of using a “Tiled” image type easily. As you can see, it detects the 9 tiles automatically.

After some more digging, it turns out that in Godot Engine you have a very powerful and customisable component (even more than in Unity) called NinePatchRect. With it, you can use any texture and slice the region you are interested in to use it as the borders of your panels / dialog boxes.

The important inspector settings are:

• Region Rect: Defines the area of the texture to use
• Patch Margin: Defines the margins of the borders, so they keep always the same size/ratio even if your panel is resized.
• Axis Stretch: Defines how to stretch the tiles when resized. Here usually you will want it as “Tiled” in both horizontal and vertical. This way the tiles are not stretched, but auto-tiled one next another when you resize the panel.

Here is an example:

Basic NinePatchRect configuration in Godot for 16x16 px tiles