Forem: Nathan Fritz

The Future of Virtual Assistants

Nathan Fritz — Tue, 01 Jun 2021 16:53:41 +0000

I did a series of talks on the future getting weird several years ago. This is a self-indulgent post where I once again explore my futurism hobby.

Virtual assistants like Siri, Hey Google, and Alexa are going to get much more useful in the coming years. With the rise of machine learning, including technologies like GPT-3, these assistants will get a lot more conversational, but it goes beyond that. These services will get personal, and become infinitely more useful as they become our agents on applications and websites.

Personalized

Assistants will collect data from our conversations to combine with data from other sources in order to create a more personalized experience. Making suggestions, for example. They might even reach out to you during the day.

"Hey, Nathan?"
"Yeah, Siri?"
"You're trying to build a pushup habit – this might be a good time."

You could also respond by shushing it, or arguing that you just wanted to do pushups that one time.

Modern thinking has it that building habits requires a trigger, and your assistant could provide that. Along those lines, it could track your calories, guide your meditations, make suggestions for upcoming anniversaries and birthdays, and more.

Some of these things might sound like notifications, but it's a little different. The assistant will be making guesses as to when you're not busy based on movement, heart rate, and other clues; it'll start to learn when you don't mind being interrupted. It'll be much more polite about it than any notification could be, not that you couldn't ask it to stop.

Other ways that an assistant will adapt to you is with subtle clues about your tone of voice, and other behaviors. In order to build a rapport with you, it'll mimic your inflections and speech patterns. Research has shown that we mirror body language and speech interactions in order to build mutual respect.

An agent will start to anticipate your usage patterns to make interactions more convenient for you. It'll notice when you've missed something, and help you fill in the gap. Beyond just anticipating your Starbucks order (more on that later), an assistant will realize that you're rushing to work, and might send a message ahead of you to let your employees know that you're going to be a few minutes late for the first meeting of the day. The agent is watching out for you, and will try to make your day go more smoothly.

An Explosion of Applications and Use Cases

The actions an agent will be able to take is going to explode. Right now, if McDonald's wanted Alexa to be able to make an order, they'd have to register an extension with Amazon and include all of the anticipated words and commands along with their responses, or a service callback to make a dynamic response. Each user will then have to add the McDonald's service to their Alexa and cross-authenticate with their McDonald's user account. Additionally, each user will have to learn and memorize the type of things they can say to use the McDonald's service in Alexa. All of this complexity keeps the number of services fairly low, and user participation even lower.

But this will change in the coming years. Phone applications and websites will be able to include standardized interfaces specifically for virtual assistants. These APIs will describe what kinds of things the agent can do with the service, suggested phrases and promotions, information dependency based workflows, and examples. This won't be nearly as strict as a traditional low-level API, because the agent will use language processing and other machine language techniques to interpret the application; it'll be somewhere in between a user interface and a computer interface. The assistant will combine its newfound knowledge of the service with what it knows about the user, and create a custom experience on the fly with the user.

Driving. "Hey Google, I'd like order a Big Mac from McDonald's up ahead."
Looks up the McDonald's agent API. "Sure, do you want that in a meal or just the sandwich?"
"Just the sandwich."
"They have seasonal vanilla custard filled Holiday Pies right now. You've been good and haven't had a dessert in a few days. Would you like one?"
"Oh they have those again? Nice, I'd like one."
"Your total is $9.14. Would you like me to finalize the order?"
"Oh, can you add an ice water?"
"Yes. The total cost is unchanged. Would you like me to order a Big Mac, Holiday Pie, and ice water for $9.14?"
"Yes, that sounds good."
"I submitted your McDonald's order on your VISA card ending in 1234. Please pull into order space #4."

Since companies no longer have to painfully create and register agent skills, there will be a lot more services available to the agent. With the service-registration and user-friction gone, and fully customized experiences using natural language, there will be an explosion of consumer use.

Agent-to-Agent

Your agent instance will be able to interact with the agents of others, at least within a given platform (I'll talk more about open and federated standards another time). This will be useful for scheduling appointments, buying gifts, and checking in others that trust you.

"Does my partner have any late meetings tomorrow?"
Agent looks up their calendar directly, or asks their agent through a special API.
"Their last work meeting is at 2:30pm."
"What should I get them for their birthday?"
"They recently added a book to their wishlist – Brandon Sanderson's Rhythm of War, the latest in the Stormlight Archive."
"Oh yeah, she loves those books. Can you call the local books store and have them hold a copy for me? Also, order a flower arrangement from the flower shop around the corner."
"I'll do that. Do you want me to confirm the arrangement and price before I order the flowers?"
"No, you know what they like."
"Okay. I'll have the book store hold the book at the front counter for you, and I'll order those flowers. I'll let you know when I'm done."

At any point, your agent could contact other agents or even people on the phone to ask the necessary questions. The other agents will know your relationship with their users, and will only allow your agent to have appropriate and approved types of data.

This example might seem a little weird – having what is essentially a program pick out flowers for your partner. I also found it deeply weird in 4 Hour Workweek when Tim Ferris asked his internet assistant to write a heartfelt apology email to his wife. To each their own.

The Future is Weird

Virtual Assistants are frustratingly rudimentary right now, but over the next decade, they'll get a lot more useful. These agents won't be generalized artificial intelligence, we're simply not that close to developing one yet, but from a user's perspective, the lines will be blurred.

I want to be clear that I'm not advocating for these features nor this future. I just think this is where things are headed based on the potentials at play, trends in natural language processing, privacy in the US, and the rise of cloud machine learning. I'll get into my opinions on the morality of these trends in a future post.

Regardless of the morality of it, virtual agents will make our lives easier, so it'll be an easy sell.

Stay tuned for Part II, where we explore the repercussions of these technology trends.

Keep Your OS Clean with $HOME/.local

Nathan Fritz — Sun, 07 Feb 2021 07:30:31 +0000

In a *nix environment (Linux, MacOS, WSL), software without packages can sometimes install to global spaces by default. This is often undesirable, due to running unverified scripts as root, conflicts with other packages, and potentially breaking the software during an OS upgrade. Instead, these custom installs should be placed in your home directory. In my case, $HOME is /home/fritzy or /Users/fritzy on MacOS.

But where in your $HOME? As the title implies, $HOME/.local.

This directory is a GNOME convention that other software has adopted as well. Similar to /usr/local, it is designated for custom or non-package installed software. The . at the beginning of the directory name has the added benefit of hiding the directory, preventing cluttering an often-used space.

Setting up $HOME/.local

If it doesn't exist, go ahead and create it, along with a bin directory as your user. No special permissions are needed.

mkdir -p $HOME/.local/bin

Then, make sure that $HOME/.local/bin is in your $PATH, preferably with a higher priority than /usr/bin.

For Linux Bash users do:

echo PATH=$HOME/local.bin:\$PATH >> $HOME/.bashrc

Custom Installers

Now we can install some software. I wanted to install Starship, a cross-shell prompt in my WSL2 Ubuntu. The only documented way to install this is to install by directly executing a download -- questionable from a security perspective.

curl -fsSL https://starship.rs/install.sh | bash

Instead, I downloaded and inspected the script. I discovered a few things. By default, it would install to /usr/bin, a global space requiring root access. But there was good news; I found a command-line option to set the install directory.

curl  https://starship.rs/install.sh --output install.sh # download
chmod +x install.sh # make it executable
./install.sh -b $HOME/.local/bin # the -b option is what discovered
rm ./install.sh # don't need this anymore

I then followed the instructions for setting up Starship for Bash.

echo 'eval "$(starship init bash)"' >> $HOME/.bashrc

Custom Compiled Installs (Node.js)

If you build custom software, you'll want to find the "prefix" option, and set it to $HOME/.local. When following build instructions, you should ignore anything that tells you to use sudo when installing; you won't need it with a prefix in your home directory, and doing so may cause problems later.

Let's clone Node.js, compile it, and install it to our .local prefix.

Checking Out

cd ~/build # I use a build directory for custom compiling
git clone git@github.com:nodejs/node.git
cd node

Updating Tags

git fetch --all --tags # update fetched branches and tags
git tag # lists tags

As an aside, if you want to sort tags with semver logic, you can update your git config.

git config --global tag.sort version:refname

Checkout a Tag As a Branch

git checkout tags/v15.8.0 -b build-v15.8.0

Configure and Compile

Now we can compile it.

./configure --prefix=$HOME/.local
make -j12 # number of hardware thread on my cpu
make install # sets everything up in your prefix directory

The first make line will take a bit, but hey, you look really busy and smart when you're compiling code.

Now when you run node -V, it'll show your newly install Node.js version. You also now have the added benefit of being able to install 'global' npm packages without sudo. You'll notice that you now have include lib and share directories in your $HOME/.local, just like you would with a /usr/local prefix.

You can get similar benefits of using nvm without having to compile.

Keep It Clean

Installing unpackaged software in your $HOME/.local directory is more secure, more stable across OS upgrades, and prevents unnecessary root usage going forward. It can take a bit of investigation with some software, but is worth having a cleaner install in the end. Ideally, the vast majority of your software simply uses OS supported packages, but now you have a plan for when it doesn't.

For you MacOS users, OS upgrades would regularly break Brew for me, but you can even install Brew into your home directory.

Please comment below, or send me your thoughts on Twitter @fritzy.

One Web Architect's Core Beliefs

Nathan Fritz — Mon, 25 Jan 2021 17:04:24 +0000

Our core beliefs are the principles that we've learned through experience or subscribed to from others in order to quickly make decisions and value judgements. They occasionally need to be re-evaluated, but without them, we'd spend all of our time analyzing instead of acting.

Over time, as a software developer, you'll adopt and develop software development core beliefs. It's important to be conscious of them, so that you can contextualize their application, debate your peers, and know when to re-evaluate.

Here are some of the web architecture core beliefs that I've developed and adopted in my 20 years as a software developer. Each of these could be a blog post, and probably already are. My former colleagues may be able to remember specific incidents and hard lessons learned that cemented some of these beliefs. 😬

Core beliefs, be they about software or life, are personal; I'm not asking you to agree with or adopt any of these, but if something rings true, certainly feel free.

Inactive Software Is Dead Software

// Detect dark theme var iframe = document.getElementById('tweet-1345969273278091264-279'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1345969273278091264&theme=dark" }

In the web world, software ages very quickly. Dependencies are out of date in months, and with a culture of small packages, your software may have a lot of dependencies.

Every time you set a piece of software down, it's going out of date. Bit rot is real. The platform that you built it for moves on, your embedded dependencies have software vulnerabilities published, your services change APIs, etc. It'll take some effort to bring your software back up to date the next time you need to work on it.

When choosing dependencies, it's usually a bad idea in the web world to use anything that hasn't been updated in the last 6 months. You've been warned.

Are there exceptions? Sure. What if your software uses a stable platform, has no or few dependencies, and is super small. Again, context is king.

The KISS Principle (Keep It Simple Stupid)

The Kiss Principle is 80 years old at this point. It states that complicated systems are much more prone to failure.

There's a lot of these software principals. You may want to adopt some of them if they ring true to you.

I also like Gall's Law.

// Detect dark theme var iframe = document.getElementById('tweet-1352511188181999617-472'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1352511188181999617&theme=dark" }

The thing is, we're engineers, and we over-do it sometimes. Over-engineering is always a temptation for software developers that love their craft. It's probably the most common software development sin. There's a time and a place, which we'll get to in a bit.

Client State is a Cache

Client-side web applications have to hold some data, and the client is almost never the source of truth. That means that any data you maintain in a client is part of a cache and should be treated that way.

// Detect dark theme var iframe = document.getElementById('tweet-7269997868-947'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=7269997868&theme=dark" }

You have to be very deliberate with cached data. Here are some guidelines:

Only cache data that you're very likely to use.
Don't cache data that the user doesn't have permissions to see.
Avoid making decisions based on cached data.
Invalidate cached data when the source of truth updates.
Don't update the cache from user actions without marking it as pending.

Dealing properly with client state data is a very large topic, but thinking of it as a cache first can help you make the right choices for how to use and maintain that data.

100% Test Coverage Is Achievable and Desirable

When writing a library or API, 100% test coverage should be a priority. Yes, it's doable. In the worst case, it's time-neutral, and the benefits are great and sometimes non-obvious.

// Detect dark theme var iframe = document.getElementById('tweet-1352517396343386114-234'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1352517396343386114&theme=dark" }

I'm not an expert when it comes to testing on the client-side of a web application, but I have seen significant coverage of the data-management and component side done to great effect.

Tests not only validate that your code is following the intended purpose, but it also documents that intended purpose in great detail. It gives future contributors a starting point when looking at a piece of functionality -- they can use your tests to suss out how to generate the required inputs, where in the code functionality lives, and exactly what your expectations for the code were. Good test coverage reduces the cognitive overhead of someone else working on your code.

Tests give you a solid foundation when refactoring -- if your coverage is good enough, you'll know where you need to keep working and when you're done refactoring. Tests give you the confidence to make big changes.

Code coverage will also help prevent spaghetti code. As Isaac points out, code that is hard to test is a code smell.

Business Logic Needs to be Isolated

All of your business logic for a web app should be in the server. UX logic can live on the client, and data management logic can live in the database, but you're asking for trouble to do any business logic anywhere except your server process. Ideally, it should be in it's own layer within that process.

When you spread business logic out, it makes it hard to find and maintain, and you greatly increase the complexity of your app. You're opening yourself up for security vulnerabilities (the very nature of a web client having authorization logic is a vulnerability in itself).

So what is business logic? Any action that results in a function that changes/accesses data directly related to the purpose of the application.

It's okay to use a stored procedure for actions that are not specific to the application, like maintenance, migrations, sharding, etc. It's okay to have client logic for displaying views and generating API calls. If you're checking to see whether a user can make an API call before making the API call, that may be a sign that something is amiss.

Keeping all of the business logic on one server layer makes it more testable, makes it easier to swap out database and API layers, and reduces the number of things a developer has to think about while making changes or debugging.

Don't Expose More Surface Area Than You Use

Any code that you're not using in your project is technical debt, and any API that you haven't tested is a vulnerability. It's a trope at this point for developers to brag about how many lines of code they've deleted rather than the number that they've written with a wink. It goes along with the KISS principal. Don't be overly clever in order to reduce your line-count, but generally less is more.

One of the reasons why I generally don't think GraphQL is a great solution is because you're deploying more capability than you're using. You're giving clients and users a full query language, of which they'll only use a small portion, in most cases, and when it doesn't work or surfaces a denial-of-service vulnerability because they can write a query that performs poorly, that's a bug you're going to have to fix.

There are valid use cases for exposing a query interface like GraphQL, and there are ways of limiting its surface-area, and ways of getting complete test coverage, but all of those things involve considered effort. Here is an Apollo GraphQL Guide for dealing with some of these problems.

Every line of code and every piece of functionality you provide is an opportunity for bugs and increases maintenance. If you and your users aren't going to use it, don't include it.

Don't Innovate When Developing an MVP

// Detect dark theme var iframe = document.getElementById('tweet-1345958359342612482-605'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1345958359342612482&theme=dark" }

This twitter thread pretty much covers my view here. It's a bit of a hot take, but it goes along with some of my other core beliefs and the KISS principal.

Basically, the time for innovation is not during the initial version of a project. You should do your experimentation separately, either as isolated prototypes and experiments, or incrementally after you prove to the business that the MVP has value.

Clever is the Enemy of Good

You should write code for people first, not computers. It's important that team members and your future self be able to easily see what your code is meant to do. Follow language idioms, don't take shortcuts just to shave off a few lines, and don't try to combine your logic to fulfill many purposes in one clever bit of code.

Instead, clearly handle your logic in an idiomatic way that walks through the problem step-by-step. Simplicity is handling the core logic and edge-cases with clear code. Don't go out of your way to save keystrokes as typing is not the time consuming part of writing software; thinking is. You can always go back and make things more terse if you've thought of a better way to be clear and handle more edge cases later.

Your goal is to make your code appear pedestrian, despite solving the problems brilliantly. This may take some iteration and a lot of thinking. You'll know you're doing well if both senior and junior developers understand your code and pull requests at a glance. Make sure to give similar feedback when doing pull requests for other developers.

For example, creating a clever mix-in function for a language that only supports direct inheritance will make the code hard to follow, and make the software more difficult to debug. Keep things simple.

Uncompromised Multi-Master Replication is a Myth

Warning: This section is about the CAP Theorem, so feel free to skip it. Do not operate heavy machinery while taking CAP Theorem.

Multi-master replication will always have compromises. The CAP theorem states that between C.onsistency, A.vailability, and P.artition-tolerance, you can never maintain all three at once.

Well-implemented distributed databases document their claims and don't claim to violate the CAP theorem. These claims are typically AP (available and partition-tolerant) or CP (consistent and partition-tolerant). On a practical level, all distributed databases aim to be partition-tolerant, safely recovering from node and network failures.

A partition is when one or more nodes are either down or can't communicate with all other nodes. These partitions can happen in unexpected ways, where the boundaries of communication is different for any given node.

An AP database keeps data available during network partitions, but can produce conflicts and inconsistencies such as foreign references or incomplete transactions. A CP system does not produce conflicts (usually, check your guarantees) and keeps data consistent, but some reads or writes can be blocked during a network partition. RDBMS databases, like SQL, are typically CP, while document stores are more often AP.

Conflict resolution is a business logic problem, and needs to be solved specifically in the context of the data being stored. If two writers are editing the same article during a network partition, a last-write-wins strategy could delete one of the editor's changes. In that particular case, you may want to resolve the conflicts manually with document-merge strategy. An AP database often resolves conflicts with a last-write-win strategy by default, so be mindful.

MongoDB famously had ridiculous performance and replication claims when it first launched in 2009. It took quite a few years to clean up. I learned a lot in those days from Aphyr's posts, exploring database clustering claims with his testing tool, Jespen. Beware of marketing-driven engineering products!

In short, when selecting a distributed database product, make sure you understand their claims. There's no magic bullet when it comes to horizontal scaling.

Make a Plan for Scaling

You can scale pretty high with a single application server and a single database server, but you should also have a plan for scaling up later. Implementing a scaling solution during development of an MVP introduces unnecessary complexity (violating several of my previous core beliefs) and is an example of premature optimization

Depending on your business needs, you could scale horizontally, making it so that you could have any number of application servers and database servers (See the Multi-Master core belief above -- this can be complicated to get right). Horizontally scaling makes sense if you need to support many writes per second, and your users and data aren't logically siloed.

You could also scale through siloed sharding. If your product primarily manages logically grouped users (a common case for sharding) each group can have a dedicated set of application servers and databases. Interactions between user groups is limited. This is one of the easier ways to scale.

If your user numbers are capped, like in an IT intranet application, simply writing an efficient application is enough to scale to 10s of thousands of active users. You should still design your application in such a way that it doesn't matter how many instances you run at once for reasons of uptime and staged releases.

Keep in mind, running multiple instances of your API against a single database server (or single master server with many read-servers) will only scale to a point. Eventually you'll exceed your ability to write data to the database and will need to shard your users/data or use a distributed database.

Knowing how you're going to scale up ahead of time will help you make implementation decisions during the MVP stage of your application. Remember, having to scale up is a good problem to have, and you'll have more resources to implement your plan later.

Developer Experience Matters (DX)

At one of my first full-time programming jobs 20 years ago, I spoke with a senior developer about a problem I was having configuring the project for a niche QA use-case. They pointed me to a CLI program they wrote to manage that configuration. He was the only one using this tool so far, so I was shocked to see how nice it was. He'd take the time to have self-documenting command-line arguments and a clear README that went over its purpose and usage.

Why had he bothered to take the time to make this script so easy to use when he was the only user? Because developer experience matters, even just for himself, and he suspected others might find it useful eventually. At the time, I would have just slapped together a script, made all of the options constants that I would have to manually edit each time, and moved on.

It left an impression, and I began taking more care in the experience of the software I was writing, because it usually payed dividends in time. I was never embarrassed to share my little tools and libraries with others.

Years later, when I started regularly writing open source code, I took the time to see what successful open source projects included in their README. It's made a huge difference for my career.

Your Core Beliefs

When I started this blog post, I asked people what their core software beliefs were. I got some pretty good answers. Feel free to send me any additional thoughts or feedback below or at @fritzy. For more, follow me here, on Twitter, and on github.com/fritzy.

In this post, I set out to explore and share some of my web architecture beliefs. Some of them are objective fact (like multi-master databases), some of them are value statements (DX matters), but they're all things that I keep in mind in order to quickly architect quality software.

A similar article was published during the writing of this. There's a lot there that I agree with, but certainly not all of it. I don't endorse their views, but it's the kind of exercise that I'm encouraging with this article.

Introducing Ape ECS (js!)

Nathan Fritz — Sun, 27 Sep 2020 03:36:11 +0000

Whenever someone announces an ECS library, or really anything to do with ECS, the post must describe what ECS is. These posts always get it wrong because it's impossible to explain without mixing in bits of implementation. Even the Wikipedia article falls into this trap. I will not break with tradition.

First of all, you can find Ape ECS at https://github.com/fritzy/ape-ecs and you can install it into your project with:

npm install ape-ecs

Okay, but what is ECS?

ECS stands for Entity-Component-System, which name the parts of the paradigm. It's used in game and simulation development.

Entities are uniquely identified and are defined by which Components or Component instances are associated with them (ugh, we're already getting into implementation).

Components are uniquely identified instances of data-types with association to an Entity.

Systems do work on Components.

The idea is that you keep your logic separate from your data, unlike Object-Oriented Programming where you encapsulate your data with your logic. But how? Well, we'd have to get into implementation details.

Generally you have a System which could be a function or a class (in Ape ECS you can override the built in System class or just use a function) that has a single job that it does like Gravity.

Most implementations have a way of querying Entities and Components beyond just getting all of the entities or getting all of a Component of a given type. Minimally you can do a Join or Union to get all of the Entities that have at least a set of Component types. Some ECS implementations have more advanced queries, like Ape ECS Queries.

class Gravity extends ApeECS.System {

  update(currentTick) {

    const frameInfo = this.world.getEntity('GameLoop')
      .getOne('FrameInfo');
    const entities = this.createQuery()
      .fromAll('Position', 'Vector')
      .execute();
    for (const entity of entities) {
      const vector = entity.getOne('Vector');
      vector.y += frameInfo.deltaTime * 9.807;
      vector.update();
    }
  }
}

The magic of ECS is that our Gravity system works on anything that has a Vector and Position. We could make it as specific as we want, but what's more important is the things we don't care about. Gravity would work on any Entity that has those Components, whether it has a Sprite, AI, Weapon, Effect, whatever. We don't have to depend on a hierarchy of classes to determine whether Gravity works on it.

Why use ECS though?

If your game is complicated, dynamic, or meant to be a simulation, a lot can be gained from separating your logic and your data. For one, you have dynamic composition of your entities.

Want the player to go from running around as a human to controlling a mech? Easy, just add your PlayerControlled component to the mech entity. Want to mutate your character to have an extra arm? Just add an extra Arm component and the equipping System will deal with it just like the other two arms.

Systems interact with each other more when they're decoupled. A bunch of them might act on or inspect the same Components, essentially piping inputs and outputs to each other. This leads to high levels of data-integration, which leads to Emergent Behavior. In the example of the Gravity system, it would interact indirectly with a Movement system that used Vectors to update their corresponding Position. There's a story about many systems interacting with each other in Dwarf Fortress to kill cats that is a classic example.

There are other benefits as well -- it tends to be more performant to run one function (System) which loops through many entities than it is to loop through many entities and run a series of methods on each. It's also easy to serialize your data and save your state when your data is separate. The Blizzard Overwatch architect talked about how it made it easier to make a competitive network game using ECS.

Okay, but Why Ape ECS?

It's performant, it's flexible, and it has some neat features.

Here is what makes it stand out:

Advanced Queries for entities.
Persisted Queries (indexes) are updated as Entity composition changes.
Component reference properties to Entities (EntityRef, EntitySet, EntityObject)
- When a referenced entity is destroyed, the property is updated to null.
- Subscribe-able events for adding and removing references.
- Reverse query from entity to entity-components that reference it.
Not all systems need to run every frame.
Export/import support for saving/restoring state with component-level serialization configuration.
100% Test Coverage.

I spent a lot of my hobby time in the last year, and especially quarantine, exploring prototypes to solving this problem to find the right implementation and features set.

There are a bunch of other ECS implementations out there for JavaScript, but most of them are fairly naive or merely instructive.

You could also use Mozilla's ECSY, which isn't a bad way to go. Some of the devs have pledged to keep working on it despite being layed-off.

Ape ECS 1.0

Today, I'm launching Ape ECS 1.0. The documentation (especially the API documentation) is comprehensive. It boasts 100% test coverage. I've run it through it's paces for usage and performance. Ape ECS is ready for you to use!

I'm super happy to get this released, especially given how difficult this year has been. I'm excited to finally talk about it more broadly and call it 1.0!

I look forward to hearing your questions, suggestions, and contributions. Open issues and pull requests on Github. Feel free to poke me on Twitter @fritzy or Discord (Fritzy#5972). Please make suggestions for the documentation as well!

Update 09/27: We had our first post-1.0 pull-request!

What's next for Ape ECS?

Software is never done! I will continue to work on Ape ECS.

The example game Missile Orders is not finished yet, nor does it properly show off the benefits of ECS yet.
I want to expand the benchmarks to cover queries, and use that as a basis for more optimizations.
I plan on adding Commands, expand Events, and implement rollbacks and fast-forwards in order to support lag-resistant and corrective network support.
The documentation needs corrections, more patterns, and examples.

If you want to work on these things, please reach out!

Special Thanks

Thanks to Ben Morse for early implementation feedback, documentation suggestions, and the TypeScript definitions!

Thanks to Jaime Robles for the banner image!