EDICIóN GENERAL

Nuevo en PHP 8 [ENG]

#43 Yo no he dicho que sea terrible. Trabajé 10 años con él y me parece cojonudo, pero creo que se ha quedado anticuado. ¿Renderizar en el servidor? Nah. Y para backend hay cosas mejor paridas.
#49 ¿Qué razones ves para calificarlo de anticuado? Lo digo porque PHP es un lenguaje que sigue evolucionando, añadiendo tipado opcional, avanzando en capacidades funcionales, mejorando rendimiento.

Por otro lado, el renderizado en servidor no es lo único que hace el backend. Es más, el renderizado en servidor sigue siendo algo dominante. Tenemos el ejemplo de Twitter que lo renderizaba todo en cliente pero les introducía un retardo hasta que el usuario podía ver el contenido, por lo que lo rehicieron renderizando en servidor usando técnicas de JS isomórfico. Pero en ese caso el primer renderizado sigue ocurriendo en el servidor, y es básicamente porque los navegadores (casi) solo entienden JavaScript. Una opción es un backend puro que se comunique con Nodejs que se encarga del prerenderizado, por ejemplo.

En fin, que Nodejs está muy bien, como también lo está PHP. Es cuestión de usar la herramienta adecuada para el problema adecuado, y PHP sigue siendo adecuado para muchos problemas (igual que para otros Nodejs es mejor opción).
#51 Probablemente porque empecé a usarlo en 2002, por eso me parece anticuado. Ahora le saco mucho partido a las capacidades asíncronas de NodeJS. Seguro que ha evolucionado mucho, pero sigue siendo un preprocesador de hypertexto que tiene que unirse a un servidor web para poder ejecutar una aplicación para web. He hecho muchas comparativas de rendimiento NodeJS vs PHP (usando FPM y demás técnicas, varios servidores web, etc.) y no hay color. Trabajar con objetos JS nativamente sin necesidad de parsear también es otra ventaja de NodeJS frente a PHP.

Yo no digo que esté mal, pero ahora lo hago todo con NodeJS y Typescript y, una vez captados los conceptos de asincronía, me parece todo mucho mejor integrado, más flexible, con mejor rendimiento y acortando tiempos de desarrollo considerablemente, por no hablar de reutilizar estructuras de datos tanto en back como en front.
#53 He hecho muchas comparativas de rendimiento NodeJS vs PHP

Lo que tengo entendido es que PHP tiene mejor rendimiento que NodeJS en cuanto a ejecución del lenguaje. Nodejs gana seguramente en el número de peticiones por segundo cuando la petición es una respuesta relativamente simple (es maś sencillo del uso de callbacks en Nodejs que en PHP).

una vez captados los conceptos de asincronía, me parece todo mucho mejor integrado

En un entorno asíncrono cosas como la programación reactiva (supongo que usas RxJS, o algo similar) es maravilloso, no hay nada mejor para gestionar la alta asincronía. De hecho ante proyectos muy asíncronos en el servidor me he planteado usar nodejs por poder usar toda la potencia de la RxJS (y alguna cosa más). Hay Rx para PHP pero no tienen todo. También es cierto que en el modelo de PHP de petición-respuesta no suele haber asincronía, por lo que no ganas demasiado.

Para un entorno asíncrono y ligero: nodejs suena muy bien. Para un entorno sin asincronía y peticiones más complejas, creo que PHP sigue siendo una buena opción.

TypeScript es un gran lenguaje, y lo dice alguien que sus dos frentes son ahora mismo PHP y TypeScript. Y lo de la JS isomórfico es una gran aproximación si puedes contar con un backend (completo o parcial) en JS.
#53 Yo he hecho por aprender un pequeño juego html5 multiplayer en nodejs (todavía sin pulir) aprovechando la experiencia que ya tenía de front-end clásico (tipo jquery y demás) y es muy muy fácil perder el hilo de lo que estás haciendo en cuanto el programa se vuelve complejo, y además los IDE te ayudan sólo de forma limitada precisamente por esto.

De hecho creo que reescribiré el servidor en Rust, Javascript es en realidad potente de cojones porque permite mil pajas mentales que además funcionan, pero una pesadilla si quieres hacer algo serio precisamente porque todo es tan mutable y flexible que llega un momento que no sabes qué es cada objeto que estás manejando (puedes meter, sacar, poner y quitar lo que quieras sobre la marcha al ser todo un diccionario en el fondo) y puedes darte tiros en el pie de mil formas diferentes.
Para cosas complejas se hace muy necesario un sistema de tipos. Typescript es una buena idea, pero no deja de ser una ñapa que además acaba sin dar todas las ventajas de un lenguaje compilado, ya que al final ejecutas javascript igualmente y los tipos no ayudan al JIT.

No quiero ni empezar a hablar de toda la mierda de ecosistema (transpilers, gestores de paquetes que crean tantos problemas como solucionan, polyfills, builders, etc.) que hay hoy día detrás de javascript, múltiples herramientas que hacen complicado lo que debería ser trivial, que al final tienes que montarte un sistema de build para un puto lenguaje de scripting. Me parece pesadillesco y sujeto con cinta aislante.
#66 tienes toda la razón. Puedes usar la ñapa de typescript para un tipado simple que te salvaría en la mayoría de situaciones dadas en desarrollos de aplicaciones normales. Y es cierto que hay mucha parafernalia. Al principio me volvía loco, pero ahora que más o menos controlo el caos me centro en la parte buena, que es que tienes paquetes hechos para lo que se te ocurra, y eso me hace ganar mucho más tiempo que el que pierdo ahora conteniendo el caos.

menéame