import { jsx, jsxs, Fragment } from 'solid-jsx/jsx-runtime';

/*@jsxRuntime automatic @jsxImportSource solid-jsx*/
const toc = [{
  "depth": 1,
  "value": "Comparaciones con otros frameworks",
  "children": [{
    "depth": 2,
    "value": "React",
    "children": [{
      "depth": 4,
      "value": "Consejo para migrar:",
      "children": []
    }]
  }, {
    "depth": 2,
    "value": "Vue",
    "children": [{
      "depth": 4,
      "value": "Consejo para migrar:",
      "children": []
    }]
  }, {
    "depth": 2,
    "value": "Svelte",
    "children": [{
      "depth": 4,
      "value": "Consejo para migrar:",
      "children": []
    }]
  }, {
    "depth": 2,
    "value": "Knockout.js",
    "children": [{
      "depth": 4,
      "value": "Consejo para migrar:",
      "children": []
    }]
  }, {
    "depth": 2,
    "value": "Lit & LighterHTML",
    "children": [{
      "depth": 4,
      "value": "Consejo para migrar:",
      "children": []
    }]
  }, {
    "depth": 2,
    "value": "S.js",
    "children": []
  }, {
    "depth": 2,
    "value": "RxJS",
    "children": []
  }, {
    "depth": 2,
    "value": "Otros",
    "children": []
  }]
}];
function _createMdxContent(props) {
  const _components = Object.assign({
    h1: "h1",
    a: "a",
    p: "p",
    h2: "h2",
    h4: "h4",
    code: "code"
  }, props.components);
  return jsxs(Fragment, {
    children: [jsxs(_components.h1, {
      id: "comparaciones-con-otros-frameworks",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#comparaciones-con-otros-frameworks",
        children: "#"
      }), "Comparaciones con otros frameworks"]
    }), "\n", jsxs(_components.p, {
      children: ["Esta sección no puede escapar a cierto sesgo, pero creo que es importante entender dónde se encuentra la solución de Solid en comparación con otras bibliotecas. Esto no se trata de rendimiento. Para obtener una visión definitiva del rendimiento, no dude en consultar [JS Framework Benchmark] (", jsx(_components.a, {
        href: "https://github.com/krausest/js-framework-benchmark",
        children: "https://github.com/krausest/js-framework-benchmark"
      }), ")."]
    }), "\n", jsxs(_components.h2, {
      id: "react",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#react",
        children: "#"
      }), "React"]
    }), "\n", jsx(_components.p, {
      children: "React ha tenido una gran influencia en Solid. Su flujo unidireccional y segregación explícita de lectura y escritura de su API Hooks orientó a la API de Solid. Más que el objetivo de ser solo una \"Biblioteca de renderizado\" en lugar de un framework. Solid tiene opiniones fuertes sobre cómo abordar la gestión de datos en el desarrollo de aplicaciones, pero no busca limitar su ejecución."
    }), "\n", jsx(_components.p, {
      children: "Sin embargo, por mucho que Solid se alinee con la filosofía de diseño de React, funciona de manera fundamentalmente diferente. React usa un DOM virtual y Solid no. La abstracción de React es una partición de componentes de arriba hacia abajo donde los métodos de renderizado se llaman repetidamente y son diferenciados. Solid, en cambio, representa cada template una vez en su totalidad, construye su reactivo gráfico y solo entonces ejecuta instrucciones relacionadas con cambios de granularidad fina."
    }), "\n", jsxs(_components.h4, {
      id: "consejo-para-migrar",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#consejo-para-migrar",
        children: "#"
      }), "Consejo para migrar:"]
    }), "\n", jsxs(_components.p, {
      children: ["El modelo de actualización de Solid no se parece en nada a React, o incluso a React + MobX. En lugar de pensar en los componentes de la función como la función ", jsx(_components.code, {
        children: "render"
      }), ", piense en ellos como un ", jsx(_components.code, {
        children: "constructor"
      }), "."]
    }), "\n", jsxs(_components.p, {
      children: ["En Solid, los props y las stores son [objetos proxy] (", jsx(_components.a, {
        href: "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy",
        children: "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy"
      }), ") que dependen del acceso a la propiedad para el rastreo y las actualizaciones reactivas. Tenga cuidado con la desestructuración o el acceso temprano a la propiedad, lo que puede generar que estas propiedades pierdan reactividad o se disparen en el momento equivocado."]
    }), "\n", jsx(_components.p, {
      children: "Los primitivos de Solid no tienen restricciones como las Reglas de Hooks, por lo que puede anidarlas como mejor le parezca."
    }), "\n", jsxs(_components.p, {
      children: ["En las listas no necesitas utilizar keys explícitamente para obtener un comportamiento con ", jsx(_components.code, {
        children: "keys"
      })]
    }), "\n", jsxs(_components.p, {
      children: ["En React, ", jsx(_components.code, {
        children: "onChange"
      }), " se activa cada vez que se modifica un campo de entrada, pero no es así como ", jsx(_components.code, {
        children: "onChange"
      }), " [funciona de forma nativa](", jsx(_components.a, {
        href: "https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/",
        children: "https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/"
      }), " onchange). En Solid, use ", jsx(_components.code, {
        children: "onInput"
      }), " para suscribirse a cada cambio de valor."]
    }), "\n", jsxs(_components.p, {
      children: ["Finalmente, no hay VDOM, por lo que las API de VDOM imperativas como ", jsx(_components.code, {
        children: "React.Children"
      }), " y ", jsx(_components.code, {
        children: "React.cloneElement"
      }), " no tienen equivalente en Solid. En lugar de crear o modificar elementos DOM directamente, exprese sus intenciones de forma declarativa."]
    }), "\n", jsxs(_components.h2, {
      id: "vue",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#vue",
        children: "#"
      }), "Vue"]
    }), "\n", jsx(_components.p, {
      children: "Solid no está particularmente influenciado por Vue en cuanto al diseño, pero son comparables en su enfoque. Ambos usan Proxies en su sistema Reactivo con seguimiento automático basado en lectura. Pero ahí es donde terminan las similitudes. La detección de dependencias de granularidad fina de Vue solo alimenta un DOM virtual y un sistema de componentes menos granulares, mientras que Solid mantiene su granularidad hasta sus actualizaciones directas de DOM."
    }), "\n", jsx(_components.p, {
      children: "Vue valora la facilidad donde Solid valora la transparencia. Aunque la nueva dirección de Vue con Vue 3 se alinea más con el enfoque que toma Solid. Estas bibliotecas pueden alinearse más con el tiempo dependiendo de cómo continúen evolucionando."
    }), "\n", jsxs(_components.h4, {
      id: "consejo-para-migrar-1",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#consejo-para-migrar-1",
        children: "#"
      }), "Consejo para migrar:"]
    }), "\n", jsxs(_components.p, {
      children: ["Como otra biblioteca reactiva moderna migrar desde Vue 3 debería sentirse familiar. Los componentes de Solid son muy parecidos a etiquetar la plantilla al final de la función ", jsx(_components.code, {
        children: "setup"
      }), " de Vue. Tenga cuidado de envolver las derivaciones de estado con computaciones, pruebe una función. La reactividad es generalizada. Los proxies de Solid son intencionalmente de solo lectura. No lo golpees antes de probarlo."]
    }), "\n", jsxs(_components.h2, {
      id: "svelte",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#svelte",
        children: "#"
      }), "Svelte"]
    }), "\n", jsx(_components.p, {
      children: "Svelte fue pionera en el marco de desaparición precompilado que Solid también emplea hasta cierto punto. Ambas bibliotecas son realmente reactivas y pueden producir paquetes de código de ejecución realmente pequeños, aunque Svelte es el ganador aquí para demostraciones pequeñas. Solid requiere un poco más de claridad en sus declaraciones, confiando menos en el análisis implícito del compilador, pero eso es parte de lo que le da a Solid un rendimiento superior. Solid también mantiene más en el entorno de ejecución, lo que escala mejor en aplicaciones más grandes. La implementación de demostración RealWorld de Solid es un 25 % más pequeña que la de Svelte."
    }), "\n", jsx(_components.p, {
      children: "Ambas bibliotecas tienen como objetivo ayudar a sus desarrolladores a escribir menos código, pero lo abordan de manera completamente diferente. Svelte 3 se centra en la optimización de la facilidad para tratar con cambios localizados centrándose en la interacción de objetos simples y binding bidireccional. En contraste, Solid se enfoca en el flujo de datos adoptando deliberadamente CQRS y una interfaz inmutable. Con una composición de plantillas funcional, en muchos casos, Solid permite a los desarrolladores escribir incluso menos código que Svelte, aunque la sintaxis de la plantilla de Svelte es definitivamente más concisa."
    }), "\n", jsxs(_components.h4, {
      id: "consejo-para-migrar-2",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#consejo-para-migrar-2",
        children: "#"
      }), "Consejo para migrar:"]
    }), "\n", jsx(_components.p, {
      children: "La experiencia del desarrollador es lo suficientemente diferente que, si bien algunas cosas son análogas, es una experiencia muy diferente. Los componentes de Solid son baratos, así que no dudes en tener más."
    }), "\n", jsxs(_components.h2, {
      id: "knockoutjs",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#knockoutjs",
        children: "#"
      }), "Knockout.js"]
    }), "\n", jsx(_components.p, {
      children: "Esta biblioteca debe su existencia a Knockout. La modernización de su modelo para la detección detallada de dependencias fue la motivación de este proyecto. Knockout se lanzó en 2010 y es compatible con Microsoft Explorer hasta IE6, mientras que gran parte de Solid no es compatible con IE en absoluto."
    }), "\n", jsx(_components.p, {
      children: "Los enlaces de Knockout son solo cadenas en HTML que se recorren en tiempo de ejecución. Dependen del contexto de clonación ($parent, etc.). Mientras que Solid utiliza JSX o literales de plantillas etiquetadas para crear plantillas y optar por una API de JavaScript."
    }), "\n", jsx(_components.p, {
      children: "La mayor diferencia podría ser que el enfoque de Solid para el procesamiento por lotes de cambios garantiza la sincronía, mientras que Knockout tiene deferUpdates, que utiliza una cola de microtareas diferidas."
    }), "\n", jsxs(_components.h4, {
      id: "consejo-para-migrar-3",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#consejo-para-migrar-3",
        children: "#"
      }), "Consejo para migrar:"]
    }), "\n", jsx(_components.p, {
      children: "Si está acostumbrado a Knockout, las primitivas de Solid pueden parecer extrañas. La separación de lectura/escritura es intencional y no solo para hacer la vida más difícil. Busque adoptar un modelo mental de estado/acción (Flux). Si bien las bibliotecas se ven similares, promueven diferentes mejores prácticas."
    }), "\n", jsxs(_components.h2, {
      id: "lit--lighterhtml",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#lit--lighterhtml",
        children: "#"
      }), "Lit & LighterHTML"]
    }), "\n", jsx(_components.p, {
      children: "Estas bibliotecas son increíblemente similares y han tenido cierta influencia en Solid. Principalmente, el código compilado de Solid utiliza un método muy similar para representar inicialmente el DOM de manera eficaz. La clonación de elementos de plantilla y el uso de marcadores de posición de comentarios son algo que Solid y estas bibliotecas comparten."
    }), "\n", jsx(_components.p, {
      children: "La mayor diferencia es que, si bien estas bibliotecas no usan Virtual DOM, tratan el renderizado de la misma manera, de arriba hacia abajo, lo que requiere la partición de componentes para mantener las cosas en orden. En contraste, Solid usa su gráfico reactivo de granularidad fina para actualizar solo lo que ha cambiado y, al hacerlo, solo comparte esta técnica para su renderizado inicial. Este enfoque aprovecha la velocidad inicial solo disponible para el DOM nativo y también tiene el enfoque más eficaz para las actualizaciones."
    }), "\n", jsxs(_components.h4, {
      id: "consejo-para-migrar-4",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#consejo-para-migrar-4",
        children: "#"
      }), "Consejo para migrar:"]
    }), "\n", jsxs(_components.p, {
      children: ["Estas bibliotecas son bastante mínimas y fáciles de construir encima. Sin embargo, tenga en cuenta que ", jsx(_components.code, {
        children: "<MyComp/>"
      }), " no es solo HTMLElement (arreglo o función). Intenta mantener tus cosas en la plantilla JSX. La elevación funciona en su mayor parte, pero es mejor pensar mentalmente en esto como una biblioteca de renderizado y no como una fábrica de HTMLElement."]
    }), "\n", jsxs(_components.h2, {
      id: "sjs",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#sjs",
        children: "#"
      }), "S.js"]
    }), "\n", jsx(_components.p, {
      children: "Esta biblioteca tuvo la mayor influencia en el diseño reactivo de Solid. Solid usó S.js internamente durante un par de años hasta que el conjunto de funciones los colocó en caminos diferentes. S.js es una de las bibliotecas reactivas más eficientes hasta la fecha. Modela todo a partir de pasos de tiempo sincrónicos como un circuito digital y garantiza la consistencia sin tener que hacer muchos de los mecanismos más complicados que se encuentran en bibliotecas como MobX. La reactividad de Solid al final es una especie de híbrido entre S y MobX. Esto le da un mayor rendimiento que la mayoría de las bibliotecas reactivas (Knockout, MobX, Vue) al tiempo que conserva la facilidad del modelo mental para el desarrollador. S.js, en última instancia, sigue siendo la biblioteca reactiva de mayor rendimiento, aunque la diferencia apenas se nota en todos los puntos de referencia excepto en los más agotadores benchmarks sintéticos."
    }), "\n", jsxs(_components.h2, {
      id: "rxjs",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#rxjs",
        children: "#"
      }), "RxJS"]
    }), "\n", jsx(_components.p, {
      children: "RxJS es una biblioteca reactiva. Si bien Solid tiene una idea similar de los datos observables, utiliza una aplicación muy diferente del patrón del observador. Si bien las señales son como una versión simple de un Observable (solo el siguiente), el patrón de detección de dependencia automática reemplaza a los cien o más operadores de RxJS. Solid podría haber adoptado este enfoque y, de hecho, las versiones anteriores de la biblioteca incluían operadores similares, pero en la mayoría de los casos es más sencillo escribir su propia lógica de transformación en una computación. Mientras que los Observables son de arranque en frío, unidifusión y basados en push, muchos problemas en el cliente se prestan a un arranque en caliente y multidifusión, que es el comportamiento predeterminado de Solid."
    }), "\n", jsxs(_components.h2, {
      id: "otros",
      children: [jsx(_components.a, {
        className: "header-anchor",
        href: "#otros",
        children: "#"
      }), "Otros"]
    }), "\n", jsx(_components.p, {
      children: "Angular y algunas otras bibliotecas populares faltan notablemente en esta comparación. La falta de experiencia con ellos impide hacer comparaciones adecuadas. En general, Solid tiene poco en común con Frameworks más grandes y es mucho más difícil compararlos de frente."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? jsx(MDXLayout, Object.assign({}, props, {
    children: jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}

export { MDXContent as default, toc };
//# sourceMappingURL=comparison-d3e09436.js.map
