DEV Community: Jakub Przyborowski

Using Vue without actually using Vue. Ovee.js 2.1 just got released.

Jakub Przyborowski — Wed, 03 Nov 2021 17:52:29 +0000

When we first started drafting the idea for Ovee.js (check out the repo on GitHub and leave a star 🙏), we’ve decided that we don’t want to reinvent the wheel and wanted to avoid reimplementing complex parts like reactivity or templating for the millionth time. It’s a popular principle among back-end frameworks - Laravel heavily reuses parts of Symfony, Symfony by default comes bundled with Doctrine, Nest depends on Express (which even can be replaced with other implementation on demand). Yet, in the front-end field, each of the big frameworks is built fully independently (correct me, if I’ve missed something).

For the initial build of Ovee.js, we’ve chosen on-change for handling simple reactivity, and lit-html for templating. We’ve also built an optional module on top of Barba for asynchronous page transitions. This decision helped us to ship the first working version of the framework relatively fast, avoiding major bugs in the potentially most complex parts.

Since the release of Vue 3, we started to tinker with its internals and decided to eventually replace on-change with a much more capable solution.

More power with Vue 3 modules

Vue 3 brought great, well-received changes to its API. But from our point of view, we also got two really important changes, that might get overlooked by most developers.

First thing is that the reactivity got rewritten to Proxy API, which solves the constraints of the previous implementation, and is much more clean and modern. For Ovee.js, we intended to use Proxy API from the very beginning, which is why we couldn’t rely on Vue 2 reactivity for the initial build.

Second, an even more important change is that Vue is now shipped in modular form, and parts of the framework are available as separate NPM packages. This way, we can use @vue/reactivity without having the whole framework as a dependency. And when it comes to the number of dependencies, a smaller footprint means faster installation and a smaller node_modules.

The experience of using independent parts of Vue 3

As we intended to only replace the Ovee’s reactivity, we’ve added @vue/reactivity and @vue/runtime-core to our dependency tree. The first one, just as the name suggests, gave us tools to rebuild our ReactiveProxy class. Usage is super easy:

import { reactive } from '@vue/reactivity';

const proxy = reactive({});

The latter brings watch, computed, and watchEffect. Earlier, we had @watch decorator, but with our own implementation. Now, we could just use watch from @vue/runtime-core package. Going further, we added 2 new decorators: @watchEffect and @computed, which just wrap their respective methods.

But that’s not everything! The TemplateComponent from Ovee.js also relyed on watch and reactivity system, to automatically re-render lit templates when any of the reactive data changes. We replaced it with helpful watchEffect underneath, which ultimately reduced lines of code and simplified how the system worked.

Currently, we only replaced the old reactivity system and added a few wrappers. But Vue reactivity system is so versatile, we can build a lot of cool new features as part of the core package and new modules as well! Of course, the same benefits are now available to the developers using Ovee.js.

Overall, the whole Vue reactivity system is well documented and easy to use. It is also written in TypeScript, with very good typings, which is also a big con for us, as we use TypeScript as well.

Wait, so what’s that Ovee.js thing?

Ovee.js is a component framework designed to work with server-side rendered markup. It means that it is not a competition for Vue or React, but rather a modern approach for projects, where we would use jQuery in the past. You can read more about Ovee.js here and take a peek at the official documentation.

Create tidy front-end components for server-side rendered markup - introducing Ovee.js framework.

Jakub Przyborowski — Wed, 25 Aug 2021 15:57:59 +0000

I remember, when I first discovered jQuery. It was around 2009 and I was a junior back-end developer, who loved also CSS but hated didn’t understand JS. I was amazed, that suddenly I had a tool, that let me create front-end interactions without much struggle. For the next few years, I became a full-stack dev and loved to have jQuery at my side. Yet, there was one thing I really missed from my back-end garden: the structure that MVC frameworks gave me. You know, out of larger organizations, there was no front-end architecture in most projects that were made in the late 2000s and early 2010s. Just a bunch of random event handlers put into a single functions.js file. Maybe, but just maybe, some prototype-based classes, if you were fancy.

To be honest, this style of doing JS still resonates in the works of many devs even today, if they are working on a simple website, not an enterprise-level app. I don’t wanna hate, I wanna help - but let’s continue with the story for now.

In search of a good front-end architecture for non-application projects

In search for better front-end architecture, around 2011-2013 I got fascinated by Backbone, then Angular.js. These frameworks were cool for building SPAs, but no one but some hipsters used them to build websites, as achieving SSR was a huge struggle. And you still wanted your site to be indexable by search engines.

In the meantime, when building websites, I’ve started to structure my JS into a pile of objects with simple auto-initialization magic. Still jQuery, still no build tools (other than some minification maybe). Sucked a little less, but still meh.

There’s a life beyond everything-in-js

With the rise of React and Vue, things got fancy. We now have static generators like Gatsby, Next.js, Nuxt.js, Gridsome, and dozens of others. And with them, the problem with SSR disappeared. But, have you tried to build a marketing-focused website on top of any of these? Yes, these are great tools and have many advantages, but the development cost can be 2-3 times higher, and you lose the simplicity of the “classic” sites built as templates for one of popular CMS systems.

With my team at Owls Department, we try to value picking the right tools for the job over following the lead of hype and fanciness. I really, really love Vue and evangelize it to my clients, when we pitch for application projects. Yet, when it comes to most website builds, we go “classic”. I believe there’s a place for using different approaches when seeking a successful front-end product - take a look at Signal’s Basecamp or GitLab - these are both mostly server-side rendered products and using them feels nice and smooth to me.

Look mum, I’ve built another JS framework

Over the years, I’ve searched for a good solution to keep the JS that we build for server-side rendered markup up to the same coding and architectural standards that we use when building SPAs with Vue. And didn’t find a good one, so started to DIY something for my team. The first version of our internal framework was built around the idea of a component, that hooks to matching structure in html (selected by data- parameter - inspired by good ol’ Angular v1) and encapsulates the JS magic. It still used jQuery here and there. But it freakin’ worked. We were able to build quite complex sites, while keeping the code maintainable. We were able to reuse components, so the work was done faster.

In late 2019 I had a chat with some team members, that it would be good to finally ditch the jQuery and also switch from our proprietary pjax clone to Barba for page transitions. When doing my research, I found Basecamp’s Stimulus (https://stimulus.hotwired.dev/) - now part of Hotwire suite. I love the work of these guys, but I don’t like how much JS-related stuff (e.g. binding events) is done in the server-side rendered markup. There’s also Strudel.js (https://strudel.js.org/), which comes from a similar background to ours. When I started to modernize our framework, I’ve found a lot of inspiration in Strudel’s design and API (kudos to the team behind this pastry-flavored framework).

By the mid of 2020, we had the new framework ready to use internally. We’ve decided to publish it as open-source under MIT license, and named it Ovee.js. It’s fully written in TypeScript (huge contribution from @F0rsaken), has good unit test coverage, and is here to help teams and individuals, who struggle with problems similar to ours. Now it’s ready for you to discover it!

Show me the code

Let’s take a quick journey, so you could feel how the framework tastes.

Installation is nothing special:

yarn add ovee.js

A component is a building block of your website or an application. In Ovee.js, it is represented by a class and corresponding markup. The framework detects html tag matching the component by either tag name or a data parameter. Each instance of matched tag gets its own instance of the component class.

Let's take a look at an example:

<incremental-counter class="incremental-counter">
    <p class="incremental-counter__value"></p>
    <button class="incremental-counter__button">increment!</button>
</incremental-counter>

import {
    Component,
    bind,
    el,
    reactive,
    register,
    watch
} from 'ovee.js';

@register('incremental-counter')
export default class extends Component {
    @reactive()
    counter = 0;

    @el('.incremental-counter__value')
    valueElement;

    @bind('click', '.incremental-counter__button')
    increment() {
        this.counter++;
    }

    @watch('counter', { immediate: true })
    update() {
        if (this.valueElement) {
            this.valueElement.innerHTML = `Current value: ${this.counter}`;
        }
    }
}

As we can see, within the component class we can reference children elements that are contained within its corresponding DOM node. The framework gives us convenient mechanisms to bind events, DOM elements and react to data changes.

The framework is reactive if you want it to be reactive. It uses the power of MutationObserver, so you don’t need to manually initialize or destroy components when you modify the DOM (e.g. by changing views using Barba).

The initialization is pretty straightforward, and if you ever used any modern framework, you’ll see the similarities.

import { App } from 'ovee';

import OveeBarba from '@ovee.js/barba';

import IncrementalCounter from './components/IncrementalCounter';

const root = document.getElementById('app');

const app = new App({
    components: [
        IncrementalCounter
    ],
    modules: [
        OveeBarba
    ]
});

app.run(root);

Oh, and you remember when I told you that it’s meant to work only with server-side generated markup? Oh, I kinda lied. You see, that’s the core use case. But sometimes a project that in 90% fits the use case for rendering markup on the back-end, this one pretty dynamic part. And when you think about how to approach it, this part shouts “duude, React or Vue would serve me well”. For such scenarios, we’ve extended the default Component’s design with the power of Polymer’s lit-html. So, some of your components can be client-side rendered, if you want.

import {
    TemplateComponent,
    bind,
    reactive,
    register
} from 'ovee.js';

@register('incremental-counter')
export default class extends TemplateComponent {
    @reactive()
    counter = 0;

    @bind('click', '.incremental-counter__button')
    increment() {
        this.counter++;
    }

    template() {
        return this.html`
            <p class="incremental-counter__value">Current value: ${this.counter}</p>
            <button class="incremental-counter__button">increment!</button>
        `
    }
}

Neat, right? This way it’s your decision, how you build your stuff. Not the framework’s.

What’s next

Our team at Owls Department uses the thing daily. We collect the team’s feature requests and have plans for the future development of the framework. The biggest change we have in mind is adapting Vue 3’s reactivity in place of the solution we have in place. With this change, we are looking forward to performance gains, especially when it comes to TemplateComponent. If you have any ideas or want to contribute, give us a heads up!

Further reads

I hope you’ll find the project interesting and I’ve convinced you to try Ovee.js.

In the future, I’ll cover Ovee’s features in more in-depth articles. Please, follow us on Twitter (@owlsdepartment), Dev.to (@owlsdepartment) and Instagram (@owlsdepartment), so you don’t miss any future publications.

The full documentation can be found here: https://owlsdepartment.github.io/ovee/

As the library is still fresh, the community is still to come. But, what is important - our team is using Ovee.js on daily basis, so we are commited to maintain and improve it in future. If you have any questions or ideas, don’t hesitate to catch us via Twitter (@owlsdepartment) or through GitHub Issues.

Cheers!

We made a mobile game with Godot. Here’s what we've learned.

Jakub Przyborowski — Sat, 26 Dec 2020 12:48:31 +0000

Some time ago, our team built a mobile game. But first things first. Let’s start with a short disclaimer - we are mainly web developers. We love to tinker with different technologies, and some of us had some experience with Unreal Engine, Unity, Phaser or even Flash in good ol’ days. Yet, we’re not specialized in game dev - that’s a fact, nothing to be embarrassed and we think an important acknowledgement for the rest of this article.

Note: this article was based on our experience with Godot in versions 3.2.2/3.2.3. Since then, new versions might have been published, and some of the mentioned issues might be now solved.

The subject

We got commissioned to build a mobile game for an NGO. It had to be educational, yet we really wanted to keep it playful and engaging for a casual player. Our creative team came up with an idea of an illustrated 2d platform game, interspersed with educational quizzes from time to time.

Why we’ve picked Godot

As our design team decided to go with an illustrational style, we knew that we’ll be working mostly with animated sprites. The gameplay quality was really important for us, so we knew we want to use an existing engine, rather than reinvent the wheel. We thought about Unity for a brief moment, but we don’t love how it works with version control, as scenes are saved in binary format. We also prefer to pick open source projects when possible. If you google for such engine, you’ll probably find Godot, Defold and some 2d-only engines.

We wanted to pick something universal, that could benefit us also in 3d game dev in future. Defold seems nice, but at the time of our decision, it seemed much less mature and popular (1.2k stars on GitHub, vs 35k for Godot). Also one of the team members had already played with Godot a little bit, so we went with his recommendation.

The language

While many competitors in the area of open-source game engines rely on Lua, Godot brings its very own GDScript language. It also brings support for C++ and C# on top of Mono. Yet, GDScript seems like the best option as it deeply integrates with the engine so most times code for the same functionality will be much simpler in GDScript. Also, most of the materials you’ll find over the Internet is based on GDScript. So, as long as you’re not a daily C++ or C# developer, you should probably pick GDScript. And that’s what we did.

GDScript is a python-influenced language, created with a single purpose. In our experience, it’s easy to learn. If you casually use Python, you’ll feel most at home. Honestly, it felt easy to start using even for a person who hasn’t used Python for like 10 years.

We really liked the integration with the engine. It brings easy to use event system, that was good enough for most of our cases. The option of writing semi-async parts of code with yield is really helpful. Yet, there are also disadvantages of being a single-purpose and not widely used language. It lacks the idea of private fields or methods, so you end up with an underscore-prefixed mess. Instantiating object is inconsistent - for scripts you call new(), yet for scenes, you call instance(). What’s worse, you can instantiate a script instead of a scene by mistake if you name it with class_name or load .gd instead of .tscn file and you won’t get any clue from the engine or editor other than meaningless runtime errors. Also, a clean way of importing classes/scripts together with a proper package manager would make it less like it’s 2003 and you’re still rockin’ PHP3. Yet, if you learn to live with those disadvantages, it does its job and you’ll find it okay.

GDScript also comes with optional Types. The notation is similar to Python’s typing, but you can only use native types along with classes, that you can access either by making them global with class_name keyword or loading using const … = preload('…'). No generics, interfaces and other things that you expect to find in a strongly typed language. Yet we still appreciated the existing support and used it as much as possible.

But things are changing and GDScript will get its next iteration with Godot 4, which looks very promising, to be honest.

The editor

Godot as a fully blown game engine comes with its very own editor for both visual stuff and scripting. What’s impressive is that the editor itself is fully written in Godot. Works okay and has a lot of helpful features, including animation editor (if you ever used Flash, you’ll feel the nostalgia), visual editor for scenes and UI and easy way to bind signals (events) with your scripts. It also has built-in documentation, which is a nice bonus.

On the other hand, we sometimes felt it tries too hard to do everything within the engine. For example, things that in most programs are using OS controls like file open/save dialogues, here are also custom-built. Maybe we wouldn’t mind if the experience was similar to the native one, but using it is dreadful and we’d really appreciate native controls here instead.

For writing scripts, you can use an external editor (there are third party packages with syntax support for VSCode, Atom and Sublime). But that, at least for VSCode, requires the official editor to be open in the background anyway.

Building the gameplay

Godot goes really well with 2D games and the amount of built-in tools and solutions is huge. We rarely had a problem, that a tool or helper was missing.

Games in Godot are built with nodes. The ability to combine two totally different nodes, that the engine gives you, is amazing! Also, in our opinion, the documentation is very good, at least comparing to other game engines. Sometimes it lacks more explanation or examples, but overall it’s in a good state.

But, unfortunately, nothing is perfect, and neither is Godot.

We were struggling with ParallaxBackground, because of the different resolutions we had to handle. And as it turned out, there is a nasty bug, that occurs when you change your screen resolution (at least in versions 3.2.2/3.2.3 that we’ve used). There were also some weird quirks when it came to physics of the body, controlling it, repositioning and stuff like that.

And yet, there were many things that we were very positively surprised with. To name a few - sprite animations, 2D transformations, global and local coordinates, collision handling and many other things. Prototyping, managing assets and level designing were a breeze. And at the end, we managed to (with some effort) get rid of (or around :)) all major bugs.

Building the UI

As even the Godot’s own editor is built on top of the engine, its support for building UIs is a first-class citizen. It brings you a catalogue of ready-made, stylable components that should do the job for most scenarios. The game we were building had quite a lot of UI for its size, as besides the core gameplay we also had to build functionalities like quizzes, educational tips, accomplishments lists, disclaimer screens and stuff like that.

Godot provides us with two ways of styling components. You can either manually attach styles per each component (these can be saved into files and reused between multiple components), or you can define so-called themes. This way, you can style a component together with its children - kinda like with CSS, but with a visual editor. To be honest, we found using just reusable styles without whole themes thing more streamlined and easy enough to maintain for a project of our scale.

What we found surprising and very unfortunate, was the total lack of touch support for scrollable containers. You should keep this in mind, that when implementing UI for mobile games, you’ll be required to code goodies like kinetic scrolling all by yourself.

What you will find helpful, is that the engine brings us multiple ways for creating animations. Besides the mentioned visual animation editor, you can use built-in tweens. If you ever used TweenMax, you’ll know what to do. It lacks a true timeline for orchestrating animations from code, however in our case playing a little with delays and durations did the job. What’s missing is an option to provide a custom easing curve, so you need to relay on built-ins.

One big, yet important hole in the ecosystem is the lack of any navigation management. So if you want to build some hierarchy between UI screens, together with animated transitions, you’ll once again be on your own.

In terms of animations, you’d be able to build something modest pretty easily. However, if you’re about to create anything fancy, you’ll quickly end up messing with shaders. So what’s missing is something to fill the gap between super simple and super complex animation techniques.

Integration with native APIs

TL;DR: if there’s an existing plugin, it’s easy. If not, you’re on your own.

Our game was intended mostly for Android, and for this OS, there is a pretty good new plugin system, introduced with 3.2 version of Godot. It’s much more straightforward than the previous module system. Godot does not bring too many platform-specific integrations. If you want to integrate analytics, push notifications, social media integrations etc, you won’t find any of these stuff within the core so you’ll need to rely on plugins. That’s a reasonable idea as it allows Godot maintainers to focus on the engine’s core.

At the time of writing this article, a lot of possibly useful plugins don’t exist yet, and if you find what you need it would probably be some alpha version with few stars on GitHub, poor documentation and not always working properly. We hope this to change in future, but if you plan to use Godot for your next project, do some research to avoid trouble in the middle of the job.

Summary

Overall, we’ve enjoyed working with Godot on the project. We’ve built a playful and enjoyable game and were able to rapidly prototype its mechanics at an early stage. However, due to limitations of the engine’s UI framework and lack of high-quality plugins for Android, we found it pretty challenging to develop a smooth experience around the core gameplay.

Anyway, we deeply appreciate lots of hard work done by Godot’s maintainers and we’ll keep our fingers crossed for the engine’s future development.

Thanks for reading!

If you’re looking for a team of creative and passionate developers and product designers, don’t hesitate to visit our website at https://www.owlsdepartment.com or email us at hello@owlsdepartment.com!

Authors:
Kuba Przyborowski @przyb
Milosz Mandowski @F0rsaken