¿Cuál es el nuevo lenguaje para reemplazar PHP? Si alguien creara un sitio de red social como Facebook, ¿qué idioma le recomendaría, teniendo en cuenta los pocos millones de personas en un momento dado, velocidad, eficiencia, etc.?

Como todos saben, PHP está muriendo lentamente … ” ¿Qué todos? Dime donde vive. ” Si alguien creara un sitio de redes sociales como Facebook …” Facebook se ejecuta en PHP y son buenos.

Es como si preguntaras ‘Oh, ¿puedo reemplazar un mango por una naranja?’.

No se puede reemplazar un mango con una naranja porque, si bien ambas son frutas, son diferentes. Pero puedes tener una naranja como alternativa al mango.

Sin mucho ruido, veamos algunos hechos / estadísticas:

  • PHP es lo suficientemente potente como para ser el núcleo del sistema de blogs más grande de la web, WordPress.
  • PHP es lo suficientemente profundo como para ejecutar la red social más grande, ¡Facebook!
  • ¡PHP es fácil de aprender y se ejecuta eficientemente en el lado del servidor!
  • PHP se ejecuta en varias plataformas como Windows, Linux, Unix y Mac OS X.
  • PHP es compatible con casi todos los servidores utilizados hoy como Apache, IIS entre otros.
  • PHP soporta una amplia gama de bases de datos
  • PHP es gratis. Descárgalo desde el recurso oficial de PHP ahora

Con los desarrollos recientes en www, las empresas se han trasladado a la web, no solo con fines publicitarios, sino con el propósito de vender en línea. Esto ha llevado al desarrollo de tecnologías y plataformas que son más personalizadas y específicas para las tiendas de comercio electrónico en línea.

WooCommerce es una plataforma de comercio electrónico en línea completamente construida en PHP. Con 16,421,945 descargas, WooCommerce controla más del 37% de todas las tiendas en línea. WooCommerce es ahora la plataforma de comercio electrónico más popular en la web.

Las estadísticas de Builtwith ponen a WooCommerce y Magento, una solución de comercio electrónico basada en PHP, como los marcos más populares para las tiendas en línea. Para que pueda estar seguro de que está en buena compañía.

Como desarrollador de PHP, tiene acceso al soporte de una de las comunidades de código abierto más grandes de canales como stackoverflow y Github. Obtener ayuda cuando la necesita realmente puede acortar su curva inclinada y aliviar el dolor del aprendizaje del desarrollo web.

Además del comercio electrónico, hay muchas aplicaciones, puntos finales API, sitios web, servicios web y mucho más que se pueden construir utilizando el lenguaje. PHP se enorgullece de ser uno de los idiomas con el mayor número de marcos de desarrollo web de código abierto.

Desde los grandes como Laravel, CodeIgniter, CakePHP hasta los más jóvenes como el marco Gliver, tienes un lago de opciones para elegir. Puede dejar que su ego se desboque y aún así encontrar un marco que se ajuste mejor.

Puedes despotricar sobre PHP todo el día, pero la mejor manera de apreciar el poder es:

  1. Aprende el lenguaje.
  2. Construir un proyecto en él, y
  3. Aprende tus lecciones de primera mano.

¡Feliz codificación!

Hay muchos idiomas diferentes que se pueden usar para el desarrollo del lado del servidor. Algunas opciones populares han incluido Java, Scala, JavaScript, Python y Ruby. Por ahora, no diría que ninguno de estos lenguajes “reemplazaría” PHP, per se, pero parece que JavaScript ha estado haciendo una gran mella en el desarrollo del lado del servidor. Sin embargo, hay muchos marcos con estos lenguajes anteriores que se han utilizado para sitios web de redes sociales populares como Facebook.

Java / Scala (ambos usan JVM) tienen Play Framework y compañías como Twitter y LinkedIn lo usan en desarrollo. Los dos frameworks más populares de Python, Flask y Django, se usan en sitios web como Instagram, YouTube, Dropbox, etc. Codecademy, Twitter, Hulu, GitHub ha utilizado Ruby on Rails, escrito en Ruby (¡sorpresa!). Finalmente, Express.js, creado sobre Node.js (un nuevo entorno de ejecución popular para JavaScript) ha impulsado los servidores de Walmart, Microsoft, LinkedIn, Yahoo, Netflix y Uber, por nombrar algunos.

A pesar de las grandes palabras de moda lanzadas por muchos de estos marcos del lado del servidor, ninguno de estos lenguajes con sus respectivos marcos tiene la mejor solución universal. Cada uno de ellos tiene sus ventajas y desventajas: la única forma de llegar a un veredicto es evaluar las herramientas necesarias para su producto.

Hay varias consideraciones que uno debe enfrentar al elegir un marco de trabajo, tales como obstinado versus no obstinado, síncrono vs. asincrónico, velocidad de creación de prototipos, etc. Por ejemplo, sería absurdo no usar Node.js o Play para un mensaje Aplicación web con muchos clientes. Sería excesivo usar Rails o Django para un servidor pequeño que simplemente se usa para enrutar solicitudes de API. Además, dependiendo de su habilidad para escalar aplicaciones, Flask podría no ser la mejor opción para un sitio web con un montón de solicitudes simultáneas.

Los factores de los que habla, como la velocidad y la eficiencia, son normalmente componentes de “escalado”. Todos estos marcos web tienen el potencial de “escalar” una aplicación web porque prácticamente usan los mismos componentes e interactúan con el mismo tipo del cliente Elegir un lenguaje o marco depende de lo que hablé antes: usted mismo . Piense en su familiaridad con un lenguaje en particular, qué tan rápido necesita un prototipo, qué tipo de módulos encajan mejor con un marco, etc. Esto será una búsqueda del alma en el nivel de programación y es un paso necesario para decidir qué marco del lado del servidor terminas usando.

¡Espero que esto ayude!

PHP está muriendo, Java está muriendo, C # está muriendo, SQL está muriendo, Javascript está muriendo, C está muriendo. Y sin embargo, cada uno de estos tiene probablemente más proyectos en curso que todos los demás combinados. Sí, las cosas que han sido suplantadas por otras cosas tienden a desvanecerse lentamente, pero es un desvanecimiento muy lento y no significa que sean malas.

(Editar: muchas personas parecen estar leyendo el primer párrafo y se están perdiendo completamente el punto, así que lo diré muy explícitamente. Hablar sobre la muerte de un lenguaje de programación no tiene sentido. Ahora volvamos a la parte interesante de la pregunta).

A continuación, ¿estamos asumiendo que PHP fue la mejor opción para crear Facebook? Yo diría que no fue así. Era tanto que no, * realmente * no usan PHP actualmente, sino que tienen un dialecto personalizado llamado Hack. PHP era simplemente el lenguaje en el que Zuck y los otros ingenieros iniciales eran productivos en ese momento.

Dicho esto, PHP tampoco fue una elección terrible. PHP tiene una gran comunidad que realmente enfatiza el desarrollo rápido de aplicaciones. ¡Esa es la clave para una startup y se demostró! Además, dado que PHP originalmente era solo una colección aproximada de scripts, hace que sea razonablemente fácil desplegarse a un nivel más bajo de abstracción y código en C cuando realmente necesita optimizar. Esto también terminó siendo súper importante. Pero, de nuevo, estas son todas las lecciones que los idiomas modernos han aprendido y han estado incorporando.

Finalmente, olvide la noción de que las redes sociales requieren algo especial de un lenguaje de programación. La mayor parte del código será muy sencillo. Sí, hay algunas áreas complejas, como la posible coincidencia de amigos, pero es probable que esté resolviendo aquellas con software dedicado, como bases de datos de gráficos. Sí, necesitarás diseñar cuidadosamente tu sistema (software y hardware) y ser increíble en devops, pero tendrás que hacerlo en cualquier idioma. Lo que necesitará mucho más que el lenguaje más brillante es ingenieros buenos y experimentados.

Lo que me lleva al quid de la cuestión. El gran atractivo de PHP es que mucha gente ya lo sabe. Probablemente no quieras a ninguna de esas personas en tu startup. Desea personas que sepan muchos idiomas, que tengan opiniones sólidas y bien fundadas. Estas personas, con muchas, muchas excepciones, tienden a no preferir PHP.

Asi que. Estoy sentado en la sala de juntas de mi nueva empresa recién incorporada, mirando la mesa repleta de dinero en efectivo y me pregunto en qué lenguaje de programación basaré mi stack. Comienzo entendiendo que esto es como el número 250 en la lista de cosas que determinarán mi éxito o fracaso, y que realmente debería ser una decisión del equipo.

¿Pero cuál es la diversión en eso? Así que analizo mis opciones para un lenguaje que tenga una comunidad sólida, uno con excelentes primitivas de concurrencia, uno que permita a los desarrolladores bajar a un nivel inferior de abstracción con facilidad, y lo más importante, uno que los mejores ingenieros que conozco quieran trabajar con.

Por el momento, ese idioma es el elixir. Está basado en Beam VM y es primo cercano de Erlang, que ha demostrado su valía durante docenas de años en sistemas increíbles. Igual de importante, ha capturado una gran parte de las comunidades más exuberantes de Ruby y Node. Esto significa que el ecosistema, que ya era bastante decente, se está llenando rápidamente. Además, sus puntos de referencia son solo plátanos. Sí, hasta cierto punto todos los puntos de referencia no tienen sentido, pero lo que Phoenix está haciendo realmente no puede ser ignorado.

Otra buena opción sería ir. Toneladas de los ingenieros realmente buenos son jefes C de la vieja escuela y no puedo pensar en una sola que no prefiera Go. Principalmente un lenguaje de bajo nivel, que puede hacer la mayoría de las cosas de alto nivel y prioriza la concurrencia. ¡No me gustan algunas de las decisiones de diseño, sino altas calificaciones!

¿Qué tal Clojure? Otra gran elección. Tal vez sea un poco más difícil encontrar desarrolladores entusiasmados, pero como descendiente directo de LISP, tiende a ser increíblemente poderoso y expresivo, y las personas que lo usan tienden a ser muy, muy buenas .

Algunas menciones notables

  • F # en el marco .Net o incluso su siempre presente yo también, C #. Solo si vas con este último, prepárate para examinar muchos currículums más hasta que encuentres The One.
  • Scala hace algunas cosas impresionantes. No he estado demasiado loco por eso, ya que parece un F # más tranquilo, pero la JVM tampoco es lo mío.
  • Nodo. Tengo que mencionar a Node. Personalmente, creo que estamos entre 6 y 12 meses después de Peak Javascript, pero Node estará presente por mucho tiempo, tiene mucha energía detrás y, aunque es el favorito absoluto de pocas personas experimentadas, todavía es bastante alto en la mayoría liza.

Pero también … no importa tanto.

Es hora de que PHP muera. Y digo esto como un desarrollador de PHP duro que actualmente convierte una base de código existente de Ruby on Rails a PHP.

La historia se repite

La razón por la que sé que PHP tiene que morir es porque he visto esto antes. Hace aproximadamente una década, PHP mató a Perl. No completamente, por supuesto; todavía se aferra en algunos entornos, tiene una legión considerable de fanáticos acérrimos, y las aplicaciones heredadas deberán mantenerse en las próximas décadas. Pero como lenguaje para los recién llegados, y especialmente para los desarrolladores web, ya estaba muriendo en 1999 y en su mayoría estaba muerto en algún momento alrededor de 2005.

Como recién llegado al desarrollo web en ese momento, estaba claro tanto que esto sucedería como por qué: Perl no era adecuado para el nuevo entorno de aplicaciones. Las páginas de tedious boilerplate CGI fueron necesarias en Perl para lograr el comportamiento básico predeterminado de PHP. El lenguaje estaba lleno de características anacrónicas: punteros ( actualización: lo siento, referencias ), estructuras hash inconvenientes y una docena de otras pequeñas peculiaridades del lenguaje, que hacían que el desarrollo web fuera tedioso, inseguro o inconveniente. No había razón para que no pudieras escribir una aplicación web perfecta en Perl, pero en PHP lo harías más rápido y más fácil, a pesar de las fallas en PHP en sí que, incluso entonces, ya eran obvias.

Los argumentos a favor de Perl sobre PHP en 1999 eran muchos: era mucho más rápido, tenía muchas más bibliotecas y soporte de controladores, y CPAN era un país de las maravillas de código preescrito que le proporcionaría el 80% del camino en casi cualquier tarea. Suena divertido decirlo ahora, pero “PHP no escala” era en realidad un argumento en aquel entonces. Pero PHP ganó de todos modos, porque esas cosas no son ventajas intrínsecas para el lenguaje. Los intérpretes pueden ser más rápidos, las bibliotecas siempre se escriben, y PEAR y PECL son gigantes en estos días *, sin tener en cuenta las innumerables bibliotecas menos formales disponibles de cada proveedor que quiere que las personas usen sus API. PHP es el lenguaje estándar de facto del desarrollo web.

Tiempo de seguir adelante

Diez años después, puedo sentir que la marea cambia de nuevo. Las expectativas de los desarrolladores sobre los idiomas han avanzado. Si lo crítico que le faltaba a Perl eran las “matrices asociativas” maravillosamente flexibles de PHP (también conocidas como hashes inteligentes), entonces lo que falta de PHP es lambdas y encadenamiento de métodos. Si bien PHP solía ser el lenguaje en el que podía escribir una página web en veinte líneas de código, hoy en día no parece que lo esté haciendo correctamente a menos que haya establecido al menos un marco MVC básico de algún tipo. Ese código repetitivo es el que dice: el lenguaje ahora requiere modificación por un marco para hacer lo que necesita.

En aquel entonces, sentí que las dificultades que se aferraban a Perl para el desarrollo web eran tontas. Ahora, con diez años de experiencia en PHP en mi haber, estoy en la misma posición. Puedo eliminar un buen sitio web en una hora en PHP, y uno excelente en uno o dos días. Sus características de rendimiento son bien conocidas y entendidas, por lo que puedo hacer que se escale casi indefinidamente. Todos los desarrolladores que queremos contratar lo saben, y cada sistema con el que nos integraríamos tiene una biblioteca de contenedor escrita. Estoy atrapado por la conveniencia de PHP en un lenguaje que está perdiendo su idoneidad para la tarea.

Adelante Ruby on Rails

El sucesor potencial más obvio de PHP es Ruby on Rails **. Ruby es un lenguaje más nuevo y limpio, con características modernas y una sintaxis elegante y dispersa (como Python). Rails elimina las tareas comunes y las repeticiones de una aplicación web de primera calidad y convierte lo que son expresiones idiomáticas de tres o cuatro líneas en PHP en construcciones de lenguaje de primera clase. Esto suena exactamente como lo que necesito para reemplazar PHP y acelerar mi desarrollo una vez más.

Pero a los siete meses de usar Rails todos los días, pirateando una aplicación Rails construida por expertos experimentados en Rails que aman el marco y el lenguaje, simplemente no puedo decir que sea la elección correcta, por razones que encuentro difíciles de precisar. El propósito de este ensayo es intentar descubrirlos.

Mi principal queja, hay que decirlo, es el rendimiento. Acabo de terminar de decir que esto no debe considerarse un defecto fatal en un idioma, sino más bien un problema temporal en su implementación. Por lo tanto, no puedo tomarlo como argumento, aunque debo tener en cuenta que el rendimiento es la razón principal por la que estoy transfiriendo mi aplicación actual a PHP. Puedo hacer que Rails se ejecute tan rápido como PHP, pero necesito entre 2 y 4 veces más hardware para hacerlo. En cinco años, es poco probable que esto sea cierto, y en cinco años tal vez no me cambiaría a PHP. Pero en este momento, no es suficiente.

En segundo lugar, odio el registro activo. Active Record es un patrón, no intrínseco a Ruby, y opcional en versiones recientes de Rails, pero su uso y sus patrones están profundamente en el ADN de Rails. Anteriormente he explicado por qué creo que ORM en RDBMS es una mala idea, por lo que no me repetiré, excepto para resumir que la ganancia de eficiencia de no tener que escribir CRUD es más que compensada por la eficiencia perdida por ActiveRecord haciendo cosas tontas y pasar tiempo resolviendo cuáles son y flexionando las reglas del marco para evitar que lo haga.

En tercer lugar, sospecho profundamente de la generación de código. El código que escribe su repetitivo para usted es útil y todo, pero si su idioma requiere un montón de repetitivo para hacer algo, entonces algo ya está mal. La generación de código fomenta el “pensamiento mágico”, donde el codificador no está seguro de si una característica conveniente en particular proviene del código escrito para ellos o intrínsecamente como parte del entorno del lenguaje. El pensamiento mágico es peligroso.

La generación de código me lleva a lo que probablemente sea el problema fundamental con Ruby on Rails, que es que no es un lenguaje. Ruby es el idioma. Y Ruby, si bien resuelve algunos de los problemas fundamentales de PHP, no resuelve el problema central, que es que las aplicaciones web modernas tienen un conjunto elevado de expectativas: características como enrutamiento, separación de modelo / vista y funcionalidad directa ahora son parte del curso. . Rails agrega estos, pero es el mismo vendaje que los marcos MVC como Zend, Symfony y Code Igniter agregan a PHP.

Entonces, ¿qué falta?

El lenguaje que toma las riendas de PHP tiene que ser mucho mejor que PHP como PHP era mejor que Perl. Tiene que hacer suposiciones sobre la forma principal de las aplicaciones web de la misma manera que PHP asumió que la función principal de su código siempre iba a escupir una página web, una suposición radical que hace que sea un poco incómodo hacer otras cosas, como shell guiones. Quiero un lenguaje que asuma que todo lo que voy a construir es una aplicación web MVC, y lo incorpora al lenguaje central, no solo a una biblioteca.

El problema es que no existe tal lenguaje. Durante un tiempo parecía que quizás JavaScript del lado del servidor sería la próxima gran cosa, unificando el lenguaje en el front-end y el back-end de las aplicaciones web. Pero las grandes mentes de JavaScript se han alejado de la tangente que es node.js: el patrón creado es una forma radical y poderosa de crear aplicaciones de alto rendimiento que aprovechen al máximo el hardware moderno, pero es una forma de hacer que el servidor aplicaciones secundarias, no páginas web. Y todavía hay muchas páginas web que deben escribirse. Otros esfuerzos de CommonJS como ejScript comienzan a intentar reemplazar PHP pero no resuelven el problema del marco.

Todavía esperando

Me veo obligado a concluir que el reemplazo de PHP simplemente no está aquí todavía. Ruby on Rails es bueno, pero no mucho mejor que un marco MVC similar en la parte superior de PHP, y ciertamente no lo suficientemente mejor como para justificar el impacto en el rendimiento provocado por el doble golpe de ineficiencia del propio Ruby y las travesuras de ORM de ActiveRecord. Python parece no estar interesado en ser el próximo lenguaje web, y la revolución del servidor de JavaScript apenas está comenzando.

Espero la próxima gran cosa. Quiero alejarme de PHP, de verdad. No quiero ser el dinosaurio Perl. Pero sea lo que sea, no parece estar aquí todavía. ¿Me equivoco?

* Otra ventaja que creo que contribuyó al éxito de PHP fue su increíble documentación, que era completa, precisa y llena de código de ejemplo del mundo real. Muchas de las primeras aplicaciones PHP, incluida la mía, se escribieron simplemente navegando por la documentación y pegando los fragmentos relevantes. Sin embargo, esto no es una ventaja intrínseca de PHP, así que lo voy a dejar fuera de consideración. Una ventaja final fue que PHP funciona bien y se instala fácilmente en Windows; El 95% de todas las computadoras en la Tierra aún ejecutan Windows, por lo que su idioma debe ejecutarse allí si espera una adopción generalizada por parte de desarrolladores adolescentes novatos que no pueden elegir su propio hardware.

Hay demasiadas alternativas en este momento. Python y Ruby on Rails son los mayores retadores. Pero antes que nada, incluso debería preguntarse cuánto tiempo la gente continuará haciendo solo desarrollo web estándar.

El mercado para el desarrollo móvil está aumentando mucho y las aplicaciones móviles a menudo se basan en servicios web, no en sitios web. PHP puede hacer servicios web, pero generalmente está haciendo un mal trabajo. (Solo utilizable por PHP). Esto significa que el front-end para sitios web será más importante y, por lo tanto, JavaScript será el número uno. Una vez que Web Assembly se convierta en un estándar, probablemente reemplazará a JavaScript.

Así que espero que los sitios web básicamente alojen páginas web simples, posiblemente incluso páginas HTML estáticas, con mucho JavaScript para hacer que las páginas sean más dinámicas, llamando a los servicios web para administrar el contenido y hacer la mayor parte de la lógica de la GUI. Reduciría la necesidad del desarrollo de back-end en sitios web.

(Por cierto, el back-end es solo una parte de la capa de presentación. El servicio web es básicamente una interfaz de comunicación con la capa de negocios).

Esto significaría que los sitios podrían cambiar a JavaScript simple que está llamando a todo tipo de servicios web.

Dado que los servicios web manejan la lógica empresarial, generalmente están escritos en lenguajes compilados para que puedan formar parte de diferentes proyectos. Por lo tanto, C #, Java y C ++ serían buenas opciones para los servicios web, con una capa delgada alrededor de ellos para la interfaz del servicio web.

Tendría que responder esta pregunta con algunas de las mías.

Primero, ¿por qué el idioma de reemplazo necesariamente debe ser nuevo? Common Lisp, Scheme y Smalltalk en particular son lenguajes interesantes que tienen mucho potencial sin explotar, incluso para la programación web. No veo ninguna razón por la cual estos lenguajes deberían descartarse simplemente porque son “viejos”. (Sin embargo, si deben descartarse por otras razones, sería un buen generador para el debate y / o lamento y / o lamento sobre la utilidad de dichos lenguajes para la programación web, o para cualquier otra cosa, y para cualquier otra cosa) algunas de las críticas más duras vendrán de personas que desesperadamente * quieren * usar estos idiomas).

Segundo, ¿qué pasa con esta “la” en la pregunta? ¿Por qué todos los que desean abandonar PHP tienen que usar un solo lenguaje? Además de los enumerados, también hay Python, Ruby, Go y Clojure para aquellos que desean usarlos, C # y Java para los masoquistas entre nosotros, Forth, Prolog y J para los particularmente locos, y F #, Haskell, Scala y Erlang para los matemáticos. Incluso hay JavaScript y Node.js para aquellos que desean tomar el camino más loco de menor resistencia (¡porque está ahí!). ¿Quién sabe? ¡Incluso puede haber dos o tres buenos reemplazos para PHP que aún no se han desarrollado!

En general, sin embargo, no creo que pueda responder completamente esta pregunta por usted. Si está comenzando un nuevo proyecto, le recomendaría que responda dos preguntas usted mismo: ¿Qué desea lograr? ¿Y qué idiomas le gusta usar * a usted * para lo que desea lograr?

Sin embargo, tendría que enfatizar que estas preguntas deben hacerse cuando un proyecto es * nuevo *, porque es un gran desafío convertir una base de código grande a otro idioma; suficiente para que cuando preguntes “¿Qué lenguaje deberíamos usar para este proyecto?”, la respuesta suele ser “¡Cualquiera sea el idioma en el que esté escrito este proyecto!”, razón por la cual no son tan abominaciones tales como PHP, C ++, Perl e incluso COBOL desaparecerá pronto …

Durante años, respondí esta pregunta, “¡PHP no está muriendo!” Y es cierto que PHP todavía se usa en una gran cantidad de sitios web.

Pero Python ha aumentado su popularidad de manera constante en los últimos 10 años, y en 2015 pasó a PHP.

Fuente: Índice de Popularidad de Lenguaje de Programación PYPL

Dicho esto, la popularidad no es la mejor razón para elegir un idioma para cualquier proyecto. Elija un idioma en función de cuán productivos lo estén utilizando usted y su equipo.

He publicado muchas veces antes, y sigo diciendo que, como cualquier opción tecnológica, el lenguaje de programación no tiene nada que ver con el rendimiento o la escalabilidad de un proyecto de software. Hay muchos ejemplos de sitios web a gran escala escritos en cualquiera de los idiomas en el cuadro anterior.

¡¡¿Qué?!! ¿Cómo puede un sitio web ser exitoso y escalable eligiendo el lenguaje “incorrecto”?

La respuesta es: la arquitectura triunfa sobre la tecnología. Es la forma en que su software maneja las solicitudes y los datos lo que determina la escalabilidad, no el idioma que usa.

La elección del idioma es importante para hacer el trabajo. El éxito de una empresa de software de inicio tiene que ver con la velocidad con la que desarrolla el software , no con la velocidad que ejecuta el software. Tiene un número limitado de meses de ingeniero para llevar su proyecto a un estado de trabajo y poder comenzar a manejar usuarios y solicitudes. Luego continuará mejorando el sitio, que también requiere un desarrollo rápido y una revisión rápida.

Por lo tanto, elija el idioma en función de cuán productivo sea con él, no por ningún otro motivo.

He estado desarrollando aplicaciones web en PHP durante años, pero recientemente he estado construyendo más aplicaciones para iOS. Cuando vuelvo al desarrollo web, realmente extraño la elegancia de Objective-C y su estructura MVC. Pude encontrar una estructura similar para mi JavaScript del lado del cliente, pero mi código del lado del servidor se dejó en los límites de mi zona de confort y PHP. Lo mejor de PHP es su ubicuidad y su baja barrera de entrada. Puede poner en funcionamiento una aplicación web en muy poco tiempo, sin embargo, el código en sí puede convertirse rápidamente en una montaña de código de espagueti. Después de casi todos los trabajos que hago usando PHP, me digo que es hora de comenzar a trabajar de manera más inteligente. Luego comenzaré a investigar nuevos marcos para PHP y pensaré en saltar completamente a una nueva pila que use Java, Ruby o Python. Comenzaré a jugar con el nuevo enfoque y desarrollaré aplicaciones simples. Sin embargo, lo que inevitablemente sucede es que entra un nuevo trabajo y recurro a mi conocimiento de dominio de PHP. Esto se debe en parte a mí, pero al mismo tiempo es el problema de la plataforma que estoy tratando de aprender. He encontrado los puntos de entrada para hacer aplicaciones sólidas que usan otros lenguajes mucho más altos que con PHP. Esto es en parte por qué PHP es un monstruo en la industria y por qué Rails y Django generalmente son relegados a los puristas.

Además de todas las alternativas populares a PHP, hay un chico relativamente nuevo en el bloque llamado Node.js. Cuando comencé a jugar con Node hace unos años, fue refrescante confiar en el conocimiento de JavaScript que tenía para crear el código del lado del servidor. Sin embargo, Node nunca pareció ser un competidor realista de los grandes idiomas a la hora de escribir un código completo del lado del servidor; fue solo para nuevos y no probados.

Recientemente eché otro vistazo al uso de Node como mi idioma principal del lado del servidor y me impresionó su progreso y comunidad. Ha madurado lo suficiente como para ser utilizado como una herramienta esencial para cualquier desarrollador web, pero especialmente para desarrolladores de interfaz de usuario / front-end. Era hora de profundizar en Node nuevamente y ver si me separaría de PHP de una vez por todas.

Nodo 101

Poner Node en funcionamiento en mi MacBook fue tan simple como podrías esperar. Así es como se ve la instalación de OSX:

// Instala homebrew y luego Node
ruby -e “$ (curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install )”
preparar el nodo de instalación

Después de eso, estás listo para ejecutar el código JavaScript en tu servidor. La aplicación Node ‘Hello World’ muestra la estructura básica del código y al mismo tiempo ilustra que es un servidor web muy capaz. Con solo 2 líneas en la terminal, tendrá todo el poder de JavaScript a su disposición y un servidor web para arrancar. Pruébelo, abra un editor de texto e ingrese este código:

var http = require (‘http’);
http.createServer (función (req, res) {
res.writeHead (200, {‘Content-Type’: ‘text / plain’});
res.end (‘Hola Mundo \ n’);
}). escuchar (1337, ‘127.0.0.1’);
console.log (‘Servidor que se ejecuta en http://127.0.0.1:1337/&#039 ;);

Guarde su archivo como app.js y desde la terminal ejecute:

nodo app.js

Cargue su navegador y vaya a http: // localhost: 1337 y ¡listo!

Esto te lleva a donde podrías preguntar, “ok, ¿y ahora qué?”. Al menos eso fue lo que hice la primera vez que le di un crack. No sabía ni entendía cómo aplicar ninguno de mis conocimientos existentes sobre cómo construir una aplicación web adecuada a partir de este ejemplo.

NPM

El nodo se vuelve realmente poderoso cuando comienzas a agregarle. El Node Package Manager * o NPM se incluye con la instalación de Node. La comunidad ha creado algunas aplicaciones, herramientas, marcos y middleware invaluables para ayudar a los desarrolladores de UI a centrarse en las tareas clave que tenemos entre manos; haciendo grandes experiencias de usuario. Si tiene experiencia con el compositor cuando construye sus aplicaciones web PHP, entonces usar NPM no será un gran alcance para usted. Hay algunos sitios geniales para ayudar a comprender los entresijos de NPM, así que solo mencionaré un par de cosas clave. NPM utiliza un archivo llamado package.json para delinear los metadatos de su aplicación y, lo más importante, las dependencias del software de su aplicación web. Puede editar este archivo manualmente y completar las dependencias por su cuenta, tal como lo haría con el archivo composer.json del compositor. También puede instalar paquetes desde la línea de comandos de esta manera:

npm install –save

Normalmente agrego la opción ‘- guardar’ para que el paquete se agregue a la lista de dependencias en mi archivo package.json.

Más allá de su aplicación web, NPM alberga algunas aplicaciones del servidor realmente geniales que querrá usar para facilitarle la vida. Puede instalar paquetes dentro de su directorio de aplicaciones local o puede elegir instalar paquetes globalmente en su sistema. Instalarlos globalmente le dará acceso al paquete desde la línea de comando (deberá agregar la carpeta bin NPM a la RUTA de su terminal). Instalar un paquete globalmente se ve así:

npm install -g

Después de aprender a administrar paquetes, hay algunos esenciales que querrás instalar antes de mojarte los pies con Node.

Construcción y portabilidad de sitios web

No he estado jugando con Node durante demasiado tiempo, pero he encontrado algunas cosas esenciales para que me mueva en la dirección correcta. Aquí hay una selección de los que encontré más útiles.

Exprimir

Quizás el componente más importante para crear aplicaciones web exitosas en Node es Express. Es un paquete de middleware que se basa en los fundamentos de Node al agregar algunas estructuras importantes para crear aplicaciones web con él. El nodo mismo delega gran parte de la responsabilidad del servidor web al programador. Express se basa en un paquete de middleware llamado Connect que llena este vacío para que los desarrolladores no tengan que preocuparse por los pequeños detalles de análisis de entrada y publicación de páginas. Además de eso, Express proporciona un marco muy agradable para que un desarrollador siga y cree un código rico y sostenible. Express se ha convertido en el estándar de facto para crear aplicaciones web en Node. No construiré una aplicación web sin ella. Hay una guía fantástica en el marco de la aplicación web Node.js para comenzar: http://expressjs.com/guide.html

Nota: Me informaron que el equipo Express está construyendo un nuevo marco llamado KoaJS. Definitivamente vale la pena echarle un vistazo: http://koajs.com/ ¡ Gracias @jeswin!

En la página de inicio de Express también hay un enlace a un libro muy útil. Le guiará a través de una descripción muy detallada de Node y se desarrollará para crear aplicaciones web con Express. Me pareció muy útil para comprender los principios básicos de Node antes de saltar a Express. Echa un vistazo: http://www.manning.com/cantelon/

Nodemon

Ejecutar y probar una aplicación Node es muy diferente a construir una en PHP. Por lo general, con PHP se piratea algún código y luego se dirige al navegador y se actualiza. Es posible que de vez en cuando necesite modificar la configuración de Apache y reiniciar el servidor web. El proceso en Node es bastante diferente. Dado que el servidor web y la aplicación están agrupados en un pequeño paquete, cambiar el código significaba tener que reiniciar toda la aplicación web; lo que también significaba reiniciar el servidor web. Cuando estaba aprendiendo cómo construir los conceptos básicos, parecía que había una cantidad interminable de matar el proceso, presionando la flecha hacia arriba para ir a mi último comando y luego presionando enter para reiniciar la aplicación ([Ctrl + C] [Arriba] [Entrar ] ciclo). Esto rápidamente se convirtió en un dolor gigante en el culo. Para que las personas hicieran un trabajo significativo en Node, esto tenía que mejorar. Afortunadamente, aquí es donde Nodemon viene al rescate. Instale Nodemon usando NPM globalmente y en lugar de iniciar su aplicación usando:

nodo app.js

nosotros lo siguiente:

nodemon app.js

Esta aplicación controlará los cambios en el código y reiniciará automáticamente Node por usted. Muy sencillo y muy esencial. Echa un vistazo al repositorio de git para obtener más detalles: https://github.com/remy/nodemon

Trago

Cuando construí aplicaciones web PHP, mi motor de plantillas elegido fue Twig de la buena gente de SensioLabs. Fue un componente del marco de Symfony y facilitó la creación de HTML front-end. Twig era una herramienta esencial para mí y si iba a portar cualquiera de mis proyectos existentes a Node, tenía que reutilizar las plantillas de vista que ya tenía. Swig hizo esta transición increíblemente simple. Casi todas las partes de Twig que utilicé estaban disponibles en Swig. Tuve que hacer un par de modificaciones menores al código de la plantilla, pero en general estaba listo para usar. Es completamente compatible con Express y tiene una guía muy útil para comenzar aquí: http://paularmstrong.github.io/s… .

Hay un puerto directo de Twig to Node pero desafortunadamente ese proyecto se ha estancado. Swig se actualiza muy activamente, así que opté por usarlo en el futuro.

Nota: Supongo que otros pueden encontrar esto útil dado que Twig es uno de los motores de plantillas más populares en PHP. Más allá de Swig, hay numerosos motores de plantillas disponibles para Node. Todos los populares tienen la misma o similar funcionalidad; se trata solo de diferencias de sintaxis en su mayor parte.

MySQL para el nodo

Cuando lees sobre Node, la mayoría de las veces está emparejado con bases de datos de tipo NoSQL como MongoDB. En el futuro, lo más probable es que use Mongo simplemente debido al increíble middleware Mongoose. Hace que la gestión de modelos dentro de las aplicaciones web sea increíblemente sencilla. Sin embargo, dado que tengo algunos proyectos heredados para administrar y transferir, quiero mantener todo lo que pueda. Esto significaba mantener mis esquemas y datos MySQL existentes en su lugar. Hay algunos paquetes MySQL disponibles, pero encontré el de felixge increíblemente completo. Eche un vistazo aquí para obtener más información y uso: https://github.com/felixge/node-

Pasaporte JS

En la actualidad, casi todas las aplicaciones web tienen algún tipo de conectividad con API de terceros. La autenticación con estos servicios tiene sus desafíos. Afortunadamente, hay numerosos paquetes disponibles en PHP para facilitar el acceso a estas API. Con Node realmente solo necesita preocuparse por PassportJS. Es un paquete compatible con Express que le permite autenticarse en casi cualquier lugar de la web. Incluso puede usarlo para autenticar su propio inicio de sesión local y administrar sesiones si es necesario. Encontré esta herramienta invaluable al autenticar con otros servicios como Twitter, Instagram y Facebook. Desde el wiki del software, dice que puede autenticarse con 140 servicios diferentes. A debe tener para cualquier desarrollador de aplicaciones web. Echa un vistazo a los detalles aquí: http://passportjs.org/guide/


Arrancando los motores

Después de comprender los fundamentos del Nodo y familiarizarme con la nueva pila, estaba listo para saltar y comenzar a crear aplicaciones. Me llevó alrededor de un día leer el libro NodeJS in Action y analizar algunos ejemplos con Express. Con una comprensión básica de cómo funcionaba la mecánica, la siguiente tarea fue hacer que uno de mis viejos proyectos fuera transferido. Para un sitio multilingüe de tamaño pequeño a mediano, el proceso de migración tardó entre 2 y 3 días. La velocidad a la que porto sitios sin duda aumentaría a medida que me familiarice con el proceso y las estructuras de Node y Express. Aquí hay un par de cosas que son notas dignas para otros que se mudan de PHP.

Sincrónico vs Asincrónico

Uno de los cambios más importantes que tuve que entender fue convertir mi código PHP sincrónico en código JavaScript asincrónico. Dado que Node se basa en un sistema de bucle de eventos sin bloqueo de subproceso único, cualquier acción que realice no esperará a que regrese una acción de bloqueo antes de ejecutar la siguiente línea de código. Todas las líneas de código se ejecutan inmediatamente una tras otra. La idea de que los datos solicitados estarán disponibles en la siguiente línea de código no es una garantía. Aquí es donde su experiencia de JavaScript front-end le ayudará. Al igual que el lado del cliente, los eventos se manejan mediante funciones de devolución de llamada y lo mismo ocurre con el código Javascript en el servidor. Para crear código síncrono usando JavaScript, deberá anidar su secuencia de eventos en devoluciones de llamada. Aquí hay un ejemplo:

// PHP
$ sql1 = “SELECCIONAR ID_usuario DE usuarios DONDE correo electrónico =?”;
$ stmt = DB () -> preparar ($ sql);
$ stmt-> execute (array ($ correo electrónico));
$ sql2 = “SELECCIONAR photo_id DE las fotos DONDE user_id =?”;
$ stmt = DB () -> preparar ($ sql);
$ stmt-> execute (array ($ user_id));

Justo lo que esperarías. PHP ejecutará y esperará un resultado de la primera consulta y luego usará los datos recibidos en la segunda. En Node, tendría que anidar las consultas a través de las devoluciones de llamada de finalización de la siguiente manera:

var sql1 = “SELECCIONE user_id DESDE usuarios WHERE email =?”;

connection.query (sql1, [correo electrónico], función (err, filas)
{

var sql2 = “SELECCIONAR photo_id DESDE fotos DONDE user_id =?”;

connection.query (sql2, [filas [0] .user_id], función (err, filas)
{
console.log (filas); // saca todas las fotos
}

}

Puede pensar que este tipo de código crecerá para ser absolutamente difícil de manejar cuando tenga mucho código síncrono para ejecutar, y tiene razón. El uso de promesas resuelve este problema de “Pirámide de la fatalidad”. No haré promesas en este artículo, pero hay un gran paquete para Node llamado Q y le da una idea de cómo las promesas lo solucionarán. Echa un vistazo aquí: http://documentup.com/kriskowal/q/

Los bichos son realmente malos

Dado que Node es un sistema de subproceso único, es importante tener en cuenta que cuando su código tenga una excepción no detectada, se desactivará Node para todos, no solo para la persona que causó el bloqueo. Esto es diferente de PHP y Apache / Nginx porque el hilo que manejó la solicitud muere, no todo el proceso del servidor web. En un entorno de desarrollo, esto está totalmente bien y probablemente lo aliente para que pueda detectar y solucionar los problemas correctamente. Sin embargo, en el entorno de producción, esto puede ser muy perjudicial ya que su aplicación web será eliminada para todos los usuarios que visiten su sitio. La solución a esto es crear un oyente para todas las excepciones no detectadas y manejarlas con gracia (vea la nota a continuación) . El código se ve así:

process.on (‘uncaughtException’, function (err) {
console.log (‘Excepción capturada:’ + err);
});

Esto asegurará que su aplicación se mantenga activa incluso cuando ocurra lo inesperado.

Nota: He leído un poco más sobre este problema y parece que manejar excepciones no detectadas de esta manera no es lo ideal. El uso de dominios parece ser la mejor solución. Lea sobre esto en los documentos de Node API . Otra opción sería utilizar una herramienta como siempre para iniciar la aplicación. Reiniciará automáticamente el servidor cuando ocurra lo inesperado.

Reescribir reglas

Una de las partes poderosas del desarrollo de aplicaciones web es la capacidad de reescribir URL desordenadas en otras agradables y limpias. Esto hace felices a los motores de búsqueda y hace que sus usuarios sean aún más felices. Con PHP no le importaba cómo se veían las URL, solo quería que la entrada funcionara. La reescritura de las URL fue administrada por Apache (o Nginx). Al usar Node para crear aplicaciones web, el mapeo de rutas de Express es la salsa especial para dirigir las solicitudes. Encontré que administrar rutas a través del código de mi aplicación del lado del servidor es un cambio muy bienvenido. Después de sentirse cómodo con esta idea, nunca más querrá escribir otra regla de enrutamiento a través de su entrada . Aquí hay un pequeño ejemplo:

RewriteRule ^ / blog / ([A-Za-z -] +) $ /blog/entry.php?slug=$1

Usando el mapeo de rutas de Express:

app.get (‘/ blog /: slug ([A-Za-z -] +)’, blogController.entry);

No más vueltas a administrar la asignación de rutas de solicitud entre tu servidor web y el código de tu aplicación web. .

Ejecución de múltiples sitios de nodo en un servidor *

Dado que Node es tanto un procesador de código como un servidor web integrado en uno, presenta un desafío cuando se ejecutan múltiples sitios en un solo entorno. La ejecución de un servidor web Node requiere que seleccione un puerto para ejecutar las solicitudes. Una vez que ejecuta un sitio en el puerto 80, no puede asignar un segundo sitio al mismo puerto. Uno podría simplemente decirle que obtenga un nuevo VPS para cada sitio web dado que son tan asequibles en estos días, sin embargo, en muchos casos, un solo VPS es una exageración total para un sitio. En estos casos, puede elegir ejecutar un servidor web estándar como Apache o Nginx y pasar las solicitudes a Node a través de proxy. Opté por proxy usando las reescrituras de Apache porque las uso muy a menudo. Así es como se ve una entrada de ejemplo :


ServerName Ejemplo de dominio
ServerAlias ​​another-example.com
DocumentRoot / my / folder /

RewriteEngine On
RewriteRule ^ (/.*) $ http: //% {HTTP_HOST}: 1337 $ 1 [P]

Para Nginx se vería algo así:

servidor {
escucha 80;

nombre_servidor http://your-domain.com ;

ubicación / {
proxy_pass http: // localhost : {YOUR_PORT};
proxy_http_version 1.1;
proxy_set_header Upgrade $ http_upgrade;
proxy_set_header Conexión ‘actualizar’;
proxy_set_header Host $ host;
proxy_cache_bypass $ http_upgrade;
}
}

También puede elegir un enfoque de JavaScript puro utilizando el paquete Node-Http-Proxy. Usa lo que tiene sentido para ti.

* Nota: He estado recibiendo muchos comentarios sobre este tema y la mayoría dice que usar Nginx no es un cuello de botella tan grande como lo imaginé originalmente y de alguna manera usarlo como proxy ayudará más que eso ‘ lo obstaculizaré. Se suponía que mi punto era tratar de ejecutar múltiples instancias de nodos en el mismo entorno, por lo que reescribí este punto para que sea más útil. Dejaré el debate sobre el rendimiento para la comunidad, ya que no he probado mucho en un entorno de producción ocupado. Thx Reddit!

Busca y encontrarás

Una de las partes más emocionantes de la programación con Node es la comunidad que lo rodea. Están sucediendo tantas cosas en el espacio y está sucediendo muy rápidamente. Cuando estaba portando mi primer sitio, me encontraba con un problema y preguntaba “¿Cómo hago esto en Node?” Simplemente buscaba en Google cualquiera que fuera mi problema y, en cuestión de segundos, tendría respuestas. Nunca me encontré con un problema decisivo que no era fácil de resolver con Node. Es un testimonio del progreso realizado. Si tienes un problema, solo búscalo en Google, sin duda alguien tiene una solución.

Envolver

Después de pasar unos 3-4 días con Node y sus contrapartes, me quedé completamente impresionado con lo fácil que era ponerse en marcha y lo más importante, lo fácil que era ponerse a trabajar haciendo cosas. La barrera de entrada para desarrollar aplicaciones web usando Node todavía no es tan baja como PHP, ¡pero está bastante cerca! Incluso diciendo eso, el valor que obtienes al comprender los administradores de paquetes y los marcos MVC son esenciales para ser un desarrollador web moderno. Esos dos conceptos son probablemente las únicas cosas que mantienen la barrera de entrada de Node + Express más alta que la de PHP. Node + Express te obliga a aprender estos conceptos antes de que puedas cocinar y eso es algo realmente bueno para un desarrollador y el código que escriben.

Finalmente, creo que es importante entender por qué escribir código del lado del servidor en JavaScript es algo tan bueno para un desarrollador web y específicamente para el desarrollador web UI / Front-end.

Control total

La mayoría de los desarrolladores web de IU ya tienen un conocimiento íntimo de JavaScript y sus matices. Aprovechar este conocimiento al preparar el código del lado del servidor aumenta la productividad. Además, mi experiencia me dice que los desarrolladores de lógica empresarial / back end suelen detestar el código UI para crear sitios web. Prefieren centrarse en la ingeniería de las funciones principales de la aplicación. La creación de aplicaciones con Node permite al desarrollador de la interfaz de usuario hacerse cargo de la parte de la aplicación del lado del servidor. La lógica de negocios se puede separar completamente de la interfaz de usuario y acceder a través de llamadas API. La separación del back-end del front-end permite a cada desarrollador elegir la pila con la que desea trabajar para hacer su trabajo.

Hay un gran artículo que detalla más la idea y no podría recomendarlo más: http://www.nczonline.net/blog/20

Dada esta experiencia reciente, me he comprometido a mover todos los proyectos futuros a Node (donde sea posible) y a comprometerme con una pila completa de JavaScript para el desarrollo de la interfaz de usuario. Ha sido un lenguaje esencial para crear experiencias de usuario increíbles y ahora se puede aprovechar por completo para crear un excelente código del lado del servidor también. Sinceramente, creo que se convertirá en el lenguaje dominante para construir código de aplicaciones web front-end en el futuro. Aplaudo y agradezco a la comunidad de desarrolladores que pusieron su arduo trabajo en crear estas increíbles herramientas para que personas como yo puedan usarlas para crear sitios web geniales.

Para convertirse en un experto en nodejs, consulte los siguientes cursos:

☞ Aprender y comprender NodeJS

☞ Aprenda Nodejs construyendo 12 proyectos

☞ Tutoriales de Node.js: Bootcamp para desarrolladores web

☞ Angular 2 y NodeJS: la guía práctica de MEAN Stack 2.0

☞ Completa el curso de desarrollador JS de Node Building 5 Real World Apps

☞ Tutoriales de JavaScript: Comprender las partes extrañas

El sucesor potencial más obvio de PHP es Ruby on Rails. Ruby es un lenguaje más nuevo y limpio, con características modernas y una sintaxis elegante y dispersa (como Python). Rails elimina las tareas comunes y las repeticiones de una aplicación web de primera calidad y convierte lo que son expresiones idiomáticas de tres o cuatro líneas en PHP en construcciones de lenguaje de primera clase. Esto suena exactamente como lo que necesito para reemplazar PHP y acelerar mi desarrollo una vez más.

Mi principal queja, hay que decirlo, es el rendimiento. Acabo de terminar de decir que esto no debe considerarse un defecto fatal en un idioma, sino más bien un problema temporal en su implementación. Por lo tanto, no puedo tomarlo como argumento, aunque debo tener en cuenta que el rendimiento es la razón principal por la que estoy transfiriendo mi aplicación actual a PHP. Puedo hacer que Rails se ejecute tan rápido como PHP, pero necesito entre 2 y 4 veces más hardware para hacerlo. En cinco años, es poco probable que esto sea cierto, y en cinco años tal vez no me cambiaría a PHP. Pero en este momento, no es suficiente.

En segundo lugar, odio el registro activo. Active Record es un patrón, no intrínseco a Ruby, y opcional en versiones recientes de Rails, pero su uso y sus patrones están profundamente en el ADN de Rails. Anteriormente he explicado por qué creo que ORM en RDBMS es una mala idea, por lo que no me repetiré, excepto para resumir que la ganancia de eficiencia de no tener que escribir CRUD es más que compensada por la eficiencia perdida por ActiveRecord haciendo cosas tontas y pasar tiempo resolviendo cuáles son y flexionando las reglas del marco para evitar que lo haga.

En tercer lugar, sospecho profundamente de la generación de código. El código que escribe su repetitivo para usted es útil y todo, pero si su idioma requiere un montón de repetitivo para hacer algo, entonces algo ya está mal. La generación de código fomenta el “pensamiento mágico”, donde el codificador no está seguro de si una característica conveniente en particular proviene del código escrito para ellos o intrínsecamente como parte del entorno del lenguaje. El pensamiento mágico es peligroso.

La generación de código me lleva a lo que probablemente sea el problema fundamental con Ruby on Rails, que es que no es un lenguaje. Ruby es el idioma. Y Ruby, si bien resuelve algunos de los problemas fundamentales de PHP, no resuelve el problema central, que es que las aplicaciones web modernas tienen un conjunto elevado de expectativas: características como enrutamiento, separación de modelo / vista y funcionalidad directa ahora son parte del curso. . Rails agrega estos, pero es el mismo vendaje que los marcos MVC como Zend, Symfony y Code Igniter agregan a PHP.

“PHP está muriendo” … No, no, no, no, no lo es. En realidad se está fortaleciendo, solo eche un vistazo a PHP7 y las comparaciones con PHP5.x, y observe su comunidad.

PHP tiene esto, Scala tiene eso, Go tiene esto, Node.js tiene la otra cosa, .NET tiene esto, el otro tiene eso … pero vamos,
PHP, como cualquier lenguaje, tiene sus propias ventajas y desventajas, y elegir PHP o cualquier otro lenguaje realmente depende del proyecto, su escala, etc.

Facebook, como mencionaste como ejemplo, va mucho más allá de simplemente elegir un lenguaje de programación. Comenzaron con PHP, hicieron Hack, HHVM … ¿significa que Hack es la mejor solución para usted? ¿rubí? ¿ir? Node.js? ¿Pitón?

PHP podría no ser la mejor solución para una aplicación empresarial complicada con mucho tráfico, pero eche un vistazo a Scala, Go, Node.js, ruby ​​y python (lenguajes casi famosos).

PHP no se está muriendo. Sin embargo, generalmente no se considera adecuado para escalar sitios web de forma rápida y masiva. Creo que PHP estará disponible durante muchos años como una herramienta útil que, como han dicho otros, está “lista para funcionar” de forma inmediata. (El código PHP bueno y seguro se puede hackear rápidamente e insertar en un sitio web para consumo inmediato).

Para “el próximo Facebook”, recomendaría cualquiera de varios idiomas diferentes: Python, Java, Ruby, Go u otros. Elija uno con potentes marcos web y capacidades de Modelo relacional de objetos (ORM).

Quora.com usa Python y C ++ para buscar, creo. Quora es una prueba de que Python puede escalar bien. La fuerza de un lenguaje con respecto al escalado es tan fuerte como la arquitectura de datos subyacente en uso.

PHP está siendo reemplazado rápidamente por marcos web. La gente se está moviendo a varios marcos web en Python, Java, Javascript, etc.

Si alguien creara un sitio de redes sociales como Facebook, recomendaría usar un marco basado en Python (por ejemplo, Django). Quora usa el marco Pylons. Instagram y Pinterest están construidos en Django. Hay toneladas de otros sitios web que usan marcos de Python.

Por que Python

Python es rápido y fácil de aprender. El tiempo del desarrollador es el recurso más importante. En general, lleva la menor cantidad de tiempo escribir código en Python.

Es importante tener en cuenta que para un sitio web con una gran cantidad de solicitudes, el cuello de botella es generalmente la base de datos y, por lo tanto, la elección del idioma no será realmente un gran problema aquí. La elección de la base de datos será mucho más importante que la elección del idioma.

Python puede ser más lento que X (reemplazar con el idioma que desee). Pero luego, si usa una buena tecnología de base de datos, Python definitivamente no conducirá a un cuello de botella.

He estado trabajando con Ruby durante los últimos 9 años y puedo decir que nunca me sentí tan contento al escribir código. Antes de Ruby usaba PHP, C, C ++, Java. Ruby tiene una cierta elegancia en la forma en que todo parece natural y exactamente como esperarías que fuera. Se siente como escribir poesía y no código, y Ruby convierte la escritura de código optimizado, eficiente y hermoso de una molestia con QA / probadores en algo en la línea de sexar sutilmente a su novia ultra caliente. Bueno, ya captas la idea.

Sí, puede ser lento y pesado en comparación con otros, pero no me importa gastar unos cientos de dólares extra en hardware si puedo hacer que mis clientes estén contentos 10 veces más rápido.

Nuestra capacidad para tener en nuestras manos el poder de la computación solo crecerá con el tiempo, por lo que tal vez una compensación del 10% al 30% en el rendimiento (ser lo más pesimista posible) será un pequeño precio a pagar por un lenguaje que permita mucho tiempo de comercialización más rápido para nuevas empresas y nuevos productos, y también permite a las empresas mantener a sus desarrolladores a bordo durante mucho más tiempo, y también para aumentar la calidad del servicio.

Tengo que decir que también vigilo de cerca Javascript debido a Node y rendimiento. Pero no me veo portando alrededor de 300 megas de código a JS, a lo sumo me ahorro algunos ms en latencia aquí y allá al desacoplar la lógica en microservicios donde sea posible. El lado del servidor Javascript necesita un marco fuerte, como Ruby tiene Rails. Y con eso quiero decir un marco real, no esos mashups que todos y su perro envían spam en Github.

He revisado Erlang, Scala, Go, Clojure: probablemente me lleve 20 años portar mi código actual a cualquiera de estos idiomas, incluida cualquier refactorización. Y habrá muchos, garantizados al portar código de un idioma como Ruby a un idioma sánscrito donde las palabras se reemplazan por todo tipo de caracteres ascii. Eso es un gran no-no. No va a suceder

También vigilando a Swift, aunque el lenguaje no es tan amigable como Ruby, a pesar de todo ese bombo publicitario. Tiene algunas características interesantes, pero su modelo de escritura es un dolor en la parte trasera. Si tuviera un perro, él o ella sentirían lo mismo. Pero, de nuevo, esto está algo más cerca de la preferencia personal: nunca he favorecido realmente este tipo de lenguaje, supongo que me interesa obtener resultados más rápido y escribir. Me gusta almorzar y tomar bebidas con mis clientes, no molestarme con el depurador o las pruebas fallidas o los errores crípticos al enviarles disculpas por correo electrónico y esto no puede, eso no puede simplemente por el idioma / pila, o más precisamente factibilidad.

Lo único que ninguna de las otras respuestas aborda es este simple hecho:

No existe un lenguaje que no sea un reemplazo apropiado para PHP, siempre que tenga una característica: el procesamiento de cadenas.

Siempre que tenga la capacidad de concatenar, dividir, modificar o transformar una cadena, su lenguaje puede ser un sustituto de PHP. La elección, entonces, se convierte en qué abstracciones del lenguaje son más útiles para la tarea.

Con una biblioteca adecuada de CGI (o servidor FastCGI o HTTP), una biblioteca de plantillas HTML y una biblioteca de base de datos, tiene todas las herramientas que necesita, y otras funciones de abstracción son simplemente una conveniencia.

Eso hace que la cuestión de qué lenguaje puede reemplazar PHP sea irrelevante hasta el punto de lo absurdo.

Entonces, la verdadera pregunta es: “¿Qué abstracciones de lenguaje serían las más adecuadas para el caso de uso de PHP?”

La respuesta a eso es la abstracción funcional. Todos los lenguajes funcionales: Lisp, Scheme, Haskell, Clojure, ML, Ur / Web, Erlang, etc., encajan perfectamente. Varios desarrolladores incluso han demostrado que, en términos de tiempo de comercialización, Lisp apenas puede ser vencido.

Pero los lenguajes funcionales no son los únicos. Cualquier lenguaje con la abstracción funcional funcionará bastante bien: Python, Ruby, C ++, Scala, F #, Nemerle, etc.

Para aplicaciones muy interactivas, especialmente donde múltiples usuarios necesitan poder interactuar en tiempo real, la abstracción del actor es la mejor opción, con mucho: Akka, Erlang, Pony, Scala y varios otros idiomas tienen actores como núcleo. abstracción, pero cualquier lenguaje funcional también tendrá bibliotecas disponibles para ello. Pero será difícil encontrar un lenguaje que no tenga una biblioteca de modelos de actores.

En cuanto al modelo de eventos, no diría que es una muy buena opción, particularmente porque los lenguajes que usan un modelo de eventos no suelen tener un buen soporte de hilos o una capacidad de escala horizontal. No utilices Node, niños.

Tienes pocas opciones.

  • Java: es rápido, tiene características de seguridad de tipo, tiene buenas formas de hacer las cosas. No es muy bueno y tiene algunos requisitos de andamios.
  • Node.js: es rápido, no tiene características de seguridad de tipo, tiene buenas formas de hacer las cosas. Es muy bueno y no tiene muchos requisitos de andamios.
  • Ruby (sin rieles): no es muy rápido, pero puede ejecutar varios servidores, tal como lo haría con el nodo.
  • Python: ¡Es como Ruby, pero con espacios en blanco semánticos!

Sin embargo, su primer cuello de botella real hará que la base de datos sea lo suficientemente rápida como para servirle contenido. GLHF con eso. 🙂

Al contrario de muchas de las respuestas aquí, creo que PHP está muriendo. Pero también piense que su eventual disminución (relativa) está demasiado lejos para hacer predicciones como esta (aunque todavía voy a seguir chupando la polla metafórica de Node, siempre y cuando continúe mejorando).

Aunque lejos de ser infalible, echemos un vistazo a sus datos de Google Trend para agregar algo de soporte a esta afirmación.

Además (como lenguaje) no creo que sea muy consistente o particularmente bueno. Tampoco tiene maquinaria masiva corporativa / empresarial, como lo hace Java.

Dicho esto, creo que es justo decir que, aparte de Java, sigue siendo fácilmente uno de los lenguajes más dominantes en el espacio web.

En otras palabras, su declive es relativo. El nodo, por ejemplo (la línea roja), tiene un largo camino antes de alcanzar niveles similares de relevancia.

Si queremos ver cómo se vería un eventual declive de PHP, señalaría a Perl.

Cuando estaba llegando al desarrollo web (alrededor del período 2003–2005), Perl era relativamente popular en el back-end (jodidas rutas cgi-bin en todas partes), o al menos en los libros que leía (así que supongo que fue incluso más popular en el período 2000-2003).

De hecho , al menos según Google Trends, Perl fue significativamente más popular en 2005 que PHP es hoy (aunque un porcentaje decente de esto era probable para aplicaciones que no son web).

De todos modos … Echemos un vistazo a su declive, en relación con Node.js:

Entonces, nuevamente, mi predicción es que PHP sufrirá una disminución similar y relativamente rápida en algún momento en el futuro, pero ese punto podría ser 10 (o incluso 15, dado su nivel de integración, que tomará algún tiempo cambiar). a partir de ahora, con un lento descenso hasta ese punto.

10 años está demasiado lejos para hacer proyecciones sobre qué nuevos idiomas podrían ocupar su lugar.

Tal vez sea Node o un marco JS similar, tal vez Python haga un gran resurgimiento junto con alguna nueva plataforma … Demonios, tal vez el jodido Haskell se vuelva muy popular en la web en ese período de tiempo.

Está muy lejos.


Como un apéndice:

Incluso es posible que la mayoría de las personas los hayan liberado de esta obsesión con un solo lenguaje o marco y solo usen lo que quieran o lo que mejor se adapte al caso de uso.

Pero creo que eso probablemente es esperar demasiado.

Si los desarrolladores de PHP se molestaran en crear una documentación decente y fácil de navegar, PHP7 sería el nuevo lenguaje para reemplazar PHP5.

Ha habido muchos puntos excelentes mencionados anteriormente, por lo que no tiene sentido repetirlos.

Python / Ruby e incluso Javascript (del lado del cliente) son tan antiguos como PHP, así que eso no es un factor. Javascript controlado por eventos podría ser un posible heredero de PHP porque es muy receptivo, pero a partir de ahora todavía veo problemas que importan mucho (principalmente, relacionados con SEO).

Finalmente … imagina que HOY es el último día en que se realiza un nuevo proyecto PHP.

No, peor Imagine HOY es el último día que se crea un nuevo sitio web PHP.

Con todos los millones y millones de sitios web PHP disponibles, cualquiera que lea esta publicación tendrá negocios que mantendrán ese legado durante algunas décadas.

¡Python es donde está! El nodo es bueno, pero Python lo supera en casi todos los sentidos. Como animador y modelador 3D, ¡Python es una herramienta increíble que puede reducir un flujo de trabajo de dos dígitos a menos de 1 hora! Por ejemplo, tuve una animación en la que el hielo se desmoronaba en cientos de pedazos pequeños, cada uno de los cuales necesitaba ser texturizado. Tantas partes con tantas texturas pueden ralentizar significativamente la ventana gráfica, sin mencionar que tomará una eternidad para texturizar cada pieza una por una. Sin embargo, con un script simple, no solo puedo aplicar la textura a cada pieza con un poco de aleatoriedad agregada para el efecto, sino que también puedo apagarla y encenderla para acelerar el poder de procesamiento de la computadora mientras estoy trabajando en otros activos en el proyecto . Sin Python, esto tomaría cientos de horas. Con él, se puede hacer en solo un par.

bueno, la cuota de mercado de PHP en realidad está aumentando. Más sitio web lo está utilizando.

Tendencias históricas en el uso de lenguajes de programación del lado del servidor, julio de 2016

¿Quién dijo que está muriendo de todos modos?

Hay debilidad en PHP, por supuesto, se lo puedo asegurar. Hay muchos desarrolladores de sitios web que escribieron códigos malos e imposibles de mantener. Pero en realidad puedes hacer un código decente usando PHP y ese código sería perfectamente mantenible.

Hice un código PHP de hace 11 años y ese mismo código todavía se usa hoy en día. ¡Aunque a veces me pregunto qué demonios estoy haciendo hace 11 años! Todavía puedo entender el código después de leer el código ya que mi código está documentado y uso el nombre de la función y la variable obvia.

Tan antigua base de código 2005, con funcionalidad adicional hoy, todo en PHP. Funcionó perfectamente para todos los fines previstos.

Mi consejo es: codifique PHP de manera adecuada, como orientado a objetos o de procedimiento, documente su código y su código cumpliría su propósito. Su código sería reutilizable y mantenible.

Te gustaría ganar dinero rápidamente ¿verdad? Solo usa PHP. ¡En el buen sentido!

PD: muchos programadores PHP son imprudentes ya que la mayoría de ellos son script kiddie. No seas uno de ellos. Siempre escriba un buen código profesional y su software será mantenible independientemente del idioma (moderno) que esté utilizando.

PPS: ¡PHP 7 es mucho mejor que PHP 5!

El front-end JavaScript ha reemplazado a una gran mayoría de lenguajes de renderizado del lado del servidor como PHP. PHP es una opción viable para crear los puntos finales API que manejan la web moderna. También está muy por detrás de la curva.

NodeJS es ligero, tiene un excelente paquete de gestión y control de versiones. Su principal competidor es Java.

Java es el primer lenguaje de la mayoría de las especialidades de CS. Eso lo convierte en un contendiente. El problema es que requiere compilación. La buena gestión de dependencias también es muy escasa tanto en Java como en PHP.

Ruby es genial pero no es práctico. Estaba pensando en el futuro hace 10 años. Sigue siendo mi idioma favorito para un prototipo. Falla bajo carga.

Node compila lo que necesita y es flexible. También obtiene mejoras gratuitas del ecosistema front-end. También tiene el manejo más amigable de subprocesos múltiples, promesa y concurrencia. Creo que ya usurpará, o pronto usurpará PHP, Java y, por supuesto, Ruby.