I love how Zig and Rust are fast and flexible. The control, the performance, the fact that what you ship is a real native binary. No runtime hiding behind it, no engine deciding things for you at 2am in production.

But every time I sat down to actually build something, I felt the tax.

More ceremony. More time fighting the compiler over things that had nothing to do with the problem I was solving. And a smaller pool of people who could read my code back to me.

Then I looked at the other side.

TypeScript's syntax is something most of the industry already speaks fluently. Interfaces, generics, async/await, arrow functions. Expressive without being exotic. Nobody needs a course to read it.

And that's when it clicked: the syntax was never the hard part of Rust or Zig. The runtime was.

TypeScript's problem was never how it looked. It was everything underneath it: a JS engine, a garbage collector, dynamic prototypes, and an npm install that pulls in a universe of transitive dependencies you never asked for.

So I started asking a different question.

This isn't the first time I've written a lexer, an AST, a type checker, a compiler. I've built that pipeline before. I know what it costs and I know what it takes. So this wasn't a leap into the unknown. It was pointing something I already knew how to build at a problem I'd actually felt.

What if you kept the syntax everyone already knows, and swapped out everything underneath it for something with Zig's discipline?

That's Lumen.

What it actually is

Lumen type-checks familiar TypeScript syntax, emits Zig, and compiles that straight to a small, dependency-free native binary. No VM. No garbage collector. No runtime.

You write this:

And you get a native executable. Not a bundle. Not a container with Node inside it. A binary.

Zig is the backend. Your TypeScript is type-checked, emitted as Zig, and compiled to a native binary from there.

The syntax you already know is all there: records and interfaces, generics, classes with extends and #private fields, template literals, try/catch/finally, async/await, map/filter/reduce. But it's a deliberate, static subset. No prototypes. No eval. No dynamic shapes that make the compiler guess.

The decisions that make it different

Generics are monomorphized. Write once over a type parameter, and each instantiation compiles to specialized code. No boxing, no runtime type juggling.

Closures compile. Capture your locals, and they get lowered to a heap environment, with no garbage collector waiting behind them.

Concurrency is real. Worker.run(fn) spawns an actual detached OS thread and hands you back a Promise. Genuine CPU parallelism, not a simulated one, because there's no per-thread interpreter overhead to pay in the first place.

It talks to C directly. Write a declare function, link a C library, and call it. No bindings generator, no FFI ceremony. Strings and scalars marshal across the boundary for you.

And because there's no interpreter in the middle, some of this ends up faster than the runtime it borrows its syntax from. Anchored regex patterns compile to specialized native matchers at build time, around 3× faster than V8 on checks like semver and identifiers. A typed EventEmitter runs about 3.5× faster than Node's on a tight emit loop.

The standard library lives in the open, in std-contrib. Take the markdown package. Rendering a typical 3 KB document in a tight loop, it does about 6,775 renders/sec, against 2,020 for markdown-it and 1,064 for marked. That's roughly 3.4× faster than markdown-it and 6.4× faster than marked on the same document. Same reason every time: it compiles the parser instead of interpreting one.

Standard library: github.com/lumen-lang-org/std-contrib

A package is just a URL

There's no package manager. No install step. No node_modules.

A simple module is just an import over HTTPS:

Lumen import with url

The .ts is fetched over HTTPS and inlined at compile time. A remote module can pull in its own siblings by relative path, fetched recursively, each URL fetched once per build. Only https:// is allowed, and remote code runs at build time. So you import from sources you trust, and you know exactly what went into your binary.

And it's not just source modules. You can pull in a C library the same way. The quickjs package embeds a full QuickJS sandbox through Lumen's FFI:

A C engine, embedded and running, imported from a URL. No build script, no bindings step, no package manager. That's the whole point.

What I'm deliberately not doing

I'm building out the standard library piece by piece: crypto, filesystem, networking, worker threads, all backed by real OS primitives, not polyfills.

But I'm being deliberate about what not to bring over from Node.js. I'm not chasing 100% API parity for its own sake.

Parity was never the goal. Discipline was.

std - lumen

The same source, native or in the browser

Lumen compiles to a native binary, or to WebAssembly, from the same source. The standard library is honest about the line between them: every function is marked for its target, so you know up front what runs everywhere and what's native-only. Pure computation, crypto, string and URL work, the event emitter, runs identically on both. The things that can't cross, raw syscalls, threads, direct filesystem access, are labeled, not silently broken.

This is also why the playground works the way it does. When you compile to WASM, a C dependency like the QuickJS engine gets linked straight into the compiled module. The whole program becomes one self-contained wasm file. So the QuickJS example above, a full JavaScript sandbox embedded through the FFI, runs in your browser with nothing installed. You're not looking at a simulation of the language. You're running the real compiler output.

The full standard library surface is at lumen-lang.org/stdlib.

The bet

The core bet is simple: remove the runtime tax without asking anyone to learn a new mental model.

You already know the syntax. You shouldn't have to trade it away to ship a real binary.

There's a playground. Write Lumen and watch it compile in the browser, no install:

https://lumen-lang.org/play

It's still early, and it's open. If that's a problem you've felt too, come look at the rest:

I'd love to hear what you think.

Code used to be the only thing we wrote, the only thing we reviewed, the only thing we shipped. Process and ceremony existed because code was expensive to produce and hard to change. That cost has dropped. A description of what we want can now generate working code in seconds, and we can iterate on the description faster than we used to iterate on the code itself.

So the loop has two artifacts now. The description, and the code generated from it. Both have to be right. Neither one replaces the other.

Which forces two questions to the surface. Is what the agent produced actually a reply to what we asked? And is the input we gave it clean enough to be worth replying to?

The first question I will cover in another article. This one is about the second. The spec.

Spec-driven is not vibe coding

The opposite of spec-driven is not test-driven. It is vibe coding. Describe the goal, get a block of code back, hope it is what you meant. Fast, fun, and unreliable the moment the system has more than one moving part.

Spec-driven changes the order. You write the description first. The agent generates code from it. You review the code, you test it, you ship it. Both artifacts are real, both have to be right. The spec is what you start from. The code is what runs.

What changes is the relationship between them. The spec is the source the code is generated from, and the place fixes start. The code is still the thing that runs in production, and it still earns the same review and the same tests as anything you wrote by hand. Neither one carries the system alone.

The canonical workflow

Two tools have made spec-driven a real workflow rather than a philosophy.

Spec Kit, from GitHub, formalized the approach. It splits the description into four artifacts: a constitution for non-negotiable principles the agent must respect across every feature, a spec for the what, a plan for the how, and a tasks breakdown for execution. The flow runs /constitution → /specify → /plan → /tasks → /implement, with clear phase gates. Thorough, opinionated, greenfield-friendly. The cost is weight. A Spec Kit change can generate eight hundred lines of markdown before any code is written.

OpenSpec, from Fission AI, is the lighter cousin. TypeScript instead of Python, npm install instead of toolchain setup, no rigid phase gates. Its distinctive idea is the delta spec. Instead of rewriting the whole description on every change, you describe what is being added, modified, or removed, and the deltas merge into the main specs after the change ships. Specs live alongside the code in the repository, which makes it brownfield-friendly in a way Spec Kit is not. Same change, around two hundred and fifty lines.

The two tools are not competing philosophies. They are different points on the same curve. Spec Kit treats specification as a first-class engineering phase with its own ceremony. OpenSpec treats it as a lightweight layer that sits next to the code and evolves with it. Same source-of-truth idea, different appetite for process.

Both are designed for the same shape of problem: one project, one codebase, one target. The spec exists so the agent does not drift, so requirements survive past the chat session, so the team aligns before code is written. That is the canonical use case.

Where we pushed it further

The methodology has a principle inside it that is bigger than the tooling. The spec is the source of truth. The code is regenerated output. Fix the spec, not the code.

Once you internalize that principle, a question follows. If the code is regenerated output, why does there have to be only one of it?

We were writing a native mobile application. Android and iOS, sharing one project. For some features iOS owned its own behavior. Fine at first, the diff stayed small. Then it grew. Each platform needed its own visual identity, its own feel. The "shared project with platform branches" model started to bend.

The standard alternatives were the usual ones. Own three codebases and pay the synchronization cost forever. Or pick a cross-platform framework (Flutter, React Native, Kotlin Multiplatform) and accept the shared runtime, the shared idioms, the not-quite-native feel.

We tried a third path. One description. Multiple targets. Same source of truth, regenerated as native code for each platform. The agent writes idiomatic code for each one because it is generating, not transpiling. The spec never runs. There is no shared runtime. The cost is a regeneration step instead of a compile step, and the discipline of keeping the description honest across all three.

This is not what Spec Kit or OpenSpec ship out of the box. Neither tool advertises multi-target generation as a feature. We took the principle they encode (intent as source, code as output) and pushed it past the canonical workflow. The tools gave us the discipline. The discipline gave us the architecture.

We applied it to Android, iOS, and eventually web. Same description, three outputs. The agent is the compiler. That arrangement was not realistic three years ago. It is now.

Where we landed on the artifacts

We did not start with Spec Kit or OpenSpec. We started with one file and let it grow. As the project grew, the file split itself almost naturally. Principles drifted into their own document, the architectural how drifted into another, feature behavior stayed in the middle, change-by-change deltas appeared on their own. By the time we read the docs of both tools, we recognized most of what was already on disk. The shape is convergent because the pressures are real.

The rest of this article uses "spec" loosely. It means the full description, across whatever files it ended up in.

What goes in the spec

The first instinct is to put everything in. Resist it.

A spec is not documentation. Documentation describes what exists for a human reader. A spec describes what should exist for an agent that will build it. Different audience, different rules.

What goes in:

• Behavior. What the feature does, in plain language. Not what it looks like, not how it is implemented. What it does, when, in response to what.

• Abstractions and data shapes. The objects the feature works with, the contracts between them, the invariants the agent must respect. This is the part the agent leans on hardest.

• Algorithm snippets. Small, high-density pieces of logic the agent should not reinvent. Sorting rules, eligibility checks, pricing formulas. If it has subtle correctness requirements, it belongs in the spec.

• Platform-divergent behavior. When iOS and Android genuinely diverge in what the feature does, name it once and explain why. Not a list of differences. A rule the agent can apply.

What stays out:

• UI pixels. Spacing, colors, exact paddings. That belongs in a design system the agent reads separately. Mixing them turns every spec change into a visual review.

• Prose explanation of why decisions were made. Useful for humans, noise for agents. Keep it in a sibling doc if you need it.

• Platform-idiomatic UI and gestures. Navigation patterns, gesture handling, animation curves, lifecycle quirks. These live in per-platform layers the agent reads alongside the spec. The spec owns behavior and contracts. The platform layer owns feel.

The test I use: would removing this line make the agent's output worse? If yes, keep it. If no, it does not belong.

What broke first

Drift between platforms. A prompt-driven change to one platform's code does not automatically update the spec, and does not automatically propagate. You patch iOS, the spec is now a lie, Android falls behind, the next web regeneration is wrong. The rule we landed on: a change starts in the spec, the spec updates first, then the agent regenerates each platform from the new source. The regenerated code goes through the same review and tests as anything else.

That sounds obvious until you watch yourself break it. The agent will happily edit the generated code in place if you ask. Sometimes that is the right move for a one-off fix. But if the change has any chance of being relevant to the other platforms, it has to start at the spec, or the divergence is back. Discipline has to be wired into the prompt and the workflow. It is not the default.

Context window pressure. As the spec grew, the agent started going back and forth before committing to a solution. Propose, second-guess, re-read, propose again. Useful in small doses, expensive when the spec is large and most of it is irrelevant to the task at hand.

We started scoping which parts of the spec load for which task. Keep the relevant section dense, keep the rest out of the way. Code generation went back to working like before. Sometimes better, because the agent was not drowning in spec it did not need.

What actually changes

You now have two artifacts to keep right instead of one. The spec, and the code generated from it.

Reviews split along that line. You review the spec for intent. Does it describe the system you want, in a way an agent can build from. You review the generated code for correctness. Does it do what the spec says, does it run, does it pass the tests. Both reviews matter. Skipping the code review because the spec is good is how regressions ship. Skipping the spec review because the code looks fine is how the next regeneration silently breaks something.

You stop owning three implementations of the same feature and start owning one description of it. You stop arguing about which platform got it right and start arguing about what right means, once, in the spec. The code still has to be read. It just gets read against the spec instead of against itself.

When something is wrong, you check both. If the spec is wrong, you fix it there and regenerate. If the spec is right and the code drifted, you regenerate. If the spec is right and the code is right but the behavior is wrong, the spec was incomplete. Fix the spec, regenerate. The fix almost always lands in the spec, but the code is what tells you it landed.

If you are running a spec-driven loop and have hit different walls than these, I want to hear about it.

To ship production, that's not enough.

Vendors will sell you anything. They'll tell you they put agents in their pipeline and ship production code. Not true yet. I'm working across multiple projects, from products and tooling used inside big tech companies to startup R&D. I invest heavily in coding agents and live coding. Here's what I've learned so far.

Code is cheap. That doesn't mean you should buy it.

A beautifully generated piece of code is compelling. Watching it build, run, ship on the first try feels great.

Then ask yourself: from that moment, what's the drift from version one? 50%? 60%? I'd say 80%.

Why? Because the first version is never mature. And now you're in the rewrite loop.

Even with a clean instruction.md or claude.md, you still get code duplication. You still get drift. You still get the "yes, you're right…" message. And you start losing track of what state your code is actually in.

Say you land on a good version. You wrote unit tests. You feel solid. Then you read through the full thing and decide it could be more maintainable. Even if you asked for maintainable code from the start. Another rewrite. Update the tests. Run QA again.

You're in a cycle. You're not shipping.

The code is cheap. The rewrite is cheap too. Nothing feels stable anymore.

What you gain, what you lose

You do learn. New patterns. New ways of doing things. That's real.

But that's not the point. The point is to ship a working, maintainable application.

I lived this on one of my own projects. The agent generated a working module on the first pass. I ran it. It built. It passed tests. Then I read it and saw three places where the same logic was reimplemented with different names. I asked for a refactor. The refactor introduced a new pattern that conflicted with how the rest of the codebase handled errors. Another pass. By the time the module looked clean, the test suite needed a rewrite to match the new shape.

Net progress: zero features shipped. Net learning: a lot. Net feeling: busy.

Right now everyone feels busy and building. A small portion is shipping real production. Incremental shipping has never been easier, and yet the loop is so compelling it pulls you away from shipping.

When the loop works

It would be dishonest to stop here. The loop does work. I've seen it.

On my own agentic coding pipeline, I built two workflows that handle GitHub issues end to end. One for immediate bug fixes. One for plan-first feature work. Both run with quality gates, Docker testing, and notifications back to me. The agent does the heavy lifting. I review and merge.

The reason it works isn't the agent. It's the surrounding infrastructure. The pipeline has clear contracts. The quality gates are non-negotiable. The agent operates inside a frame I designed before I let it touch anything.

Same story with LumenJS, the framework I open-sourced this year. Web components on web standards, file-based routing, server boundaries the framework physically enforces. Half the reasons I built it that way exist because an agent is the primary developer. Less room to go wrong. The framework is the structured surface. The agent is the worker. The structure came first.

That's the pattern. The agent isn't the system. The agent works inside one.

So how do you survive

You stick with a stack you actually know. The moment you let the agent pick everything, you lose ownership. You also lose the ability to debug it when it breaks.

You resist the buzz from the magic generation. That feeling is a fake sense of accomplishment. Too good to be true. 99% of the time, the real work is still ahead of you. The build passing is not the finish line. It's barely the start.

You invest in infrastructure more than before. Start with a solid layer: architecture, must-use and must-not-use patterns, data flow, component responsibilities, testing infrastructure, CI. Everything from day one. That's what lets you plug in a coding agent and actually get value out of it. Small, validated, incremental steps. You leverage the agent and you keep ownership and control.

This is the part most teams skip. They want the agent first and the structure later. It doesn't work in that order. The structure is what makes the agent useful.

You still need to learn how to code, more than before. You still need to try patterns and learn their tradeoffs. You still need to master the agent's tools and make them work for you. The skill ceiling went up, not down. The agent makes the floor higher and the ceiling further away at the same time.

And you still own the agent's output. If you ship code you don't understand and it breaks, that's on you. Not the agent. Not the vendor. You.

What this means for engineering leaders

If you run a team and you're being pitched on agent-driven development as a productivity multiplier, ask one question: what's the infrastructure my team needs in place before the agent makes us faster?

If the answer is "none, just turn it on," walk away.

The teams getting real leverage from coding agents right now are not the teams with the most agents. They're the teams with the cleanest contracts, the strictest quality gates, and the engineers who still read every diff before it merges.

Code is cheap. Judgment is not. Infrastructure is not. Ownership is not.

We faced these exact problems. Here's how we overcame them using coding agents.

Humans are mission-driven. So are our agents.

At work, at home, in life we each operate around a set of missions. We applied the same model to our agents. We built an agentic team around our tools and gave each agent a defined set of missions to carry out over time.

Our job as humans doesn't disappear it shifts. We create missions, specify timing and frequency, and let agents execute. Then we observe for drift, update missions that are complete, and retire ones that no longer fit the current state of the project.

Start small. Start safe.

We began by identifying mission types with low risk and clear scope: daily improvements, security checks, bug detection. The kind of work a single agent can handle with little chance of going off course.

The code flow: GitHub as source of truth

Here's the pipeline we use to develop and maintain both LumenJS and the Nuraly platform.

1. Issue creation A mission scans the codebase and creates a ticket for a specific task. If a similar ticket already exists, the agent skips it.

2. Implementation Another mission picks up the ticket, creates a branch, implements the fix or feature, opens a PR, and iterates until checks pass build, tests, and SonarQube pipelines. If something breaks, a separate agent takes over to fix it.

3. PR review On our SaaS, we maintain a next branch before anything goes live. A review agent inspects each PR: if the changes are small and obvious, it merges to next. Otherwise, it leaves a comment requesting improvements. The cycle stays open another agent picks up the PR, evaluates the feedback, and either pushes back (if the change isn't worth it) or implements what's requested. To avoid burning tokens, we cap the number of retry attempts.

4. Human validation Once the PR is green, a human steps in to validate what the agent has done before anything ships.

Missions are scoped by project.

Each project has its own set of missions. What we've found: small, incremental changes over time give us more control and visibility than large codebases nobody has the bandwidth to manage.

The human role doesn't disappear, it shifts.

This is the part people often misunderstand about agentic systems. Agents don't replace human judgment. They replace human execution of repetitive, well-defined tasks.

Here's how the responsibility actually divides:

• Humans define the mission its scope, timing, retry limits, and success criteria. Humans observe for drift and decide when a mission is stale or needs updating. Humans do the final validation before anything ships.

• Agents execute they create tickets, open branches, push code, iterate through fix loops, and auto-merge small obvious changes. They work continuously, within the boundaries they've been given.

The key insight: as long as missions stay small and well-scoped, agents stay predictable. The human overhead doesn't scale with the number of agents it scales with the number of missions you define, which is a much smaller number.

The shift is worth it.

We didn't need more developers or more sprints. We needed a different model small missions, running continuously, with humans staying in the loop at the right moments.

What surprised us most wasn't what the agents could do. It was the clarity the mission model forced on us. When you define work precisely enough for an agent to execute it, vague tickets stop being acceptable.

Small changes compound. Drift is the real risk. And the loop never fully closes without a human that's not a limitation, it's the point.

That distinction matters more than it sounds.

LumenJS is a full-stack web component framework and platform built with TypeScript. File-based routing, server loaders, SSR, authentication, real-time communication, database, storage - everything you need to build a production application, in one coherent system built on web standards.

We Didn't Guess. We Observed.

We paid close attention to how coding agents actually behave in practice - what they struggle with, where they drift, what structures they naturally produce correct output in.

That feedback is embedded in every design decision LumenJS makes. When a pattern caused agents to go wrong, we changed the framework. When agents reliably produced clean output in a certain structure, we made that structure the default.

We've Done This Before

Back in 2019 before LLMs, before any of this we built SustainJS. Same instinct: something about how web apps were being structured felt wrong, so we built what we thought was right.

Then the LLM era arrived. While building Nuraly, we went through framework after framework React, Astro, separate frontend and backend projects. Each one had the same problem: designed for humans writing deliberately, not agents generating at speed.

So we concluded, for the second time, that we had to build our own. Except this time, we had coding agents to help us build it.

Native Technologies. By Conviction.

We've said this before: we build on native and near-native technologies because they last.

We chose Lit Element as the renderer for NuralyUI. Now LumenJS takes web components to the next level a full-stack platform where routing, server data, and real-time subscriptions are all built around the same browser standard.

No deprecation dates. No migration guides waiting to be written. Just the platform.

pages/dashboard.ts auth, data, and real-time in one file

A Platform, Not Just a Framework

LumenJS ships with production-ready modules built in. Authentication with 2FA. A full communication stack with chat, conversations, and WebRTC calls. Not integrations to wire up. Not tutorials to follow. They are there, they work, you use them.

The difference between a framework and a platform is whether you spend the first week building infrastructure or building your product.

Proof of Concept? We Call It Production.

We are rewriting Nuraly on top of LumenJS. Not a demo. Not a side project. The full platform - calls, shared workflows, collaborative session building, live execution. Everything we needed it to handle, it handles.

When something breaks, we fix it. That is the only kind of reliability test that matters.

The Visual Editor

We started with a low-code studio. Low-code has a ceiling.

So we pivoted to an augmented code visual editor a visual layer on top of real code, not a replacement for it. LLM coding agents work alongside it, accelerating the writing while the editor makes output legible.

Same philosophy as LumenJS: don't hide the code. Structure it better.

Click any element on the page. A properties panel shows its attributes, styles, and matching CSS rules from the component source. Edit a value and it writes directly to the TypeScript source through the AST - not the DOM, the actual file.

The AI is part of the editor. Select an element, open the chat, describe what you want. It reads the source, applies the change, and you can roll back if it gets it wrong. Claude Code and OpenCode are both supported.

Nothing from the editor ships to production

Lumenjs editor mode

What Ships With It

• File-based routing, SSR, server loaders, API routes

• Real-time subscriptions over SSE and Socket.IO

• Authentication with OIDC, native email/password, and TOTP 2FA

• Full communication module: chat, conversations, WebRTC calls, end-to-end encryption

• Email with built-in templates and multiple provider support

• File storage with local and S3 adapters

• Database layer that works identically on SQLite and PostgreSQL

• Permissions, i18n, SEO, rate limiting middleware

This is not a list of planned features. It is what exists today.

The APIs are not stable yet. We are moving fast and things will change. We expect to reach v1 by Q4. Build on it with that in mind.

Conclusion

We are excited to launch LumenJS - not only because it represents how we practice augmented code, but because we have a team of coding agents as maintainers keeping the project alive, secure, and stable.

This is not a side project waiting for attention. It is a living framework, maintained the same way it was built.

https://lumenjs.dev

https://github.com/nuralyio/lumenjs

https://nuraly.io

The Demo Trap

Most agent projects start the same way. A simple UI. A simple API interface with an LLM. It works beautifully in the demo.

Then comes the real use case.

Suddenly, the team expects great results from the same setup they prototyped in a weekend. They start gluing UI to API, connecting endpoints, building wrappers, and wondering why the results are mediocre at best.

Here's the problem: there's not much value in that layer. The chatbot interface, the API wrapper, the prompt template: these are commodity components now. Everyone has them. They're table stakes, not differentiators.

Before you touch any of that, you need to deeply understand how to interface with the LLM, what components relate to it, and how they all connect with each other.

When you do that, when you truly understand the system, something shifts. You stop treating the LLM like a piece of code and start thinking about it as a system. You stop solving technical problems and start solving real ones.

Agents Are Simple in Tech, Brutal in Operations

The building blocks of an agent are simple. An LLM, tool calling, a feedback loop: the concepts are well-documented and the primitives are accessible.

But the system behavior is not. Tool calling is not reliable tool execution. A feedback loop is not correct state handling. Multi-step agents break in subtle, hard-to-reproduce ways. Here's the framing that makes it click for anyone who's run production infrastructure: agents are distributed systems with nondeterministic planners. If you've ever dealt with eventual consistency, partial failures, or observability gaps in microservices, multiply that by a component that makes different decisions every time you run it.

Building agents encompasses many technical and non-technical areas that most demos conveniently skip. Before your agent can do anything meaningful in production, you need to consider:

Access management. Who can the agent act on behalf of? What permissions does it inherit? If your client has a cloud environment, how do you connect to it securely?

Data governance. What data can the agent access? What can it store? What are the compliance requirements? This gets especially complex with European clients under GDPR.

Security. An agent that can take actions is an agent that can take wrong actions. An agent with cloud credentials that rotates a resource instead of tagging it can take down a staging environment. An agent with database access that misinterprets "clean up old records" can wipe production data. The attack surface is fundamentally different from a read-only chatbot, and the blast radius is real.

Monitoring. How do you know what your agent is doing? An agent that silently retries a failed API call 40 times before your alerting catches it is not a hypothetical; it's a Tuesday. How do you catch failures before your client does? How do you audit decisions the agent made autonomously?

Infrastructure. Local or remote providers? Self-hosted or cloud? How do you handle latency, failover, and scaling for long-running agent tasks?

User experience. How do you surface what the agent is doing in a way that builds trust rather than anxiety? How do you handle the cases where the agent needs to ask for clarification?

Integration. The agent doesn't live in a vacuum. It needs to connect to existing systems, APIs, databases, and workflows that were never designed for autonomous actors.

You need all of these pieces in place before you can design and distribute a working agent. Not after. Before. That's what makes this an operations problem, not a technology problem.

The Delegation Problem

Are the clients, are we as developers, actually ready for delegation?

We used to do everything ourselves. As developers, it's not easy to delegate code writing. We built our careers on it. We had fun doing it. We got deep satisfaction from shipping something we wrote with our own hands.

Then you start delegating to AI. And the results are mixed.

Sometimes the model isn't good enough for the task. Sometimes your prompting isn't precise enough. Sometimes both. And when you hit those walls, something interesting happens.

You start shifting your focus. From writing to planning. From coding to architecture. From execution to design.

You start a new kind of race: you think more and type less.

This is the real transformation that agents bring. Not replacing developers, but changing what it means to be one. The role evolves from writing code to orchestrating systems, from executing tasks to leading missions.

The Generation Trap

We now know that almost any piece of software can be generated relatively easily. AI can write code, scaffold applications, generate entire features from a description. This creates an enormous, and misleading, promise around delivery.

"If code can be generated in minutes, surely delivery is easy now."

It's not. And believing this is a trap.

Because it was never about writing code. It was always about understanding what the client actually means. Then executing on that understanding. Then iterating based on what you learn.

It's about infrastructure. It's about security. It's about integration. It's about all the things that code generation doesn't touch.

We absolutely need expertise. More than ever, in fact. But the expertise we need is not for executing tasks. It's for planning, reviewing, managing, and leading.

Not to type. To think.

Not to execute. To lead the mission.

Stop Chasing Frameworks

The market is crowded. Every week brings a new framework, a new wrapper, a new "agent builder" that promises to make everything easy.

None of them solve the actual problems.

Frameworks don't solve trust. Frameworks don't solve accountability. Frameworks don't solve blast radius. They solve wiring, and wiring was never the hard part.

The teams that will fail are the ones chasing the next wrapper, shipping demo-driven agents, and confusing "it works on my laptop" with production readiness. The teams that will fail are startups optimizing for speed of generation while ignoring speed of recovery.

The teams that will succeed, especially in the enterprise, are the ones treating agents like what they are: production systems that happen to include a nondeterministic component. They invest in governance, security, monitoring, and integration before they write a single line of agent code. They build operational maturity first.

The real value was never in the chatbot UI. It was never in the framework. It was in the ability to design, deploy, and operate a system that earns trust.

That's the mission. Lead it.

The Workflow

It starts with a GitHub ticket, created by a PM or QA. Claude Code with the Ralph Wiggum plugin activated spins up a fresh environment, initializes it with the latest codebase, and analyzes the ticket. It loads the relevant Claude Code skills and gets to work.

It creates a branch. It starts coding. When needed, it commits progressively and updates the checklist in GitHub to keep the status visible especially if other agents are working on related issues at the same time.

Once the work is ready, the agent creates a pull request and starts collaborating with other agents. GitHub Copilot steps in for a diff model review a second pair of AI eyes on the code.

At the end of each execution, a summarized version of the conversation is saved. So when work continues on the ticket through a PR comment or a follow-up task the agent picks up the compact context from the previous run. This way, we keep working on the ticket without losing context.

Quality Gates

This is where SonarQube enters. It analyzes the PR and flags the pipeline status. If it fails, Claude Code reads the issues and quality gate results, creates a separate branch to fix them, validates the fixes, then merges them back into the ticket branch.

If the pipeline passes, a Telegram message is sent to the collaborators who worked on the ticket this also doubles as a way to test our own workflow engine in a real scenario.

Why Telegram? Because we've made a deliberate choice about where our developers spend their time. The old model has engineers glued to screens, refreshing CI dashboards, waiting for pipelines, context-switching between Slack threads and terminal windows. We don't want that. We want our team talking to clients, understanding problems firsthand, sitting in the room where decisions are made. The agents handle the waiting. The notifications come to you not the other way around. Build the feedback loop around people, not around screens.

Then comes the human review. We still keep this step. We value the human eye.

After the Merge

Once the ticket is merged, Claude Code spins up a dedicated QA VM for that specific ticket launched from a pre-built image, which makes it extremely fast. After validation, the VM is carefully destroyed. Clean in, clean out.

We chose this over resetting environments because resets are fragile. You can miss something a stale config, a leftover dependency or add a feature and forget to update the reinit script. Starting from a fresh image for QA removes that risk entirely. It was one of our best decisions.

The deployment itself is triggered from the GitHub issue. When the issue is flagged as ready for test, an agent worker detects it, prepares the environment, and comments back on the issue with the VM details. Everything stays in the ticket no separate workflows, no context switching.

With this cycle, a QA engineer can test a ticket before the code review is even done — and continue working on it by adding comments directly on the issue. No need to wait on an engineer, no getting blocked. The feedback loop between QA and the agent stays continuous.

Why We Still Read Every Line

This is how we ship working code at Nuraly while keeping quality and ownership intact. Every agent code is reviewed. SonarQube's pipeline needs to be green. But after all, we still read the new and modified code line by line.

Not because we don't trust the tools but because the code is ours. Agents accelerate the work. The ownership stays with us.

What It Actually Is

OpenClaw is an LLM running in a loop with tools. A workflow that calls an LLM node, gives it access to your file system, browser, shell, and messaging apps, then loops until the task is done. It can also accept commands from long-running nodes like Telegram or WhatsApp, which makes it feel interactive and always-on.

That's it.

I'm not saying it's bad. The engineering is solid. But let's call it what it is: a well-packaged agent loop. An LLM node connected to tools, running over iterations, with persistent memory and messaging integrations. This pattern has existed for a while. Workflow engine, LLM nodes, tool access, long-running connections. The architecture is not new.

What Actually Matters

What actually matters right now and what OpenClaw confirms is everything around the LLM. The tools you give it. How you manage context. How you handle memory between sessions. How you set guardrails so the agent doesn't go rogue. That's where the real engineering challenge lives.

We already know this. The LLM is the brain. But the tools, the context management, the memory persistence — that's the body. And without a good body, the brain just hallucinates in the dark.

The Access Paradox

There's something worth sitting with here. The more data and control you hand to an AI agent, the more it can do for you. But that same access is exactly what lets it hurt you. It's the same lever, pulled in two directions. Give it your email, your calendar, your file system, your shell — and yes, it becomes powerful. But now the cost of a bad decision scales with the access you gave it.

Fragile and Expensive

Here's my honest concern with investing in this pattern right now: autonomous agents are still either fragile or expensive to run. One user mentioned hitting their entire Claude Max daily limit within hours just by letting the agent loop autonomously (before Anthropic blocked users from routing their subscription through third-party tools like this). Another had their agent accidentally start a fight with an insurance company. These aren't edge cases — they're the current state of autonomous AI.

The Real Blocker

And this is where it gets interesting. I think the real blocker for broad adoption isn't the models, isn't the tooling, isn't even the cost. It's security. Until we solve the agent security problem — how to give an AI meaningful access without exposing everything to a single bad reasoning step — autonomous agents will stay in the hands of early adopters willing to absorb the risk. Enterprises won't touch this. They can't afford an agent that emails a client the wrong thing, deletes the wrong file, or leaks sensitive data because it misunderstood a prompt.

Where This Leaves Us

In the absence of a genuine research breakthrough — something on the level of what we saw with Claude's leap in reasoning — we're essentially optimizing the loop. Making the tools better. Managing context smarter. But the fundamental limitation remains: the model reasons well enough for short, bounded tasks, and starts breaking down on anything truly complex or long-running.

Would I invest in building on OpenClaw right now? No. Not because it's bad, but because the value isn't in the loop itself. The value is in the platform layer underneath — the workflow engine that sets boundaries, the persistence layer that maintains state, the permission system that controls access. That's what enterprises actually need, and that's what doesn't come for free with an open-source agent loop.

Build the infrastructure. The agent patterns will keep evolving. But the foundation? That compounds.

Persistence management is one of those features that quietly sinks to the bottom of the backlog. We all want it. We all know we need it. But the priority stays low, pushed aside by urgent customer requests and deadlines. "One day, when we have time, we'll implement it properly." There's a good chance that day never comes.

So we decided to stop waiting.

The Solution: A Dedicated KV Service

At Nuraly, we built a separate service, a simple key-value store that serves our other microservices. It can hold encrypted values when needed, and it runs independently from everything else.

What can you store? More than you'd expect:

• API keys and secrets
• Database connection strings
• User-specific settings per service
• Feature flags and configuration overrides
• Agent state

That last one surprised us too. We now use the KV service to hold the state of our AI agents, their context, progress, and memory between sessions. What started as a configuration store became the backbone of our agent persistence.

All of this sits behind a dedicated permission service, so access stays controlled and auditable.

Why This Works

The beauty of a standalone KV service is isolation and simplicity. You don't need to manage persistence inside each microservice anymore. No more duplicating the same storage logic across services. No more spinning up separate databases just to hold configuration for each one.

Instead, the feature is one HTTP request away.

Each microservice pulls only what it needs, nothing more. No hardcoded values buried in deployment scripts. No redundant persistence layers bloating every service. Just a clean API call.

It's a small architectural decision, but it compounds. Onboarding new microservices becomes faster. Rotating credentials becomes trivial. Debugging configuration issues becomes possible. And every new service you spin up inherits the same persistence capability without implementing storage logic from scratch.

Where This Leads

I've started thinking of persistence not as a feature to implement later, but as infrastructure to build early. The cost of doing it right upfront is low. The cost of doing it wrong, or not at all, accumulates invisibly until it doesn't.

If you're building a platform, don't let persistence sink in your backlog. Build the KV layer now. Your future self will thank you.

At ReactConfg 2018 Event, Dan Abramov explained the Logo of React, he said that the user interface can be splitted into small independent units called components - similar to an Atom - and they will focus, in the next few years, on Hooks: “Electrons” as he named them.

On the other side of the Javascript world, Angular started focusing on smaller units as Component, Directive and Pipes rather than modules.

Starting from Angular 14, Components can be standalone and imported into modules or other components without the need for a dedicated module.

Standalone Component in Action.

To test this feature, I created a blank project and activated the routing option.

Then, I created a basic component UserDetailComponent , the metadata looks like the following.

Then, created a service for the User. For the sake of the demo, this service is not provided in the root providedIn: 'root'

So now, all we have to do is to use the service in the component. Before Angular 14, we had to create a module that defines all providers components and other dependencies or import everything in the AppModule.

Now, we can declare Components as standalone and provide the service directly into the Component

In the Route Module, we can directly import the component rather than the Module.

Github Srouce

You can play with the demo directly on Stackblitz

Motivation

Have you ever thought: why a framework like Angular started to review their vision about modularity?

In most Angular applications we are used to find some CoreModule, SharedModule and others that contain the common unit which is used in more than one module.

Everytime the application grows, there's a chance that these modules will grow too.

That's fine until we start thinking about performance.

In the chart below, we will demonstrate the use of a common NgModule and how to import a component directly inside another module without the middle man, Thanks to Angular 14 of course.

Sharing standard component

In this case we have three components, two services and more than two modules.

These units are used in more than one place, so we created a SharedModule to package them. This ShareModule has been imported in the two modules.

When lazyloading the module with LazLoading routes, the SharedModule alongs with the components and services and every unit exported, will be loaded in each module.

Sharing standalone component

In this case we have the same unit (components, pipes, services and modules) but we ditched the SharedModule.

We transformed the component in Standalone mode, which means that every component will load the needed providers.

The FormatDatePipe load the DateTimeService and DocumentViwerComponent load DocumentService.

Now When lazyloading a Component, only the component that is directly linked to it will be loaded.

Conclusion

Angular started approaching ReactJS with the small independent unit approach by introducing Standalone Component, which seems a big step toward enhancing web application performance and building a better and more maintainable web.

Personally, I'm not fan of the idea of working with only one Framework, since we can explore multiple paths at the same time then adopt what was a success in each Framework.

As Front-end Architect, choosing the right Framework can impact the whole company even the group, that’s why we choose carefully the technologies that we adopt.

For many years Angular prove how stable, it is, and when braking change happens, it will be accompanied by a great documentation.

Even there a tool to assist you when updating project. ng update

Angular CLI auto completion

Bootstraping Component, Pipe and Service is a daily task when starting a new feature with Angular projet. So we use ng command to generate our static files.

If you use VS Code or Intellij or any IDE there's extentions that execute ng generate command for you. But if you want use the command line in your Terminal you will have hard time to remember the arguments to pass.

That's why Angular has introduce CLI auto completion

To use this feature on Winsows you need to activate WSL(Windows Subsystem for Linux) or Use GIT Bash.

Double check if the command has added the command to the .bashrc

And than we can use TAB key to autocomplete, it's a bit slow on windows but it works.

We can go even further with the list of available flags.

Conclusion

Tools make the life of developers easier, every improvement can affect their productivity. This makes us sometimes choose a framework among others in order to get a richer toolkit.

In our case, we need to find out if there's a special character in the string to convert them,  and this was made by checking the decimal code of each character and check if it is above 127 or not,

why 127?

Because the ASCII table told us that the characters code starts from 0 (NULL) and ends at 127(DEL)

So we made this function.

bool isASCII(const std::string& s) { return !std::any_of(s.begin(), s.end(), [](char c) { return static_cast(c) > 127; }); }

And this how we used it

#include #include #include

bool isASCII(const std::string& s) { return !std::any_of(s.begin(), s.end(), [](char c) { return static_cast(c) > 127; }); }

int main(){ std::string testString = "not a valid Ãscii"; std::cout << "Is valid ASCII " << isASCII(testString.c_str()) << std::endl; }

And the output will be:

Is valid ASCII 0

0 as NULL is C++

PS: Will share snippets as I'm learning C++

Being a web developer using JavaScript frameworks consumes a lot of energy.

The JavaScript meant to be for the front-end development and to add some interaction to static pages, like display images on click, validate forms and load async portion of data.

Look around you now, JavaScript is everywhere. every month or a week there a new framework or library that want to change the world appears.

Let's look at some history:

At first, there's plain JavaScript, at that age, you need to write more for less, then it comes the libraries like jQuery, MooTools, and YUI( Yahoo! UI Library )

Then Angular.js has appeared at 2009, followed by Knockout, Backbone.js, Ember.js, and others.

After a while React has been introduced by Facebook at 2013, a component-based frontend framework

Then in 2016, it comes Angular 2+ a complete Javascript framework for the front-end.

But Ryan Dahl let the front-end developer be a full-stack developer by making Node.js

After 2009 developers start making web application and services with Javascript and new JavaScript frameworks start popups.

Starting from 2017-2018 people start choosing a path to follow, like Angular developer, React Developer and so on.

Also me, I'm known as Angular developer,  That's the main framework that I work with but you need also to master other Frameworks if you want to be laways fresh.

Following everything is the perfect option to lose focus. for me, I'm really aware of what I should consume to prevent the distraction, and also I create a routine to keep up with what should I know.

Again have you felt the JavaScript fatigue before? Share your experience with us ?.

When everything goes right, everybody is happy, but when one thing goes wrong, not nesserely everybody should feel sad.

To keep the good relationship we need to remove all the confusing things from the workflow and everybody should speak the same language.

Let's pick a case that everybody will pass on :

You create a view with Angular, Vue or React, you consumed mock services and everything looks OK,

Then it comes the moment of truth when you will connect the frontend view with the backend service/API, you implemented it and it didn't work you will contact the backend developer and he will tell you that his service work like a charm.

You invite him to look at the result and he admitted that there's a bug need to fix.

After he fixes his code, two things can happen :

The bug fixed and everything goes right.

The bug persists and you show him the scenario again and we loop through this until we get everything OK, if we did not break other parts of the App.

That's Ok but, this takes time and energy.

Here's I start a searching for automation, then to end to end testing, to simulate everything, and here's my experience :

I found Cypress and start writing my tests for my views and after each view or service implementation, then the worrying start decreasing.

With the (e2e) end to end testing, you stop worrying about regression and focusing on the new functionalities that need to implement.

With that, the relation between the front and back Team start recovering.

If the test fails I made a video of the issue and send it the concerned person, otherwise I invite him to watch the scenario fails ?

I start being less exhausted as a Front-end developer.

Next step, is to add the e2e test, to the DevOps pipeline.

And you, how are you dealing with the regressions?

First of all, I'm a consultant and I have a startup which means I work on lots of things with a lot of things.

And to keep it up without loses I need to isolate each thing from the other things. and here's where I start using Docker.

I hear people talking about Docker on the DevOps field but this is not the case for me, I start using Docker in the development environment, and here's how.

In the last mission, I was working on a frontend application using the Angular framework, and it's not just me, we were a team working on the same project trying the make things happen, really fast.

But this is not the case when we have a different version of Node.js and @angular/cli.

This start occurring when building success in some machine and fail in other, and here we start using Docker in the development environment, we choose a Node.js version that matches with the production server and we create an image for the environment, then we all start using the same image.

Besides all of that, any new member can use the same image without installing any of other tools than Docker, and it makes the integration of new members easy and smooth.

Then I start controlling the CPU and the Memory of the container to keep the host machine cool and prevent battery drain when I'm walking around with my MacBook Pro

That does not end here.

I start exploring new applications that were hard to install especially when I was using Windows, but with Docker, I just need to pull an image and run it.

I use Docker, how about you?

We all agreed that hybrid apps do not cost much, but when it comes to performance you need to be careful.

PhoneGap open's the door for JavaScript and HTML/CSS to enter the mobile world, then Apache Cordova (which is a fork from PhoneGap) Then it's comes the famous Ionic which is Angular Framework build for Cordova platform.

But the performance was not quite good, and sometimes not acceptable at all.

So as Always I start for Alternatives, there's Xamarain with C# (I'm Sorry I'm not a C# developer). I moved on and I found ReactNative And NativeScript, I choose the second because I'm an Angular developer.

Initially, NativeScript lets developer create Native mobile views and using Javascript as Code behind, then They introduced building apps with Angular, which helps the Angular developer to give a try the mobile development.

Personally, I didn't try NativeScript with Angular.js, the first app I've Made is with Angular2+.

As I mention the layout rendering is Good and fluid, but I've got some complication when using Nativescript:

Garbage Collector (Android Only)

We all know that Angular output is quite big than a plain Javascript app. when exploring the app that I've made, I experience a random UI freeze, and it's remarkable and it affected the user experience.

After an Investigation, I found that the JavaScript GC(Garbage Collector) triggered when no more RAM is available and that causes the freeze ( from 0.5s to 2ssecondsd on Angular). After many issues opened on Github Panayot Cankov wrote a blog (Deep Dive into NativeScript 3.1 Performance Improvements ) about performance and explained why and when this issue happens.

Then in the announcement of NativeScript 3.2 (Announcing the Release of NativeScript 3.2) they introduce an experimental flag "markingMode": "none" for Android, I Tired and the freezes are gone.

Launch Time

Using Angular with NativeScript will affect the launch time especially on Android, and it will take longer than Vanilla Javascript .

Using Webpack to minify and uglify speed up the App, but when I tried the Snapshot flag(Just for Android) I felt the difference.

So what's Snapshot?

It's a previously prepared JavaScript context. Instead of fetching, parsing, and executing scripts on every startup, the NativeScript Android runtime looks for a previously prepared binary file that is the result of those tasks, to reduce the amount of time it takes for your app to get up and running.

Angular 2+ is very structured and it has clean Architecture patterns and it helps you build a scalable application without struggling.

Conclusion

I found that NativeScript and Angular is a successful marriage and I hope it continues.

Other opinions? leave a comment.

HTTP/2

Node.js has stabilized the Http2 protocol and there are already frameworks that support it, right now, like Koa (Made by TJ Holowaychuk who's also made Express.js), Hapi.js and also Express.js using express-http2-workaround middleware.

Enhanced support for ESM modules

As we know Node.js has it's own module system (CommonJS), but it's not quite common as it only supports Node environment so you can't run CommonJS file in the browser.

ECMAScript 6 brought us a module system to JavaScript and Node.js 10 support it.

N-API

Node.js has introduced N-API in the Node v8 release AND now it's Stable. And if you don't already know what N-API is :

It is intended to insulate Add-ons from changes in the underlying JavaScript engine and allow modules compiled for one version to run on later versions of Node.js without recompilation.

NPM ? Node.js

How come Node get updated and NPM not?  NPMJS has realized also a new version and I personally like it, and it comes with:

• Security, security, and security.
• A new command to find security vulnerabilities npm audit
• Optimizations for continuous integration (CI)
• ...

New methods (will cover some)

• Console.table and it displays tabular data as a table and I LOVE it
• The Argument(e) in try {} catch(e) {} is now optional
• ...

Finally the Deprecations

• Using require() to access several of Node.js' own internal dependencies will emit a runtime deprecation.
• Use of non-string values for process.env has been deprecated in the documentation.
• The enroll() and unenroll() methods have been deprecated.

For further details, you can check Node.js announcement Node v10.0.0

Did you hear about DevOps? Yeah, me too, here's what Amazon says about :

DevOps is the combination of cultural philosophies, practices, and tools that increase an organization’s ability to deliver applications and services at high velocity

When I start coding in a new project the first thing I do is to prepare the git repository, there are many services allow you to host your repositories int they servers, the Famous one is Github but you need a membership to host private repositories, like all developers I start looking for an Alternatives until I found Gitlab , There's an open source version (Community) and  I installed on my oven server but It took all of the memory that I have, so I stick with the hosting they provide.

Everything seems Ok until start working with NativeScript and Angular to build mobile Apps, in the DEV world there's always more than environment, at least we have a development environment and production environment when you are in dev environment, you can't know how your code or the plugin that you've just installed gonna behave or will it work in prod environment.

Here there are two main roads, build the application each time I add a NativeScript plugin or code for days then build the App and I found out if everything seems Ok, If not,  you maybe need to change some plugins and rewrite a bunch of lines of code.

The solution?

While browsing the web I found some services contain a CI into they names, like CircleCI , Travis CI , and others, I got curious until I got deep into the subject, And found out that these are tools for Continuous Integration and delivery.

How does it work?

To Deliver a good product you need to do your test the app, by writing the unit tests or/and real humans interaction, you need to run your unit tests each time you add code to find out if you or somebody else broke the app.

Ok, but running tests and building each time in your machine will reduce the performance of your development environment, and for sure will make your nervous, How about building in somebody else machine? that's when I start looking for alternatives solutions, in the meanwhile Gitlab introduce the Continuous Integration feature, and it's for FREE.

Now when I (or anyone else in the same repository ) push a commit, Gitlab will run the test, build and generate an APK file (for Android) for me and show me If there are issues white building.

I will share with you how I've Done it.

You can achieve this workflow by adding .gitlab-ci.yml

Let's break this file down.

First, we created a Job, then we pull a Docker image that contains a fresh Installed version of Android.

Then we installed the Node.js, after that, we installed NativeScript, updating the Android SDK and installing Node modules with NPM.

When everything is done, we build the App with NativeScript CLI (command line tools).

In the build process of NativeScript we pass by the unit tests, if there's an error it will be thrown with an Exception.

If there's no error and everything is fine we will get our APK available to download, This all happens while you're writing your code in peace, you didn't stress your machine but you got visibilities about what's gonna happen when you build for production.

Isn't a big deal? how do you think?

Back in the days, we used to create a state for every block or area that get updated from the same place and does not know anything about the others blocks, or manually update the view and here we need also to update the state of the same block, what a mess. It's hard when you start growing your app using these techniques.

Then I discovered (forced myself to use) Redux or the one state manager, at the beginning I found myself writing more code than I usually do, creating the actions, the reducers, and the effects and so on.

And to create an action I need to pass by many files to do a single interaction, it was like another hell, but when the app starts growing I didn't feel exhausted like before, when I wanna get some data I know exactly how and where to find it,  and also I can easily plug any other blocks into the apps I just need to connect it to the State manager and I get the access to all what I need, Isn't That cool?

But wait I'm an Angular Developer and Redux made for the React Community, well there's an implementation of Redux philosophy for Angular folks and it calls NGRX and I used it in production and everything seems alright.

How about Vue.js developers? Vuex is the implementation of Redux for the Vue.js framework, I tried it and it does what I need.

Using a state Manager really helped me a lot and boost my skills and it reduced the development time.

Forced your self to use it and feel the difference.

Did you try a State Manager before?

How many times you start working with cool UI framework and after a while, you found some limits? did you try to add some features and you lost hours and hours and if you start from the ground it will take you so much less time? it also happens to me.

90% of the UI frameworks looks cool at the beginning, but when the app start growing and we need some extra UI elements we will start looking for a new one to complete the missing elements, OK we found a one, how about using them both? huh, and the size of the App start growing, besides the conflict and the tricks that we do to keep all the UI frameworks works together, THEN our app starts growing with built-in issues (what a cool features).

But How I deal with that?

The last project I start I chose Vue.js as front-end framework, as the majorities of developer I usually kickstart the project with a UI framework, to get more done with less pain, the top elements I usually  use are, the Form and they built-in validation, buttons, modals and they confirmations,  grid and data table.

After exploring some UI frameworks I chose Element-UI , and there's will be always missing components or elements, and when I found something missing what I really did?

I made the missing feature or components, but how?

Before start using any framework, I open the source code and look how they built it, and I read the documentation many times to understand the philosophy behind it and find out if I can easily add features to its core, if not I continue the looking for the other frameworks.

Choosing a UI framework means knowing how to add stuff to it and how to manipulate it.

Why I choose to add to its core rather than create independent components:

• First, we will use they built-in architecture and helpers
• Second, THINK about the community, sharing your features or components with the community will be one of the things that make you happy, helping others is the best thing I ever did.

That's how I deal with UI frameworks, how about you?  ?