sabemos que JavaScript es uno de los lenguajes más populares y ampliamente utilizados en el front end. ¿Me pregunto si no se usa ampliamente en back-end?¿Por qué el lado del servidor Javascript no es ampliamente utilizado?
Respuesta corta: porque hay alternativas mucho mejores.
Respuesta larga: Dado que es totalmente interpretado (y a menudo no es bueno, eg IE6), no proporciona mecanismos de E/S estándar aparte de lo que ofrece el entorno, tiene una gramática suelta que resulta en código difícil de verificar y mucha gente encuentra que OO basado en prototipos es mucho más difícil de tratar que OO basado en clases.
* "Debido a que se interpreta por completo ..." * No se ha estado [manteniendo actualizado] (http://code.google.com/p/v8/)? * "no proporciona mecanismos de E/S que no sean los que brinda el entorno" * Entonces, como cualquier otro idioma en el mundo, entonces. I/O no es una función de idioma, es una [característica de entorno] (http://nodejs.org/). * "tiene una gramática suelta que resulta en código difícil de verificar" * La gramática no está suelta. Acepto que la verificación del código puede ser un desafío con los lenguajes dinámicos ricos. –
@TJ - Ese proyecto de Google parece ser un intérprete, no un compilador. Quise decir que no contiene E/S en su implementación estándar, a diferencia de C, C++, C#, Java, etc. Describiría los puntos y coma opcionales excepto cuando no son opcionales como una característica de gramática suelta. – OrangeDog
No pude estar más de acuerdo con usted acerca de la idiotez de la "inserción de punto y coma", está muy bien allí. ** Wow ** Ojalá hubieran arreglado eso en modo estricto. V8 es básicamente un compilador JIT en lugar de un intérprete. De hecho, es un compilador JIT de optimización (más recientemente un análisis de dos fases con análisis y optimización de puntos de acceso). No hay ninguna razón para que un formato provisional no se pueda almacenar (Rhino hace esto, compila código de JavaScript a Java), el lenguaje no lo impide más que requerir que permita construcciones dinámicas. –
JavaScript es popular y ampliamente utilizado en el front end porque tiene una masa crítica, no necesariamente porque es un lenguaje excelente. Nadie toma la decisión de escribir JavaScript para el código del lado del cliente; simplemente debe, porque cada navegador lo admite. En el back-end, otros lenguajes (Java, PHP, Python, Ruby, ...) ofrecen ventajas que JavaScript no puede ofrecer.
De hecho, CoffeeScript es un intento de evitar el requisito de escribir JavaScript (tradicional) en el navegador, tampoco. –
Cada vez es más utilizado gracias al motor V8 de Google. Eche un vistazo al Node.js. Creo que el bajo rendimiento limitó su efectividad antes.
Node.js le permite escribir servicios web personalizados con subprocesos múltiples en un abrir y cerrar de ojos y en su mayoría POO. Creo que verás que Javascript en el back-end apenas está comenzando a ejecutarse.
creo que la única cosa que de nuevo es — como otros han dicho — la falta de una (para Linux al menos) solución perfectamente embalados y estandarizada drop-in. Esta solución debería ser recogida por las principales compañías de alojamiento y agregada como parte de sus ofertas de productos para que realmente despegue en mi humilde opinión. Si eso sucede, creo que descubrirá que explotará en el espacio del servidor back-end.
Microsoft ofrece la posibilidad de programar sistemas de back-end con "Javascript" (AKA JScript) desde 1998 con su oferta ASP. Aún puede desarrollar aplicaciones ASP.NET con JScript. Entonces no es nada nuevo. Creo que la razón por la que no se usa ampliamente para aplicaciones ASP o ASP.NET es porque VBScript es el "predeterminado" y C# parece ser el idioma preferido para profesionales con más experiencia. Pero no hay nada que lo detenga, excepto las políticas de la empresa que a menudo restringen a los desarrolladores a un único idioma para el desarrollo corporativo. Una razón por la que JScript podría no ser usado mucho por entidades corporativas es que "appears no longer to be actively developed." De hecho, Microsoft nunca realmente "comercializó" JScript para desarrolladores. O al menos no tanto como lo hicieron C# & VBScript. Entonces creo que eso puede haberlo retrasado.
Creo que la * exposición * pobre limitó su uso antes. Estaba disponible para el uso en el servidor en un momento en que otros mecanismos del lado del servidor también tenían serios problemas de rendimiento, la gente simplemente no * lo usaba *. Sin embargo, +1 para las cosas del nodo, y la observación de que probablemente esté a punto de despegar. He estado usando JavaScript en los servidores por años, es simplemente ** tan ** conveniente usar un idioma en todas partes. –
El bajo rendimiento no es una razón, programé PHP, .NET (C#), Perl y JScript, JScript no es el ejecutante más pobre. – KooiInc
Agregué comentarios sobre lo que creo que está reteniéndolo, y la prueba de que ha existido desde 1998. – sholsinger
Yo diría que es solo un accidente de la historia. Javascript nació en Netscape como un lenguaje del lado del cliente y nunca hizo la transición.
Comparándolo con los lenguajes web prominentes del lado del servidor de hoy, creo que la diferencia más obvia es que las baterías no están incluidas con Javascript. No hay una biblioteca estándar
Compárelo con Python, PHP, ruby, etc. que tienen fantásticas bibliotecas estándar que hacen que la programación web sea mucho más agradable.
Nitpick: En realidad, JavaScript nació como un lenguaje de scripting web para el cliente y el servidor. De hecho, la razón por la que originalmente se llamaba LiveScript (y no, por ejemplo, NavigatorScript) fue porque se enviaba como el lenguaje de scripting para el marco de la aplicación web Netscape LiveWire que formaba parte de Netscape Enterprise Server 2.0 y posterior. Estoy de acuerdo con tu conclusión, sin embargo. Es un poco difícil usar un lenguaje para la programación en el servidor, que ni siquiera puede leer un archivo del sistema de archivos. –
Creo que la respuesta podría ser que lo que es bueno para el lado del cliente no siempre es bueno para el lado del servidor. Por ejemplo, Javascript (ECMAScript en general ... también ActionScript) es un lenguaje muy laxo e indulgente, que le permite salirse con la suya con muchas cosas. En el lado del cliente, esto no solo es aceptable sino también preferible.A menudo desea que su interfaz de usuario sea lo más sencilla y tolerante posible para mejorar la experiencia del usuario.
En el lado del servidor, sin embargo, suele ser una historia diferente, y es por eso, creo, que los idiomas que dominan ese lado son más fuertemente tipados y rígidos.
También está la cuestión de la escala. Lo que funciona para la base de código generalmente más pequeña de una aplicación de interfaz de usuario del lado del cliente no siempre funciona para el lado del servidor, que tiene que lidiar con una serie de problemas que no son realmente una preocupación importante en el lado del cliente. p.ej. rendimiento, empaquetado, escalabilidad: estos son mucho más importantes para el código del servidor que para el código del cliente (por lo general), por lo que es comprensible por qué las personas no elegirían JS para trabajar en el servidor.
php, ¿rígido? 1234 –
No soy un experto en esto, pero Douglas Crockford dice en "Javascript: The Good Parts" que JS esencialmente se hizo popular en el navegador por accidente, no por mérito.
", JavaScript es un lenguaje con más que su parte de las piezas malas. Se fue de la inexistencia a la adopción global en un periodo alarmantemente corto de tiempo. Nunca tuvo un intervalo en el laboratorio cuando podría ser probado y pulido ... cuando no Java applets, Javascript se convirtió en el 'lenguaje de la web ' por defecto. la popularidad de JavaScript de forma es casi completamente independiente de sus cualidades como un lenguaje de programación ".
Los diferentes navegadores lo implementan de manera diferente, y es más difícil decir qué es correcto que para los idiomas con un intérprete estándar.
Tiene buenas características, como explica el libro de Crockford, y node.js puede demostrar que es genial para el desarrollo del lado del servidor. Pero hasta ahora, donde las personas han tenido opciones, en su mayoría han elegido otros idiomas.
En el servidor, las personas no están obligadas a usar un idioma específico, y JavaScript es tan libre que el código se vuelve muy difícil de mantener.
Es por eso que el mayor porcentaje de personas elige otra cosa.
¿Porque no se supone que sea un lenguaje del lado del servidor? –
esto no es ni subjetivo ni argumentativo. Es una pregunta válida con respuestas reales. –
la primera vez que vi un atributo 'runat =" server "' en una etiqueta 'script type =" text/javascript "' Lo vomité en la boca – hunter