He visto desarrolladores que han estado trabajando con C durante mucho tiempo y todavía desarrollan con MFC (Microsoft Foundation Classes). La razón es simple: no existen alternativas reales para crear interfaces de usuario en C. Si bien Qt existe, requiere una licencia comercial para uso profesional, lo que convierte a MFC en la única opción.

MFC proporciona componentes de interfaz de usuario básicos, pero aún es capaz de crear programas de nivel de producción como software CAD o aplicaciones para hospitales.

El estado actual del ecosistema JavaScript es bastante similar.

No existe ningún marco que se haya creado específicamente para abordar los objetivos de HPSE. Si bien existen motores de juegos como Babylon.js, estos solo ofrecen funciones para gráficos 3D y no proporcionan una estructura general como lo hace React.

Entonces, al final, todo vuelve a Vanilla JavaScript y TypeScript. No es que los desarrolladores utilicen Vanilla JavaScript porque les encanta; lo usan porque no hay otra opción. Al igual que en los primeros días, cuando los desarrolladores tenían que construir todo desde cero en C debido a la falta de marcos comerciales, ahora nos enfrentamos a la misma situación en JavaScript. No existe ningún marco que satisfaga completamente las demandas de HPSE, por lo que debemos desarrollar manualmente con Vanilla JavaScript.

Y, francamente, esto no es exclusivo de JavaScript. Esto también se aplica a la mayoría de los demás idiomas.

Hay un dicho que dice: "No existe el almuerzo gratis".

Muchos de los programas que comenzaron con grandes ambiciones de romper nuevos límites han terminado dependiendo en gran medida de funciones personalizadas creadas directamente dentro del lenguaje de programación. HPSE también comenzó con la visión de algún día ejecutar programas nativos en el navegador y, por ahora, debe escribirse pieza por pieza en Vanilla JavaScript.

Algunos podrían argumentar: "¿Por qué no simplemente abandonar JavaScript y usar C o Rust para crear un módulo WebAssembly (WASM) y ejecutarlo en el navegador?"

Hay una buena historia que responde a esta pregunta.

Una vez se les preguntó a los líderes de Babylon.js y Three.js en un comentario si la tecnología WASM sería el futuro de sus motores. Su respuesta fue "No."

La razón es simple: el código C/Rust no se ejecuta directamente en el entorno web, lo que dificulta la depuración. Y gracias a los avances del motor V8, JavaScript ahora puede alcanzar un alto rendimiento. JavaScript es un lenguaje de programación que se ejecuta directamente en el navegador y ofrece alta productividad; no es necesario abandonar estas fortalezas.

En el pasado, los programadores competían desarrollando sus propios sistemas operativos. Pero después de que Windows, Mac y Linux se convirtieran en estándares, la atención se centró en cómo crear programas que se ejecuten sobre estos sistemas. De manera similar, los navegadores actuales han evolucionado hasta un punto en el que es razonable pensar en cómo crear programas que se ejecuten en ellos.

Si hubiera líneas claras sobre para qué debería y no debería usarse JavaScript, y si las tareas de alto nivel fueran realmente inadecuadas para JavaScript, entonces Microsoft nunca habría iniciado el proyecto Babylon.js, y Three.js nunca lo habría hecho. han sido creados. Lo mismo ocurre con WebGPU, que se está estableciendo como un nuevo estándar web.

Recientemente, he estado reflexionando sobre mi identidad como desarrollador, preguntándome qué significa exactamente "frontend" y si ese término realmente puede abarcar el alcance del desarrollo de clientes web.

Estoy seguro de que hay mucha información errónea en mis pensamientos, pero publicaré esto como mi primera entrada en el blog para consolidar lo que he estado pensando.