¿Polymer JS está muerto?

El polímero no está muerto (ni siquiera cerca), pero se ha enfrentado a muchos desafíos. La ideología de la “biblioteca JS de cliente monolítico” se ha polarizado cada vez más en los últimos tiempos con más desarrolladores debatiendo la adopción de Angular-vs-React. Polymer (y muchas otras bibliotecas) trata de evitar tales conflictos al tener su propio nicho.

El primer problema que Polymer enfrentó temprano fue que su desarrollo fue un proceso lento. Sus “competidores”, como React, se implementaron mucho más rápido e inherentemente ofrecieron muchas más funciones. Esto llevó a Angular y React a ganar más impulso. El impulso de Angular se vio obstaculizado cuando lanzaron su versión (2.0) TypeScript, pero rara vez escucho a la gente quejarse porque TypeScript es bastante genial.

La adopción de Polymer se ha visto obstaculizada porque muchos desarrolladores están eligiendo bibliotecas más robustas y complejas como Angular o React. Pero este no es realmente el problema de Polymer per sé . HN: ¿Cuáles son las desventajas de Google Polymer?

El polímero también es de última generación. Los componentes web permitirían a los desarrolladores confiar menos en bibliotecas como jQuery y otras. El uso de componentes web sigue siendo un concepto nuevo y aún no ha sido estandarizado por W3C. Polymer resuelve esto al ofrecer polyfills para garantizar que su código funcione con la gran mayoría de los navegadores. Pero como Alejandro Hernández afirma sucintamente: “déjenme aclarar esto. Al menos por ahora, vamos a usar bibliotecas JavaScript (es decir, rellenos de polietileno) para evitar el uso de bibliotecas JavaScript. Bueno, eso es ‘fascinante'”.