¿Es JavaScript el mejor para el back-end?

Creo que es una opción viable, aunque posiblemente no sea la mejor.

• Comencemos diciendo que no hay una mejor opción . Depende de lo que realmente estés haciendo. Por ejemplo, node.js es realmente bueno para cosas vinculadas a IO (gracias a su naturaleza asincrónica) pero es realmente malo para cosas vinculadas a la CPU.
• Algunas personas pueden odiar a JS con pasión, pero aquí lo diré: JS no es tan malo. Hay algo peor. Personalmente, encuentro que PHP es mucho, mucho peor que JS. Y también, JS está corrigiendo constantemente sus errores, al tiempo que agrega características nuevas, emocionantes y útiles al lenguaje, en las últimas versiones de ECMAScript (principalmente 6 pero también 7 y 8).
• Si tiene desarrolladores que saben lo que están haciendo, entonces JS es realmente tan bueno como cualquier otro lenguaje dinámico (y por saber lo que están haciendo , me refiero a las personas que escriben pruebas unitarias, que usan promesas y generadores para evitar la devolución de llamadas) diablos, que se mantengan alejados de las coacciones de tipo …)
• También siento que JS ha tenido más influencia funcional recientemente, en comparación con la mayoría de los otros idiomas principales (y eso significa que lo disfruto más, pero algunas personas podrían no tenerlo)

Pero ten cuidado. Como la mayoría de los otros lenguajes dinámicos, pero aún más, JS requiere disciplina para escalar sin convertirse en un desastre. Así que ten cuidado si creas algo grande con él.

Depende absolutamente de lo que haga tu backend.

JavaScript tiene una gran ventaja: uno puede desarrollarse rápido y rápido. Si lo que tiene en mente es la velocidad de desarrollo, y solo conoce JS como un lenguaje de fondo, entonces JS es el idioma a seguir. Sin embargo, hablemos honestamente sobre el resto de las cosas en las que uno podría estar interesado.

El rendimiento de JS es aceptable para, digamos, un blog personal o un sitio pequeño donde generalmente no hay mucho tráfico. Pero cuando comienzas a ver cuántas visitas recibes, qué tan cargado está tu sistema, si comienzas a preguntarte cómo puedes soportar más clientes sin comprar más hardware, entonces no encontrarás una respuesta en JavaScript. Obtiene “lo más rápido posible, pero no más rápido”, realmente no puede optimizar JavaScript, hay costos inherentes que pagará todo el tiempo.

Eso no significa que no puedas obtener rendimiento. Se sabe que las personas hacen cosas increíbles con lenguajes interpretados, incluidos el código de bytes de Java y CIL. La tecnología evolucionó mucho y, a veces, el argumento de “velocidad de desarrollo” puede ser convincente. La mayoría de las veces, el costo supera el rendimiento y, para la mayoría de los prototipos, JavaScript es más rentable.

Pero volviendo a tu pregunta. ¿Es JavaScript el mejor para el backend? No, pero tampoco es lo peor. Al final, cualquier idioma es bueno siempre que ofrezca las cosas que necesita de manera productiva. JavaScript es productivo, pero tiene más que solo el tiempo de desarrollo para tener en cuenta.

Depende de tu proyecto.

En mi experiencia, ningún idioma es “absoluto” para todo tipo de proyectos. Tienes que investigar claramente cómo vas a construir una determinada cosa.

IO asincrónico sin bloqueo de Node.js lo convierte en una opción adecuada cuando tiene una gran cantidad de solicitudes por segundo porque el bucle de eventos se realiza muy bien, es por eso que grandes jugadores como Walmart, Netflix y Paypal han venido a Node.js y todos de ellos compartieron que sus aplicaciones Node.js se cargan más rápido que las aplicaciones anteriores.

Pero la pregunta difícil son los cálculos por tarea. Debido a la naturaleza de un solo hilo de JavaScript, no es bueno para una tarea computacional intensa.

Entonces, ve que es mejor pensar en términos de un proyecto específico que las tecnologías deben usarse, en lugar de comenzar una guerra santa de que X siempre es mejor que Y.

No puede equivocarse con ninguno de los lenguajes para el desarrollo de back-end y puede usarlos para una multitud de otras tareas más allá del desarrollo web también. JavaScript es posiblemente la tecnología más omnipresente del lado del cliente que proyecta una amplia red sobre el desarrollo front-end. Pero con la creación de la plataforma NodeJS en 2009, JavaScript se convirtió en un jugador en tecnología de fondo. Node.js tiene una floreciente comunidad de código abierto que ha conformado muchos módulos excelentes para agregar capacidades adicionales a las aplicaciones de Node.js.

Lenguajes como Java, PHP, Python, Ruby, etc. tienen mucha más historia, lo que significa mucha más madurez y estabilidad. Debe tener en cuenta que todos tienen un proceso de aprendizaje diferente, por lo que depende en gran medida de cómo aborde el idioma que seleccione.

Node.js PHP (lenguaje de programación) Empresa de desarrollo de aplicaciones móviles, Servicio de desarrollo de sitios web

Depende.

Esto es demasiado subjetivo para responder realmente. La mayoría de los “puristas” dirían “no”, pero realmente se reduce a sus requisitos funcionales y no funcionales, presupuesto, línea de tiempo y conjunto de habilidades disponibles del equipo. Si está creando una base de datos empresarial, probablemente no. Si está creando una API altamente concurrente, muy bien podría ser.

Un buen caso de estudio es LinkedIn:

• LinkedIn se movió de Rails a Node: 27 servidores cortados y hasta 20 veces más rápidos – Alta escalabilidad –

Hay ventajas y desventajas de cada conjunto de tecnología y aprenderá a través de prueba / error qué funciona mejor para resolver su problema particular. ¡La mejor de las suertes!

Sí, puedes hacer muchas cosas de backend en Javascript.

Hay muchos frameworks y aplicaciones que ejecutan Javascript como backend, todos con diferentes pros y contras.

NodeJs

Node.js es una plataforma basada en el tiempo de ejecución de JavaScript de Chrome para crear fácilmente aplicaciones de red rápidas y escalables. Node.js utiliza un modelo de E / S sin bloqueo controlado por eventos que lo hace liviano y eficiente, perfecto para aplicaciones en tiempo real de uso intensivo de datos que se ejecutan en dispositivos distribuidos.

OPA

Opa es un marco de aplicación avanzado para JavaScript. Todos los aspectos están escritos directamente en Opa: código de interfaz, código de fondo, consultas de base de datos y configuración. Y todo está fuertemente estáticamente tipado.

CommonJs

La API de CommonJS llenará ese vacío definiendo las API que manejan muchas necesidades de aplicaciones comunes, proporcionando en última instancia una biblioteca estándar tan rica como las de Python, Ruby y Java. La intención es que un desarrollador de aplicaciones pueda escribir una aplicación utilizando las API de CommonJS y luego ejecutar esa aplicación en diferentes intérpretes de JavaScript y entornos host.

Vertx.io

Vert.x es el marco para la próxima generación de aplicaciones simultáneas asincrónicas, escalables sin esfuerzo. Vert.x es un marco de aplicación basado en eventos que se ejecuta en la JVM, un tiempo de ejecución con concurrencia real y un rendimiento inigualable. Vert.x luego expone la API en Ruby, Java, Groovy, JavaScript y Python. Entonces eliges qué idioma quieres usar. El soporte de Scala y Clojure también está en la hoja de ruta.

Depende del proyecto real que intente implementar.

Si su backend está relacionado con la simple obtención de datos de algunos sql / nosql db y el suministro de esos datos al lado del cliente sin un procesamiento pesado, nodejs es uno de los marcos preferibles para usar o incluso Go Language podría ser una buena opción.

Pero si necesita hacer un procesamiento de imágenes pesadas o procesar tareas intensivas en el backend, entonces nodejs podría no ser una buena opción.

En mi opinión personal, uno no debería usar o apegarse a un idioma simplemente revisando las revisiones, sino pensar en las aplicaciones prácticas del idioma y si un lenguaje o marco en particular cumple con esos requisitos en un punto en el que su backend necesita escalar y manejar solicitudes del lado del cliente.

Si te gusta la respuesta, vota amablemente 😀

No. No. No no no no no no no.

JavaScript es el peor lenguaje absoluto para el back-end. Se puede usar para el back-end … pero hay formas mejores, más rápidas, más versátiles y más funcionales para realizar el procesamiento del lado del servidor (C #, PHP, Perl, Java, un equipo de monos no entrenados que responden a las solicitudes HTTP lanzando sus propia materia fecal en un teclado y emitiendo el galimatías aleatorio resultante, etc.).

El mandamiento 404 (de las escrituras de Serveriah 127.0.0.1):

Así dice el Señor: aunque no hagas uso de la abominación llamada JavaScript del lado del servidor. El que lo usa debe ser castigado con la muerte.

E2A: He recibido un poco de retroceso en esta respuesta, y quería aclarar mis declaraciones. Parte de lo que escribí tenía la intención de ser chistoso. Mi respuesta es un poco cansada y tiene una gran cantidad de sesgo. Trabajo en un campo donde JavaScript es el peor lenguaje para el back-end. Si bien no hago muchas cosas de back-end en términos de volumen de código, lo que he escrito requiere una velocidad de ejecución rápida (como en las funciones cron súper optimizadas que se ejecutarán una vez por minuto durante los próximos 5 años). Además, también conozco mejor C # y prefiero usarlo.

Además, el servidor de mi empresa no tiene Node.js instalado, y ¿por qué hacer algo en JavaScript cuando puede hacerlo fácilmente en C #?

El mejor idioma para cualquier tarea es el que mejor funciona para una situación dada.

Además, como un chico incondicional de C #, no puedo resistir la tentación de golpear JS en el lado del servidor 😉

No estoy de acuerdo con las otras respuestas aquí. Cualquier lenguaje es simplemente una herramienta para la programación, y uno debe elegir las herramientas que sean apropiadas para la tarea en cuestión. Cada vez que escucho opiniones polarizadas sobre un tema u otro, me pongo cauteloso. Además, Javascript ha acelerado su desarrollo recientemente, por lo que una opinión previamente formada puede no estar al tanto de las últimas capacidades. Los idiomas van y vienen. No es sensato aferrarse al pasado.

No hay un “mejor” lenguaje. Debes usar cualquier idioma para que puedas hacer el trabajo de la manera más eficiente. Esto generalmente significa cualquier idioma en el que tenga más experiencia.

Dicho esto, Python es el mejor lenguaje y todos deberían usar Python siempre que puedan. 😉

Js maneja el back-end un poco diferente de lo que solíamos ver en otros idiomas: es de un solo subproceso e impulsado por eventos, en palabras simples, no lo usa para hacer grandes cálculos, lo usa como un “camarero” entregando pedidos y resultados entre el cliente y muchos servicios pequeños (cada uno escrito en el idioma que desee).
En general, creo que es una mejor idea y es más fácil de administrar …

No.

Generalmente se considera que JavaScript es un lenguaje bastante malo en general.

Incluso si te gusta, crees que es increíble, ¿es lo mejor ?

No creo que ninguna persona razonable pueda hacer ese caso.

Se reduce a ser el mejor solo en las situaciones, es la única opción disponible. Como hablamos de back-end, por ejemplo, si su plataforma es Google Docs / Spreadsheets / Presentations / Forms, JavaScript es la única opción, entonces también solo es un lenguaje de pegamento, ya que lo principal que usa dentro de sus App Scripts son las API de Google de Todos los aspectos relacionados con Drive, Documentos y cualquier objeto involucrado.

Si tiene la opción para cualquiera que sea su back-end, elija otra cosa que no sea JS.

¿El mejor? Nah

¿Que es lo mejor? Si me preguntaste: nada. Nada es “lo mejor”.

Todo lo que se utiliza para el desarrollo de back-end es una opción y es su trabajo descubrir qué es lo mejor para usted.

Sí, use el nodo js como back-end. Es la mejor fuente disponible en este momento.