DEV Community: Keff

I've FINALLY launched my Product!!

Keff — Tue, 16 Dec 2025 15:05:47 +0000

Cardboard.js is now on Product Hunt

Hi everyone,

After years of working on Cardboard.js, I’ve finally launched it on Product Hunt. This project started as a way to build small, interactive web apps without writing HTML, JSX, or separate CSS files — you write everything in plain JavaScript or TypeScript and let Cardboard handle rendering and reactivity.

If you’ve followed my earlier posts about building this framework, thanks for sticking around. If not, here’s a quick intro and a few snippets to show what it feels like to use.

What Cardboard.js Is

Cardboard.js is a lightweight reactive UI library (~16 KB), focused on simplicity and performance. It provides:

No HTML required — you generate DOM elements with JS.
Built‑in state management.
Reactive updates (UI updates when state changes).
Reusable components and CSS‑in‑JS style support.

Quick Snippets

Basic Usage

Instead of writing HTML, you initialize the framework and define UI with JavaScript:

import { tag, init, allTags } from '@nkeff/cardboard-js';

const { div, p } = allTags;

// Initialize Cardboard (defaults to <body>)
const root = init();

// Append elements
root.append(
  div(
    p('Hello world!')
  )
);

This creates and attaches the DOM for you without a template file — everything lives in code.

A Simple Reactive Counter

Cardboard includes reactive state primitives so your UI updates automatically:

const Counter = () => {
  const count = state(0);

  return button()
    .text(`Clicked $count times`, { count })
    .addStyle('color', 'gray')
    .stylesIf(count.greaterThan(5), { color: 'red' }) 
    .clicked(() => count.value++);
};

// Mount it to the body
tag('(body)').append(Counter());

Here you define a component function that returns UI with reactive state. As count.value changes, the text and styles update automatically.

Why It Matters

If you’ve worked with frameworks where you juggle templates, build steps, and lots of boilerplate, Cardboard offers a simpler alternative where logic and UI live together in plain JavaScript or TypeScript. It’s small, fast, and doesn’t need HTML, CSS, or JSX if you don’t want them.

How You Can Help

If you think this could be useful — or even just interesting — I’d love your support on Product Hunt. A visit, upvote, or comment goes a long way and helps this project get more visibility.

producthunt.com

Thanks for reading — and if you try it out, I’d really like to hear what you build with it.

Might save you some headaches!

Keff — Tue, 16 Sep 2025 11:19:33 +0000

Keff

Sep 11 '25

Eskema: Composable, Ergonomic Runtime Data Validation for Dart Done Right!!

#showdev #programming #dart #flutter

Comments

4 min read

Eskema: Composable, Ergonomic Runtime Data Validation for Dart Done Right!!

Keff — Thu, 11 Sep 2025 11:53:38 +0000

Every Dart project has that one file — you know the one.

The file full of if (value == null || value is! String || value.isEmpty) checks.

The file that starts out as “quick validation” and slowly mutates into a plate of spaghetti code that nobody dares to touch. 🍝

I’ve been there. In fact, that’s what pushed me to build Eskema.

Most existing solutions I found leaned on code generation, which meant I ended up with opinionated, hard-to-read boilerplate and mysterious generated classes. I wanted something else: a library that was declarative, ergonomic, and unopinionated. Something that makes it obvious what is being validated and where it’s happening, without sprinkling spaghetti across my codebase.

Eskema started as a tiny functional library a few years ago, but it has since grown up: now it has a solid class-based core, operator sugar, and a builder API. It’s still extremely simple to extend; adding a new validator or transformer is basically trivial, but it’s powerful enough to cover most real-world validation needs.

Why Eskema?

Key features of Eskema include:

Composable API: Validators are just Dart functions that take a value and return a Result. You can nest and combine them freely (with all(), or(), or the overloaded &/| operators). This makes validation logic highly composable and easy to reason about.
Rich built-in validators: Out of the box, Eskema has checks for types, numbers, strings, lists, maps, etc. For example, isString(), isInt(), isEmail(), listEach(), listIsOfLength(), and many more. Presence checks (isNotNull(), isNotEmpty(), isPresent()) and comparison checks (isGt(), isLte(), isIn(), etc.) are included too.
Operator sugar: Combine validators with & (AND) and | (OR), and invert with not(). For example, instead of all([isString(), isNotEmpty()]), you can simply write $isString & isNotEmpty(). You can also override error messages inline with the > operator, e.g. hasLength(5) > 'must be 5 chars'.
Optional vs Nullable semantics: By default, a key must be present and non-null. Use nullable(validator) to allow a field to be null, or optional(validator) to allow it to be missing entirely. This helps avoid the common confusion between “no value” and “null value.”
Builder API: If you prefer a more fluent, type-safe style, Eskema offers a builder API. For example:

  final userValidator = $map().schema({
    'id': $string().trim().toIntStrict().gt(0),
    'email': $string().trim().toLowerCase().email(),
    'age': $string().toIntStrict().gte(18).optional(),
  });

No codegen – all runtime: Eskema validates plain Dart maps and values at runtime. No build steps, no generated classes.
Production-ready: Fully tested, documented, and with sensible error messages. Failures produce a structured list of expectations (message, field path, etc.), not just a bool.

Functional Validation Examples

Here’s a validator for a user object using the functional API:

final userSchema = eskema({
  'username': isString() & isNotEmpty(),
  'password': isString() & hasLength(8, 32),
  'email': isString() & isEmail(),
  'signupDate': optional(isDateTime()),
});

final result = userSchema.validate({
  'username': 'alice',
  'password': 'secret123',
  'email': 'alice@example.com',
  // signupDate omitted is OK (optional)
});

if (!result.isValid) {
  print(result.expectations);
}

Each field maps to a validator. We combined checks with & instead of writing all([...]), and used optional(isDateTime()) to allow signupDate to be missing. The Result object has .isValid and .expectations with detailed error info.

If you only need to validate a single value:

final isNonEmptyStr = isString() & isNotEmpty();
print(isNonEmptyStr.isValid('hello'));          // true
print(isNonEmptyStr.validate('').isValid);      // false

Writing custom validators is easy too:

Validator isEven = Validator((value) {
  return Result(
    isValid: value is int && value % 2 == 0,
    expected: 'even integer',
  );
});

Before vs After Eskema

Let’s be honest: we’ve all written validation code like this at some point:

// Before: classic if/else soup
bool validateUser(Map<String, dynamic> user) {
  if (user['username'] == null || user['username'] is! String || user['username'].isEmpty) {
    return false;
  }

  if (user['password'] == null || user['password'] is! String) {
    return false;
  }
  if ((user['password'] as String).length < 8 || (user['password'] as String).length > 32) {
    return false;
  }

  if (user['email'] == null || user['email'] is! String) {
    return false;
  }
  final email = user['email'] as String;
  final emailRegex = RegExp(r'^[^@]+@[^@]+\.[^@]+');
  if (!emailRegex.hasMatch(email)) {
    return false;
  }

  return true;
}

Not only is this verbose, but it’s brittle: hard to extend, hard to read, and easy to get wrong.

Now here’s the same logic expressed with Eskema:

// After: Eskema
final userSchema = eskema({
  'username': isString() & isNotEmpty(),
  'password': isString() & hasLength(8, 32),
  'email': isString() & isEmail(),
});

final result = userSchema.validate({
  'username': 'alice',
  'password': 'secret123',
  'email': 'alice@example.com',
});

print(result.isValid); // true

Clean, declarative, and composable. Instead of juggling if/else and regex checks, you just describe what you expect — and Eskema takes care of the rest.

Using the Builder

For those who like a fluent, IDE-friendly approach, Eskema’s builder API provides similar power with method chaining:

NOTE that everything is a validator, so you can combine and compose functional and builder validators.

final mapValidator = $map().schema({
  'id': $string().trim().toIntStrict().gt(0),
  'tags': $list().each($string()).lengthMin(1),
});

// Usage:
final res = mapValidator.validate({'id': '42', 'tags': ['dart', 'eskema']});
print(res.isValid); // true

This yields the same result as manual validators, but in a fluent syntax. The advantage lies in ergonomics: IDE autocompletion, type safety, and the elimination of the need to import numerous free functions.

Ergonomics and Tips

Use the $ shortcuts: Many zero-arg validators have a cached alias. For example, $isString is a pre-built isString(). Looks clean and avoids re-allocating functions. Use isString() if you want to specify a custom error message.
Operator overloading: Get comfortable with &, | and not(). They make schemas terser and more logical to read.
Clear error messages: Use > to override messages, e.g. hasLength(5) > Expectation(...).
No boilerplate: Works out of the box for Flutter forms, API handlers, config files – anywhere you need validation.
Async support: Need async checks? Just use .validateAsync(). Eskema will promote validators to async as needed.

Conclusion

Eskema takes the headache out of runtime validation by providing a simple and flexible toolkit. It’s small in scope but big in composability. You can validate nested JSON, lists, or individual values with clear syntax and rich error reporting – all without codegen or ceremony.

If your app deals with dynamic data, give Eskema a try. A few ergonomic validators might just save you from a world of edge-case bugs – and maybe even a little coding despair.

👉 Give it a spin: Eskema on GitHub. Your future self (and your teammates) will thank you.”

In case you're in the same situation I was in, take a read about my experience!

Keff — Wed, 02 Jul 2025 12:38:14 +0000

Keff

Jun 27 '25

Rediscovering My Passion: From Burnout Back to Excitement

#devjournal #developer #career #leadership

Comments 28

2 min read

Rediscovering My Passion: From Burnout Back to Excitement

Keff — Fri, 27 Jun 2025 13:18:03 +0000

Rediscovering My Passion: From Burnout Back to Excitement

I used to lose track of time coding—pulling late-night sessions just because it was fun. My side projects weren’t even for work; they were pure passion. But after eight years in my last job, I started dreading my IDE. What used to feel like play became a drag, and I’d find myself sighing every time I opened a file. Eventually I realized I had to leave. It took me a couple of years to build up the courage, but quitting turned out to be one of the best decisions I’ve ever made.

The Burnout Trap

It wasn’t one big meltdown—more like a slow leak. Mornings felt like a weight, and solving bugs stopped being exciting. Instead of tackling deadlines, I felt chained to them. I realized:

Working there drained me.
Constant context-switching killed my focus.
It seemed I carried the company, without being valued.

I missed enjoying coding just for the fun.

Hitting Pause (Kind Of)

I spent almost two years unemployed by choice. I didn’t code at all. Some days I loved it—rock climbing, nature photography, and new hobbies filled my time. Other days I hated not writing a single line of code. That push-and-pull helped me figure out what I really wanted.

Back to Reality

After two years, money became a reality check. I had to decide: go back to coding (safe) or switch industries (scary). I started applying and interviewing, but every process felt off—ghosting, weird vibes, nothing clicked. I worried I wasn’t valuable anymore.

A Breath of Fresh Air

Then one company reached out, and the process was different from day one:

Clear process—no radio silence.
Genuine conversations—they listened and answered my questions.
Human vibe—every interview felt respectful.

The technical challenge went great, and in the final round HR asked, “What do you like about the company, and what made you apply?” I was honest: I hadn’t dug into their values yet, but I loved the project’s challenges and the team energy. HR wasn’t thrilled and almost rejected me. Luckily, the team lead and technical lead pushed back, convinced HR I was the right fit, and I got the offer.

Back in the Groove

I started in April, and it’s been amazing. The work is challenging and fun, and my teammates actually care. Now I:

Enjoy the job again.
Feel valued.

And my hobby keyboard is back on my desk, and those coding sessions are back.

Takeaway

Burnout happens—it’s a signal to reset.
Culture matters—find teams that treat you like a person.
Take the leap—quitting was scary, but it led me here.

If you’re stuck in a draining role, remember: stepping away can help, and the right opportunity is out there to reignite your passion.

[Boost]

Keff — Tue, 10 Jun 2025 15:36:45 +0000

Keff

Jun 10 '25

📦 Cardboard.js: Building a Simpler, More Intuitive Framework

#development #devjournal #webdev

Comments 2

3 min read

📦 Cardboard.js: Building a Simpler, More Intuitive Framework

Keff — Tue, 10 Jun 2025 15:36:25 +0000

Hey there! Hope you're having an amazing week! 🚀

If you're new here, let me introduce you to Cardboard.js—a lightweight, reactive web framework that lets you build dynamic web apps with just JavaScript or TypeScript. No HTML templates, no unnecessary boilerplate—just clean, reactive code.

Curious? Check out the repository to dive right in!

This post is a devlog and changelog about the latest updates to Cardboard.js. It’s all about making the framework more intuitive, developer-friendly, and powerful. Let’s dive into what’s new and why it matters!

🚀 The Big Picture: Making Names Make Sense

One of the biggest challenges in any framework is naming things. Names should be intuitive, descriptive, and align with industry standards. In this update, I focused on renaming key concepts in Cardboard.js to make them easier to understand and use.

Here’s what’s changed:

🏗️ Mount Points: A Cleaner Way to Attach Elements

Previously, Cardboard used the term attach for managing where elements are added in the DOM. While functional, it wasn’t very intuitive. So, I’ve renamed it to mount points, a term that’s more familiar to developers.

What’s New:

attach → mountPoint
detach → restoreMountPoint
attached → getMountPoint
tag.attach → tag.mount

New Utilities:

resetMountPoints() → Resets to the first mount point.
clearMountPoints() → Clears all mount points.
withMountPoints(tag, cb) → Temporarily sets a mount point for scoped operations.

Before and After:

Here’s how the new API makes your code more readable and intuitive:

Before:

attach(div1);
p.attach('Child of div1');
attach(div2);
p.attach('Child of div2');
detach();
p.attach('Child of div1 again');
attached().append(p('child of div1'));

After:

mountPoint(div1);
p.mount('Child of div1');
mountPoint(div2);
p.mount('Child of div2');
restoreMountPoint();
p.mount('Child of div1 again');
getMountPoint().append(p('child of div1'));

🔄 Observables: A More Familiar Name

Previously called Consumables, these reactive objects hold values and notify listeners when the value changes. While the functionality was great, the name wasn’t. So, I’ve renamed them to Observables, a term that’s widely recognised in the developer community.

Why This Matters:

Using familiar terminology reduces the learning curve and makes the framework more approachable for new users.

🧠 Computed Observables: Smarter State Management

Cardboard now supports computed observables, which let you derive new reactive values from existing ones. For example:

const count = createObservable(10);
const isAbove18 = compute(count, (newVal) => newVal >= 18);

Previously, this was called intersect, but I’ve renamed it to compute to align with industry standards.

✨ Built-in Compute Helpers: Now Even Better

Cardboard offers a set of pre-built compute helpers like greaterThan and isEmpty. These were standalone functions, but now they’re available as methods directly on Observables for cleaner, more readable code.

Before:

const isAbove18 = greaterThan(age, 18);

After:

const isAbove18 = age.greaterThan(18);

🔄 Lifecycle Events: Standardized Names

Lifecycle events have been renamed to align with common conventions:

start → mounted
removed → unmounted
beforeRemove → beforeUnmounted

🎯 Why These Changes Matter

At first glance, these changes might seem small. But they make a huge difference in how intuitive and enjoyable Cardboard.js is to use. By adopting familiar terminology and simplifying APIs, I’m making it easier for developers to pick up the framework and start building amazing things.

🌟 What’s Next?

I’m aiming to release the first stable version of Cardboard.js before the end of the year! There’s still a lot to do, but I’m excited about the progress so far.

If you’re interested in contributing or just want to follow along, check out the GitHub repository. Every star, issue, or pull request helps!

❤️ Join the Community

If you find Cardboard.js interesting, I’d love your feedback! Whether it’s trying out the framework, reporting bugs, or suggesting features, your input is invaluable.

👉 Visit the GitHub Repository

Let’s build something amazing together!

📦 Cardboard devlog, what I've done in the last update

Keff — Mon, 17 Mar 2025 10:05:27 +0000

Hey there! Hope you're having a great week!

I'm building Cardboard, a straightforward, yet powerful reactive web framework. You can look at the repo, or the other articles in the series if you don't know what Cardboard is about!

This post is a devlog/changelog about what's happened with Cardboard in the last update. What's been added, changed, and improved.

Changes

State

I've re-written the state to use Consumables. I decided to do this as the previous implementation of the state was unstable, hacky and not very intuitive to be honest.

Consumables are custom objects that hold a value, can be listened for changes, and can dispatch new values.

Another inconvenience was that you could only create object/array states, not primitive values. With the new implementation, you can have both.

By using Consumables the new state is simplified. It's also a lot more stable and intuitive.

Before:

let st = state({ count: 0 });
st.count++;

Now:

let count = state(0);
count.value++;

Now we must modify the value of the consumable.

There are many more changes, but not worth mentioning as they're not that interesting :P

Additions

States can now be children

To be able to create reactive text before, you had to use the text function or tag.text method. While that did the job, it was a pain if you just wanted to add the Consumable value without interpolating. Let's look at an example to better understand what I mean:

Before:

const hours = state(0);
const minutes = state(0);

div(text('$hours', { hours }), ':', text('$minutes', { minutes }));

Now:

const hours = state(0);
const minutes = state(0);

div(hours, ':', minutes);

Consumable Intersecting

When using Consumables, you might want to check if it has a value, if it's empty, if it's a certain value, etc...

For this, Consumables can be intercepted, which means that you can create a new Consumable that updates its value based on another Consumable.

Look at this example:

const temperature = createConsumable(32);
const isTooHot = greaterThanOr(temperature, 30);

div().showIf(isTooHot);

As you can see this can be very powerful. isTooHot will be true if the temperature is higher or equal to 30, and false if less.

The div will be shown or hidden based on the value of isTooHot.

Let's look at another example:

const TodoItem = (todo: IConsumable<TodoItem>) => {
  const isComplete = grab(todo, 'complete', false);
  const todoText = grab(todo, 'text', 'Empty Todo');

  return div(
    input().setAttrs({ type: 'checkbox' })
      .changed((self) => {
        todo.value.complete = self.checked;
      }),
    h4(todoText)
      .stylesIf(isComplete, { textDecoration: 'line-through' }),
  );
}

grab will set its value to a specified value from the original consumable. Whenever todo changes, the values of isComplete and todoText will also update.

If the input checkbox is changed, it will set the complete property. When this happens the h4 will react and set the styles accordingly.

I'm interested in knowing what you think about this. Do you think the approach I've taken is good? Or would you suggest going another route?

`each`

The biggest change has been the addition of the each function. This has taken most of my time and has made me rethink how some aspects of the project work. Most other changes have been made to make each work properly.

each renders lists that update whenever the state changes. The interesting and hard thing is that it's smart and will only update the things that need to be updated. If a value is added, only that value is added to the dom. If a value changes places, only that operation is done.

This was a bit of a challenge, not only creating the actions to be performed but also handling memory.

This is how it works:

const colors = state(['red', 'orange', 'yellow', 'green', 'blue', 'indigo', 'violet']);
const selectedColor = state('red');

div(
    each(colors, (color) => 
        button(color)
          .addStyle('color', color)
          .stylesIf(equalTo(selectedColor, color), { fontWeight: 'bold' });
    )
);

If a colour is added, removed, or changed places, each will react and update the list accordingly.

If you want me to write a more detailed and technical article about how each works, let me know in the comments and I will get to it. It's pretty interesting!

Improvements

After working on all of the changes mentioned above, and adding more tests a lot of bugs have been squashed, naming has improved, and the overall stability of the project has increased.

Additionally, I've spent a lot of time improving the wiki and docs, as well as the README. I think having a decent Wiki and documentation is key from the get-go.

Summary

It's been a productive couple of weeks. I don't think I've ever spent this amount of time working on a single project (outside of work). But I like how Cardboard is turning out! I think that with a bit more work it can be very powerful and competent.

I'm aiming to have the first stable version finished before the end of the year!

If you find the project interesting please consider helping out!

nombrekeff / cardboard-js

A very simple, yet powerful reactive framework, to create web applications. All of this with, no HTML, CSS, JSX, and no required build.

📦 Carboard.js

Welcome to Cardboard. An extremely light (around 18kb), performant, and very simple reactive framework. It offers almost everything you'd expect from a complete framework. Like managing state, components, logic, and the rest. But with a twist, you don't need to write any HTML, CSS, or JSX if you don't want to. See what it can do.

It's similar in philosophy to VanJS, if that rings a bell, but with many more features, and a more extensive API.

!NOTE!: Cardboard is in development, use it with caution.
You can check the v1.0.0 milestone for a view on the development state - help is much appreciated!

const Counter = () => {
  const count = state(0);
  return button()
    .text(`Clicked $count times`, { count })
    .addStyle('color', 'gray')
    .

…

View on GitHub

Is tech boring lately or is it me?? 😐

Keff — Mon, 18 Dec 2023 13:19:39 +0000

I'm finding tech very boring lately. Nothing seems that exciting or innovative. Just the same stuff with different flavours or efficiency levels.

So, is this a me thing or do you feel the same way?

And if you don't, what excites you?

Should listicles be forced to have a tag so we can hide them from feed?

Keff — Sat, 09 Dec 2023 13:12:36 +0000

I know, I know, many people have talked about, and hated on listicles here on DEV many times.

But to be completely honest, they're some of the most annoying and un-creative articles you can come across. Most of them are useless or offer very little value apart from a collection of X or Y things, or are just cheap marketing. And you can't escape them it seems... They're also bad for beginners, making them feel like they MUST read them in order to progress as developers. And that's not good.

Listicles are one of the reasons I left DEV for half a year or so. And after coming back it seems it's even worse than before. Maybe the rise of AI is making it even easier to create them.

I really like this platform. I've been an active member of DEV for many years, have posted numerous articles and have consumed many more. I've read some of the best articles here, and engaged in some of the most interesting discussions and conversations.

And i know I'm not the only one that dislikes listicles, or even stopped using DEV because of them. This makes me sad, because great articles get lost between all the listicles.

But I think it could be fixed quite simply.

I want to bring up a possible solution to the table, which might've been already suggested, but in case it hasn't, here it is.

The idea is not to prevent creating listicles, but a way for people who dislike them to hide them from their feed. People who want to see them, can. People who want to create them, can. And people who don't want to see them, can.

The idea is to "force" listicles to have a tag listicle or something like that. So that we can hide it from the feed like we hide any other tag.

Forcing it could be done by the guidelines and mods I guess...

Or maybe it can be algorithmically done in code or using AI 🤷

Just a little idea!

How could AI influence our evolution? 🧠🤖

Keff — Tue, 21 Nov 2023 21:32:08 +0000

I've always been fascinated by evolution, human evolution in particular. But more precisely, how the things we do and the behaviours we have today could affect our evolution.

In the last few days, I've been thinking about AI (how strange...). Not only AI but how AI could affect our evolution.

Seeing as AI is taking over at a rapid pace, and we use it more and more, even for trivial things. We might get to a point where AI can do so many things for us, that we'll stop needing to do them as often, or at all.

This popped a question in my head. What are some things AI could do, that would lead to humans losing some part of their behaviours/intelligence/abilities/... as a part of evolution?

All of this, of course, at a time when AI is truly useful, integrated and can completely remove the need to do certain things.

Maybe we become dumber, as there's not much need to think as hard anymore, why would you, if you can just ask good old AI!

Or let's say that we get to a point, where some tyrannical leadership rules the world and forces all newborns to have AI implanted into their brains...

By having the AI integrated from birth, humans might lose the need for the ability to reason, as AI will do it for them. Or maybe AI is so good at remembering images, sound, texts, etc... that we don't need to learn to do those things, and over time, humans might become incapable of doing them without the implanted chip.

Possibilities are endless really, so what do you think?

[Challenge]: Nobody's solved this yet, can you?

Keff — Fri, 17 Nov 2023 17:08:17 +0000

Last week I posted a little cryptic challenge. It's been exactly a week and nobody has solved it yet. Maybe you can!!

If you haven't checked it yet, go give it a try!

[Challenge]: Cryptic riddle, can you solve it? 🧐

Keff ・ Nov 10

#watercooler #challenge #puzzle #fun

If you checked it but couldn't figure it out, I will share a clue in the comments of this post, hopefully that helps a bit :)