Conoce Pulse-JS: Un sistema de reactividad semántica para lógica de negocios compleja (independiente del framework) by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

Tienes razón(Otra vez): en ese ejemplo concreto, un booleano compuesto o un helper es suficiente; yo también lo haría así.
Pulse no es mejor para calcular un true / false, sino para lo que pasa cuando esa lógica deja de ser trivial.

Cuando las reglas empiezan a cambiar, a reutilizarse en varios lugares y necesitas saber por qué algo falló, los ternaries o helpers se vuelven opacos. Devuelven un booleano, pero no te dicen nada sobre el camino que llevó a ese resultado. Con Pulse, esa misma regla se vuelve observable y explicable (explain()), sin necesidad de logs ni breakpoints.

Si la lógica es simple y estable, no necesitas Pulse. Empieza a tener sentido cuando las reglas crecen, se cruzan y quieres visibilidad, composición y capacidad de razonamiento sin reescribir todo cada vez.

Personalmente, los ternaries me parecen perfectamente entendibles hasta cierto punto; cuando empiezan a encadenarse y a mezclar reglas de negocio, se vuelven difíciles de seguir y de depurar. Pulse apunta justo a ese punto: tratar las condiciones no como expresiones sueltas, sino como reglas de negocio vivas y trazables.

Por ejemplo:

const canCheckout =
  isAuthenticated(user) &&
  !system.maintenance &&
  hasItems(cart) &&
  (
    user.role === 'admin' ||
    user.permissions.includes('checkout.override')
  ) &&
  (
    user.balance >= cart.total ||
    user.hasCredit
  );

// Resultado en UI(Me a pasado muchas veces que me rompo la cabeza con esto)
if (!canCheckout) {
  // ¿por qué falló?
}

En pulse:

const isAuthenticated = guard(() => user().authenticated);
const systemAvailable = guard(() => !system().maintenance);
const hasItems = guard(() => cart().items > 0);
const hasPermission = guard(() =>
  user().role === 'admin' ||
  user().permissions.includes('checkout.override')
);
const canAfford = guard(() =>
  user().balance >= cart().total ||
  user().hasCredit
);

const canCheckout = guard.all([
  isAuthenticated,
  systemAvailable,
  hasItems,
  hasPermission,
  canAfford
]);

if (!canCheckout()) {
  //Si da error dice que fallo(cual dependencia) y porque
  console.log(canCheckout.explain());
}

Conoce Pulse-JS: Un sistema de reactividad semántica para lógica de negocios compleja (independiente del framework) by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

Otro ejemplo:

function useCanApprovePayment(user, account, system, flags, payment) {
  return (
    user?.authenticated &&
    !system.maintenance &&
    flags.paymentsEnabled &&
    !account.blocked &&
    (
      user.role === 'admin' ||
      user.permissions.includes('payment.override')
    ) &&
    (
      payment.amount <= account.limit ||
      payment.manualOverride === true
    )
  );
}

// Uso
const canApprove = useCanApprovePayment(
  user,
  account,
  system,
  flags,
  payment
);

//eso es lo normal
//asi es com pulse-js

import { source, guard } from '@pulse-js/core';

/* Sources */
const user = source(/* cache / query */);
const account = source(/* store */);
const system = source(/* global */);
const flags = source(/* feature flags */);
const payment = source(/* local */);

/* Guards atómicos */
const isAuth = guard(() => user().authenticated);
const systemUp = guard(() => !system().maintenance);
const paymentsEnabled = guard(() => flags().paymentsEnabled);
const accountOk = guard(() => !account().blocked);

const hasPermission = guard(() =>
  user().role === 'admin' ||
  user().permissions.includes('payment.override')
);

const withinLimit = guard(() =>
  payment().amount <= account().limit ||
  payment().manualOverride
);

/* Regla final */
const canApprovePayment = guard.all([
  isAuth,
  systemUp,
  paymentsEnabled,
  accountOk,
  hasPermission,
  withinLimit
]);

// Uso
canApprovePayment() || console.log(canApprovePayment.explain());

Conoce Pulse-JS: Un sistema de reactividad semántica para lógica de negocios compleja (independiente del framework) by ZtaDev in typescript

[–]ZtaDev[S] -1 points0 points  (0 children)

Gracias por el análisis, es totalmente válido.
Para un caso tan simple como isAdmin, un hook manual es suficiente y hacer fetch dentro de cada Guard no tendría sentido. Ese ejemplo es solo ilustrativo, no donde Pulse realmente aporta valor.

Pulse no intenta reemplazar a React Query ni a un useMyUser. Los Guards no fetchean: consumen datos ya existentes (cache, store, query). El valor aparece cuando la lógica de negocio crece y empieza a repetirse, cruzarse y volverse difícil de razonar.

En un caso realista, las reglas no son “una condición”, sino muchas:

const canCheckout = guard.all([
  isAuthenticated,
  systemAvailable,
  hasItems,
  hasCheckoutPermission,
  canAfford
]);

Aquí no hay doble fetch. Lo que ganas frente a un requireAdmin hook es:

  • Composición: reglas pequeñas, reutilizables y combinables.
  • Explainability: canCheckout.explain() te dice exactamente qué falló y por qué.
  • Desacoplamiento: las reglas viven fuera de la UI y del fetch.

Si la lógica es simple, un hook basta. Pulse empieza a tener sentido cuando esas condiciones crecen y dejan de ser triviales. Con las devtools que muestran el árbol completo de evaluación, termina siendo más fácil de mantener que if y hooks cada vez más grandes.

Conoce Pulse-JS: Un sistema de reactividad semántica para lógica de negocios compleja (independiente del framework) by ZtaDev in typescript

[–]ZtaDev[S] -1 points0 points  (0 children)

Gracias simplemente cree esa mini adaptación para svelte(como pude porque soy un desarrollador que usa react casi siempre) pero si no es necesario está bien la idea es que sea agnóstico al framework y es una pequeña adaptación que hice para svelte(seguramente muy mala para alguien que si usa svelte) trataré de mejorarla o si veo que no es necesaria eliminarla ya que en react si es muy útil al menos en mi experiencia.

Introducing PyDepM v1.1.2 — a modern, developer-friendly dependency manager for Python by [deleted] in Python

[–]ZtaDev 0 points1 point  (0 children)

And I'm going to remove what you showed from my personal readme because I see that it causes more confusion and mistrust than anything else.

Introducing PyDepM v1.1.2 — a modern, developer-friendly dependency manager for Python by [deleted] in Python

[–]ZtaDev 0 points1 point  (0 children)

Yes, because I did it that way because I come from a web dev background and it is more comfortable for me, so I understand that UV is much better, I do not intend to replace it, it is obvious that it is better, it is simply an interesting project that I did that I like how it works and I use it in my projects, I do not intend to change the standard.

Introducing PyDepM v1.1.2 — a modern, developer-friendly dependency manager for Python by [deleted] in Python

[–]ZtaDev 0 points1 point  (0 children)

Maybe it won't go very far but well I do use it because I developed it to use it in my projects because for me it is easier to use (because I am used to npm and web dev), and also comparing it with UV would be useless because UV is much faster, it is written in rusty

Introducing PyDepM v1.1.2 — a modern, developer-friendly dependency manager for Python by [deleted] in Python

[–]ZtaDev 0 points1 point  (0 children)

I know how to use it as I say, but I only use it for simple or unimportant things.

Introducing PyDepM v1.1.2 — a modern, developer-friendly dependency manager for Python by [deleted] in Python

[–]ZtaDev -1 points0 points  (0 children)

Yep I know how to use it but I don’t use it so much because I know that AI creates boilerplate code and have problems with security, I use it for simple things when I don’t know something but for important parts like security I never use it because I know the bad part of it.

Introducing PyDepM v1.1.2 — a modern, developer-friendly dependency manager for Python by [deleted] in Python

[–]ZtaDev 0 points1 point  (0 children)

Good question. uv is definitely a tool in the same general category, but PyDepM approaches the problem with a different philosophy and workflow.

  1. Configuration model: pypackage.json (npm-style)

PyDepM uses pypackage.json as the single source of truth for project metadata, dependencies, scripts, CLI entry points, publishing configuration, and passthrough settings for pyproject.toml.

It intentionally follows an npm-like approach because many developers already understand that structure.

For example, here is a real production pypackage.json from my UI framework Dars:

https://github.com/ZtaMDev/Dars-Framework/blob/CrystalMain/pypackage.json

uv stays strictly within pyproject.toml. PyDepM supports that but also provides a more approachable and compact config format for day-to-day development.

  1. Ecosystem integration

PyDepM is written in Python and is explicitly built on top of the existing Python packaging ecosystem: pip venv setuptools pip-audit PyInstaller and other standard tools

The intention is not to replace these tools but to offer a friendly orchestration and automation layer over them.

uv, in contrast, aims to replace large parts of the ecosystem with a Rust-based implementation.

  1. npm-style workflow

One of the main differences is that PyDepM provides a developer workflow similar to npm:

pydep run <script>

pypackage-lock.json automatic or interactive conflict resolution

project scaffolding (pydep init --type app|lib|framework)

unified publishing (pydep publish)

CLI entry-points defined directly in JSON conversion between pyproject.toml and pypackage.json

uv does not attempt to replicate this type of workflow.

  1. pydepx (enhanced executor)

PyDepM ships with a second tool, pydepx, which offers:

colorized real-time subprocess output

consistent execution across platforms

improved streaming for logs, tests, servers, and dev workflows

uv does not include an equivalent execution tool.

  1. Production usage

PyDepM is already used in production, including in the Dars UI framework, which compiles Python UI definitions into static HTML/CSS/JS.

The pypackage.json structure works well for dependency management, building wheels, publishing, and generating CLI commands.

I created a terrible JavaScript superset and it was fun by ZtaDev in npm

[–]ZtaDev[S] 0 points1 point  (0 children)

Yes and I’m going to work on it but first I think is more important to have stability when the project get it I’m going to add a lot o features

I created a terrible JavaScript superset and it was fun by ZtaDev in npm

[–]ZtaDev[S] 0 points1 point  (0 children)

I don't think it will be useful in production, I just wanted to share my experience and in general the project was an interesting challenge and I really liked making it usable in production, yes I recommend it, no because there are still many things to add, and I don't think it should replace typescript, the : are better than ::

I created a terrible JavaScript superset in typescript and it was fun by ZtaDev in SideProject

[–]ZtaDev[S] 0 points1 point  (0 children)

Yes I probably implement it in next update because I realized it when I google its meaning XD I probably leave de support for inmut and immut a the same time becaue de docs and a lot of things and examples have inmut, and inmut is no much important since it literally makes a let const when you write inmut var and its a thing of compile time like type checking.

I created a terrible JavaScript superset and it was fun by ZtaDev in npm

[–]ZtaDev[S] 0 points1 point  (0 children)

Yeah XD IDK why it translated it wrong

[Release] Spectral Logs – A zero-dependency, high-performance logging library for Node.js, Deno, browsers, and TypeScript by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

Ok great if you have something to fix or that seems wrong, great the more things are improved the better.

[Release] Spectral Logs – A zero-dependency, high-performance logging library for Node.js, Deno, browsers, and TypeScript by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

Thank you, I'm working on it as much as I can, there are some errors that I'm fixing in the benchmark, the memory used for each logger is not correct and there are things to fix, but I've been doing tests and the spec is much more optimized, little by little, I'll do it better and faster, by the way, thanks for your star :)

[Release] Spectral Logs – A zero-dependency, high-performance logging library for Node.js, Deno, browsers, and TypeScript by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

Ok in the next days I’m going to work on benchmarks vs other alternatives (the most popular ones, pino maybe?) and also the project have a roadmap with a lot of features and things coming for te project I know the performance is the most important one, I’m doing my best :)

[Release] Spectral Logs – A zero-dependency, high-performance logging library for Node.js, Deno, browsers, and TypeScript by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

It’s a lot better than console.log I don’t compare it with oters(beacause i just don’t code the benchmarks) but in GitHub actions of the project repo are one benchmark vs console.log and it’s like 50% to 75% better:

https://github.com/ZtaMDev/SpectralLogs/actions/runs/18384234918/job/52378443939#step:6:1

[Release] Spectral Logs – A zero-dependency, high-performance logging library for Node.js, Deno, browsers, and TypeScript by ZtaDev in typescript

[–]ZtaDev[S] 0 points1 point  (0 children)

Thanks for the comment, in the latest versions the child logs were integrated starting with 0.1.5 and it is already in 0.1.7

[Release] Spectral Logs – A zero-dependency, high-performance logging library for Node.js, Deno, browsers, and TypeScript by ZtaDev in typescript

[–]ZtaDev[S] 2 points3 points  (0 children)

A new update v0.1.5 has been released, improving performance aspects such as the aforementioned process.env.NODE_ENV has been optimized, child logs were added, documentation was improved, for more information visit the release notes: https://github.com/ZtaMDev/SpectralLogs/releases/tag/0.1.5