Al menos se pueden esperar dos tipos de respuestas como “¿por qué lado del servidor?” Y “¿por qué lenguaje de scripting?”
¿Por qué un lenguaje del lado del servidor?
Por supuesto, un objetivo es almacenar datos y poder recuperarlos desde cualquier lugar (al menos con alguna conexión de red) y, a menudo, compartirlos, pero los servicios en la nube como Backend como servicio a menudo pueden ser suficientes para eso a menos que desee un control total en qué máquinas se guardan los datos.
- ¿Cuál es la mejor especificación técnica para un sitio web de directorio de membresía?
- ¿Se usa Ruby para algo más que Rails y aprendizaje?
- Si un programador competitivo de nivel medio quisiera comenzar el desarrollo web, ¿cómo sería su enfoque?
- ¿Cómo creo una lista desplegable dinámica?
- ¿Qué es mejor usar para raspar los datos del sitio web y enviar correos electrónicos, PHP o python?
Una razón realmente más importante será que a menudo necesitará implementar reglas de negocio que no deben ser ignoradas por los piratas informáticos del lado del cliente o del intermediario (tenga cuidado con el uso de SSL siempre que las cosas sean razonables). Cualquier control de formulario de front-end siempre debe hacerse de nuevo en el lado del servidor, y por coherencia, poder reutilizar exactamente el mismo código para controlar las entradas en ambos extremos es una ventaja interesante que se vuelve aún más significativa cuando el código del lado del cliente también funciona sin conexión … (transición interesante a los lenguajes de secuencias de comandos 😉)
¿Por qué un lenguaje de script?
Técnicamente, los lenguajes de secuencias de comandos del lado del servidor son muy adecuados para las metodologías ágiles, y más específicamente para el desarrollo basado en pruebas
Esto se debe principalmente a que casi no tiene tiempo de compilación y, a menudo, ni siquiera tiene que reiniciar un servidor para probar los cambios (pero es posible que deba borrar o deshabilitar algo de memoria o caché del módulo)
Vojta Jina realizó demostraciones bastante buenas con Karma JavaScript Test Runner (también conocido como Testacular) al mostrar los resultados de las pruebas unitarias actualizadas incluso mientras escribía su código. La demostración fue del lado del cliente, pero las mismas herramientas se pueden aplicar del lado del servidor con node.js u otras plataformas JavaScript del lado del servidor como wakanda, SilkJS u otras, y estoy bastante seguro de que puede encontrar herramientas similares para otros lenguajes de secuencias de comandos como PHP, Python ruby u otros.
En realidad, incluso los proyectos Java y C ++ han visto parte de su código hecho en JavaScript con fines de flexibilidad.
Tenga en cuenta que todos los diferentes lenguajes de secuencias de comandos del lado del servidor tienen sus propias ventajas y que generalmente debe considerar qué encaja mejor con su caso:
– con qué idiomas, marcos trabajan sus compañeros de trabajo
– cuál proporciona las mejores bibliotecas, herramientas y arquitecturas para su dominio específico
– cuál se adapta mejor a tu propia forma de pensar
Algunos son puramente funcionales, otros son simplemente objetos, y otros son una especie de mezcla que depende de la forma en que lo use (JavaScript, PHP)
comienza a aprender
No es el único, pero, mientras busca aprender uno, a partir de hoy JavaScript es un lenguaje de script muy interesante para el lado del servidor:
– grandes actuaciones
– excelente y servicial comunidad
– ser activamente mejorado a través de implementaciones y estándares
– lado del cliente potencialmente reutilizable
– Muy flexible con mecanismos todavía estrictos y de congelación.
Otra ventaja es que, si bien el conocimiento de JavaScript también es muy útil para el desarrollo front-end, también se puede usar en bases de datos (MongoDB, Couchbase, WakandaDB, …), para construir herramientas de línea de comandos (Inquirer.js, commander.js, .. ), para configurar scripts proxy (archivos de ejemplo de JavaScript o JScript Auto-Proxy)
