¿Qué sentido tiene usar Javascript para todo?

Es accesible y presenta una barrera de entrada baja. No me refiero a eso en un sentido negativo o despectivo. Lejos de ahi. ¿Recuerdas Visual Basic? ¿Recuerdas que fue un trato GIGANTICO? CSI Miami “Hackers” usó “Frontends de Visual Basic para preparar un algoritmo de descifrado” una vez.

Toda la programación que sé hoy, lo sé por BASIC. Los de mis amigos que comenzaron con C todavía luchan. Estaba aprendiendo algoritmos cuando estaban aprendiendo lo que significaba todo el drama. Cuando me encontré con la recursión, la programación dinámica, varios algoritmos de clasificación, etc., leí un tutorial en línea de 12 páginas y recogí toda la especificación de C en un fin de semana. No pudieron envolver sus cabezas en torno a la implementación de la memoria para salvar sus vidas. En ese momento estaba leyendo FFT, pasando a las transformadas de wavelets y la localidad temporal, de nuevo porque QuickBasic me permitió sacarlo.

La diferencia era que el lenguaje hacía las cosas accesibles. El mundo siempre estuvo sano, excepto a finales de los 90 y principios de los 2000. Todos necesitaban programadores, y la gente sabía que podían obtener trabajos si hacían las cosas lo suficientemente difíciles. Condujo a una explosión de UML, SOAP y CORBA, y DCOM, y RMI y EJB y Rational Rose. * Ugggghhh *

Todo lo que estás viendo es un círculo completo. Lo que olvidamos fue toda esa tontería y toda la tecnobabble es insignificante junto al poder de la Fuerza (del diseño del algoritmo).

El uso del algoritmo de clasificación correcto recorrerá los círculos alrededor de su basura WSTP-definida por WSDL diseñada por WSDL, aplicando WSTP-Security todos los días de la semana y dos veces en un fin de semana.

¿Viendo problemas de rendimiento? A menos que estés escribiendo para un Arduino o el Apple Watch, estás viendo problemas de rendimiento porque estás usando algoritmos terribles. Tu memcached es lento porque tus tablas hash no están equilibradas. Su representación es lenta porque su concatenación de cadenas es terrible y no está asignando suficiente memoria de la manera correcta.

¡Un algoritmo de multiplicación basado en FFT en Javascript encontrará 1000! factorial, entonces su MEJOR intento de una implementación vectorizada optimizada de micro-código hiper-subproceso hiper-optimizado que hace la multiplicación bit a bit. La diferencia es – Javascript hace que escribir un FFT sea accesible. Hacer eso en Asamblea es un dolor en el trasero. Es cierto que ahora hacer un multiplicador de FFT en un lenguaje compilado de forma nativa será AÚN más rápido que hacerlo en Javascript. Y donde hay una necesidad: tienes Swift, Go, Rust, C, C ++, etc.

Esta es precisamente la razón por la que los microservicios de estilo de continuación de paso de mensajes de un solo subproceso terminan rindiendo más rápido que su mejor intento en los intentos de subgrupos de subprocesos locales agrupados en subprocesos para “optimizar bloqueos” en Java. Perdiste el juego en la palabra “cerraduras”. Puedes optimizarlo todo lo que quieras. Si dices “bloqueo”, estás tomando una penalización que Javascript no tendrá.

No es que Javascript sea especial o mágico. Probablemente es tan terrible como QuickBasic, y quizás peor. Pero la vaca sagrada te permite crear una matriz, un objeto, una función o una estructura con la posible ceremonia MENOS. Eso permite que quede más capacidad mental para implementar clasificaciones de radix y de pila y buenas funciones de hashing que se equilibren bien, y soluciones de monte-carlo al problema del vendedor ambulante, y así sucesivamente … No se trata de “Patrones de diseño”, UML y Rational Rose van a superar la potencia de hacer que sea accesible para codificar el algoritmo correcto de forma rápida y sin tener que pasar por IImplementerOfFactoryOfCreatorOfSingleton.

Muchas razones, aunque no las defiendo todas. La mayor ventaja es usarlo tanto para el frente como para el trasero, ya que poder compartir el código entre el servidor y el cliente es una gran ganancia. Además, Node es bastante rápido para el tipo de back-end habitual, y descargar el trabajo pesado a algo como Go o lo que sea es bastante fácil. ¿Y cuando solo necesito batir algo muy rápido y tirarlo? Usted apuesta a JavaScript es mi primera opción.

La verdad es que es un lenguaje relativamente amigable y muy expresivo que permite todo tipo de estilos de codificación (OOP (ish), funcional, etc.). Especialmente a medida que madura y obtiene todo lo que ES6 y ES7 tiene que ofrecer / tendrá que ofrecer, es una opción cada vez más sólida para un montón de cosas. Ni siquiera mencionar que la comunidad es enorme, y como la comunidad se ha centrado alrededor de NPM, el código altamente modular es el estándar.

Todo lo que está bien y bien, no debe usarse para todo y usted no debe usarlo porque puede o porque no quiere aprender algo nuevo. Hay muchas tareas más adecuadas para Go, Ruby o incluso Java *. Elija la herramienta correcta para el trabajo como siempre, es solo que JavaScript es la herramienta correcta para muchos trabajos ahora, pero no cometa el error de pensar que es un juguete.

* lol jk, Java sería mi última opción para casi cualquier cosa

Muchas respuestas, pero no una que me haya gustado mucho. Así que asumo lo que quiere decir con “JavaScript” para todo lo que quiere decir con el comportamiento del lado del cliente, el comportamiento del lado del servidor y la base de datos (Angular / React / etc., Express, Mongo) y no como los controladores de dispositivos.

Hay muchas razones. Una ubicación a menudo es que usas un idioma para todo. Esto tiene el beneficio de la reutilización del código y no impedimento (como entre Java y SQL, lo que lleva a las pesadillas de ORM). Pero déjame profundizar en este beneficio porque parece muy nebuloso. Considere dos escenarios. Una si la validación, para la capacidad de respuesta de la interfaz de usuario voy a validar en el cliente. Pero también necesito validar en el servidor. Si estoy usando idiomas diferentes, significa que tiene dos conjuntos diferentes de código de validación. Algunos marcos han hecho un buen trabajo para que esto sea indoloro, pero son soluciones muy mágicas. Otro problema es la carga de la primera página. Las aplicaciones de una sola página le permiten descargar cosas al cliente y también le permiten tener una aplicación mucho más receptiva, pero su inicio es lento. La mejor solución es representar la página inicial en el servidor y tener todas las demás páginas representadas en el cliente. Diviértete haciendo esto en dos idiomas diferentes. Así que hay dos razones sólidas para ejecutar Node en el servidor.

Otra razón para ejecutar Node en el servidor es porque Node es naturalmente asíncrono. Es muy difícil escribir los subprocesos que consumen subprocesos que eran estándar justo en otros marcos en Node. Puede escribir un buen código aynschronous fuera de Node y JS, pero en Node es el valor predeterminado natural, mientras que en otros marcos es mucho más difícil.

¿Por qué usar JavaScript en la base de datos? Bueno, JSON se está convirtiendo en la lengua franca del mundo de las computadoras, reemplazando a XML. Esto significa que una base de datos que contenga JSON no tendrá problemas de impedancia, como SQL frente a C # / Java, lo que llevará a las pesadillas de ORM. JSON también es un buen ajuste para datos no estructurados y las bases de datos NoSQL tienden a tener propiedades de escalamiento diferentes y beneficiosas.

Mi consejo: cualquier arquitectura en la que un componente se base en otro componente para ser de un determinado tipo es bastante defectuosa. Debe diseñar sistemas para que los componentes puedan intercambiarse con un código completamente rediseñado sin molestar a ningún otro componente. Esto es una mierda bastante básica. Pero -dude-on-internet- dices, ¿no acabas de decir que JavaScript en el servidor era bueno? Sí, tiene ventajas, pero abrazar ciertas ventajas puede tener un impacto negativo en su arquitectura. Lo que podrías hacer: Tener un extremo frontal de SPA. Tenga un back-end de Node / Express que haga las primeras representaciones y la validación, y así sucesivamente. Luego, tenga una capa de datos / negocio separada que devuelva JSON. Podría estar en cualquier cosa, pero no está vinculado a JavaScript.

La Web es un mercado masivo con muchas soluciones diferentes para casi todos los problemas. Al igual que todas las tecnologías importantes que cambian las sociedades y se integran en las culturas, ha tardado mucho tiempo en madurar y obtener las capacidades que los innovadores siempre pensaron que debían tener.

La web se ejecuta dentro de navegadores web, la mayoría de los cuales tienen algún tipo de motor javascript, por lo que no debería sorprender que el formato de intercambio de datos de mayor crecimiento en la web se base en Javascript – JSON. Durante la mayor parte de su historia, la Web ha tenido un entorno para el navegador y otro diferente para el servidor, de modo que cada aplicación web era, en efecto, dos aplicaciones: una en el servidor en un idioma y la otra en el navegador, en HTML y Javascript.

Con Node.JS y otros entornos de JavaScript para el servidor, esto ya no es cierto. Ahora puede compartir el código entre el servidor y el navegador, hasta el nivel de que lo que eran dos aplicaciones separadas ahora son solo interfaces diferentes de una aplicación. Eso, en realidad, ahorra mucho esfuerzo de programador, tiempo y, lo que es más importante, dinero, no solo en el tiempo original empleado en la creación de la aplicación, sino también en el aspecto de mantenimiento.

Eso, más que nada, es la razón por la que muchas personas están empujando JavaScript en el servidor. ¿En cuanto a cualquier lugar más allá del servidor y el navegador? Bueno … al parecer, el nuevo “Código de Visual Studio” de MS está construido a partir de Node.JS, así que … Tal vez también haya un lugar para él en el escritorio.

Porque tú puedes.

Por qué no? Si conoce JS y puede usarlo para su proyecto, entonces no necesita aprender una nueva herramienta.


Porque es popular

Como han señalado otras respuestas, JS está teniendo un renacimiento en este momento. Actualmente está creciendo rápidamente en GitHub.

Solo porque puedas, no significa que debas

  • JavaScript no es siempre la solución más eficaz para su problema. Elija la herramienta adecuada para el trabajo.
  • JavaScript tiene muchas peculiaridades. A la gente parece gustarle los lenguajes de compilación a JS como TypeScript para solucionar este y otros problemas.
  • El ecosistema de JavaScript es turbulento en este momento. ¿Todos esos nuevos proyectos de GitHub? La mayoría no se mantendrá después de un año más o menos.

Buena suerte en tus proyectos!

HYPE, HYPE y MÁS HYPE

Según la psicología, se llama efecto lemming.

Los lemings son pequeños roedores que se han observado para seguirse unos a otros a medida que se lanzan a la muerte, en ríos furiosos o incluso en acantilados.

Ahora, JavaScript no es tan malo. Tiene buenas partes también.
La cosa es que la mayoría de la gente cree que usar js para todo significa que no tienen que aprender más cosas y que su vida sería más fácil.

Realmente desearía que eso fuera cierto, pero no lo es. Javascript tiene su uso en algunas áreas como nodejs y navegador. En otras áreas como mongoDB, la cordura tardó pocos años en superar el efecto lemming

Actualizado: Agregando más argumentos a las respuestas a los comentarios.

La reutilización del código es, de hecho, el único argumento a favor de js. Pero lo que realmente importa en el desarrollo de software es el tiempo .

Claro, puede reutilizar el código tanto en el servidor como en el navegador. Pero el navegador y el servidor son bestias muy diferentes. Y el código que realmente reutiliza se reducirá a los modelos de visualización únicamente. Con la falta de frameworks * js maduros , es más lento usar js en lugar de C # (Asp .Net), PHP (con laravel o Symfony) en el lado del servidor.

* Express no me parece que esté maduro y el meteoro es nuevo, con el reciente cambio de fuego para reaccionar, difícilmente puede considerarse maduro.

PD: no creo que nadie me menosprecie si elijo postgres sobre mongoDb, ¿verdad?

¡Bueno, JavaScript y los motores que ejecutan JavaScript presentan la capacidad de codificar en cualquier lugar para cualquier cosa! Por ejemplo, JS puede usarse para desarrollo web tanto en el frente como en el extremo posterior. Esto permite a los programadores usar un solo lenguaje y tener un código más legible y mantenible, y también es bueno para las empresas, ya que ahora pueden contratar a menos personas y tampoco hay necesidad de que varios instructores o clases enseñen a los recién llegados.

También JavaScript tiene habilidades increíbles y en su mayoría únicas. Lo mejor de ellos es la libertad en el estilo en el que codificas. Puedes usar los paradigmas OOP o FP. Además, JS es una muy buena opción cuando se trata de problemas de manejo de velocidad o solicitud, donde lenguajes como PHP consumen recursos.

No se puede negar que JS es mucho más lento que en los idiomas de nivel inferior (por ejemplo, C ++) y nadie está diciendo que JS es el mejor idioma (y quienquiera que esté diciendo que está equivocado o que solo está asumiendo un solo caso), pero es mucho más agradable que la mayoría de los idiomas que hay.

Desde un punto de vista económico, puede reducir los costos de los proyectos (a menudo experimentos) y compartir abstracciones con una gran comunidad de desarrolladores. En lugar de reinventar las ruedas, puede “tomar prestado” el código de una gran cantidad de bibliotecas y adaptarlo a sus propias necesidades. Una vez que su código esté funcionando, puede devolver fácilmente el código con algunos intereses de su propio esfuerzo. Guarda muchas de las fricciones que vienen con otros lenguajes y ecosistemas. (De lo que aprendí, revertir el argumento ecominc también es válido: si desea aumentar sus ingresos o salario como programador, es posible que también desee aprender otros idiomas).

JavaScript es una comunidad que crece todos los días a partir de tutoriales de Internet y personas que simplemente quieren aprender algo. Ya que está en cada navegador que usa, es fácil comenzar, solo necesita usar herramientas de desarrollador, no necesita estar familiarizado con la encapsulación, el tipo de Languedoc, oop, la compilación o cualquier patrón de programación (creo que es por eso que hay mucho de programadores sh ** js también). Y cuando el lenguaje con el que está más familiarizado se está asentando en un nuevo nivel, con node, io, cylon, etc., la comunidad simplemente explota. Y para una empresa es más barato tener 6 desarrolladores de JavaScript que trabajarán en la pila completa que 3 js devs y 3 c # devs 3 expertos en MySQL, etc.

Por cierto, no hay nada como el mejor o el peor lenguaje, pero hay un lenguaje mejor para ese tipo de trabajo. Espero haberme aclarado con mi inglés, disculpe cualquier error, escribo esto en mi teléfono y no estoy acostumbrado a escribir en inglés. Gracias si llegas tan lejos.

Aunque probablemente no sea técnicamente en TODAS las computadoras, el tiempo de ejecución de JavaScript está más cerca de ser ubicuo que cualquier otra alternativa, probablemente por un orden de magnitud. Si tiene un navegador, tiene la capacidad de escribir y ejecutar código Javascript, por lo que puede ejecutarlo en cualquier lugar que tenga uno de esos.

Y gracias a node.js, ni siquiera necesitas un navegador. Pero aquí es donde el argumento de la ubicuidad de JavaScript pierde terreno: me parece que si va a escribir un código del lado del servidor, la disponibilidad del tiempo de ejecución de su idioma en el lado del cliente no es una razón para elegir ese idioma. Pero a algunas personas les gusta la idea de que toda su pila trabaje en los mismos patrones.

Ahora, el tiempo de ejecución del nodo es estúpido y rápido, por lo que si escribe un código asíncrono, casi no perderá la concurrencia, hasta que lo haga. Entonces probablemente te preguntarás por qué no elegiste otra cosa.

Y luego hay personas que usan Javascript para cosas que no están relacionadas con la web. Esto ni siquiera pretenderé entenderlo.

Por lo general, siempre tienes opciones.

JS es realmente bueno para desarrollar aplicaciones web de tamaño pequeño / mediano. Puede introducir bastante lógica rápidamente y lanzar el proyecto en los plazos más cortos.

Además, actualmente hay muchos marcos de trabajo de backend que permiten utilizar JS tanto para frontend como para backend. Es mucho más fácil escribir todo en un idioma que tener un idioma para backend y otro para front.

Pero si necesita algo realmente complejo y con enormes ciclos de transformación de datos, necesitará usar algunos lenguajes OOP sólidos. Normalmente se utiliza para soluciones empresariales JAVA.

Algunos problemas con el desarrollo de todo en JS:

– Un montón de marcos y existe un riesgo para el uso de la producción (las tendencias y el mantenimiento están cambiando demasiado rápido).

-las dependencias también podrían salir bastante rápido

-Demasiado difícil desarrollar algunas características complejas en el futuro.

Por qué usar javascript para todo:

1. Fácil de gestionar los recursos humanos.

Normalmente ves la experiencia de JS. No es que usted barajará a los desarrolladores front-end con back-end y así sucesivamente. Sin embargo, se siente mejor para las personas que están experimentando un infierno asíncrono con las personas que tienen dolores de cabeza de devolución de llamada.

2. Prototipo más rápido – de extremo a extremo.

Si usted es pequeño (digamos <5 personas, nuevamente no es difícil y rápido para juzgar a un niño pequeño) y comience con una idea en mente. Probablemente, JS será una mejor opción. Esto funciona muy bien cuando hay dos personas. Por lo general, se espera que sean desarrolladores de pila completa, y pueden realizar programas de pares, revisión de códigos, establecer estándares de estilo, etc., de manera más cómoda.

3. Popularidad de Node.js

Es un buen servidor backend para usar. Gran comunidad. Muchos recursos. y un montón de cosas buenas. Si por casualidad eliges Node en el backend, estás prácticamente haciendo “JS para todo”. Coz, no tienes una opción en la parte delantera. (En realidad, su pregunta realmente se reduce a “¿por qué usar JS en el servidor?”)


PD. Si alguien está diciendo, JS no es bueno para aplicaciones grandes / escalarlo a grande. Solo ignoralo. Porque si estuviera creando una aplicación tan grande, probablemente ya tenga expertos de su lado que no crearía la necesidad de que publique esta pregunta. Si no sabes si JS escala bien; puedes asumir con seguridad que para cuando JS no esté escalando, probablemente seas multimillonario y puedas contratar a un grupo de geeks para que incluso escriban tu propio idioma (lee swift, ve).

Eso no es realmente el caso. Realmente puedes usar Javascript para todo. Todavía hay mucho Javascript no se puede hacer que un lenguaje del lado del servidor adecuado como PHP puede.

Algo como la instancia de cURL, es increíblemente poderoso que Javascript no puede hacer. La seguridad es más frecuente en PHP o Ruby, ya que ocurre en el servidor en comparación con Javascript, donde cualquier persona puede acceder a sus archivos de JavaScript en algún nivel. El mayor enfoque en JS es que se está volviendo popular para aplicaciones de UI y de página única. En alguna parte es probablemente solo una tendencia. Pero es realmente poderoso en ese caso. Incluso WordPress ha movido parte de su funcionalidad a React con integración completa de API.

  1. El único idioma que puede hablar con su navegador a través de Eventos.
  2. Alimenta tu navegador para realizar solicitudes asíncronas al servidor a través de Ajax
  3. Aumenta la experiencia del usuario al lanzar errores e información a través de la validación del lado del cliente
  4. Permite embellecer tu página web utilizando efectos de animación.
  5. Permite manipulaciones DOM – agregar / eliminar elementos, clases, etc.

Simplemente es el único idioma que le permite hablar con el navegador y es el más sencillo de todos.

Cualquiera que diga “x es el futuro de y” siempre está lleno de mierda.

No voy a saber si JavaScript es bueno o malo, solo diré “ciertamente es un lenguaje de programación”.

Creo que a los principiantes les gusta la idea de usar un solo idioma para todo, de modo que no tienen que aprender más de uno, y los sitios web prefieren decir que las cosas son el futuro, así que leemos el artículo y miramos los anuncios.

Es solo una exageración, lo conseguimos para Java, .NET, Ruby on Rails, eso pasará.

No puedo aceptar que JavaScript se pueda usar para ” todo “, además de que ” AJAX ” está defectuoso y no funciona en todos los navegadores / plataformas.

JavaScript es más para los desarrolladores de aplicaciones para usuario y la programación de servicios de fondo que se relaciona con la interfaz de usuario .

A menos que pretenda usar una API potente que funcione con JavaScript como un servidor de socket, este es un caso en el que tendría que estar en desacuerdo conmigo mismo .

No me malinterprete. Me encanta JavaScript, pero está extremadamente limitado en el poder que tiene sobre lenguajes de alto nivel como PHP. Necesitas marcos para JavaScript – o clases pre-construidas. PHP tiene el poder desde el principio.

No tenga miedo de aprender lo más que pueda sobre JavaScript. Sin embargo, no te olvides de los lenguajes de alto nivel que se encuentran detrás de ese Magic de front-end.

¿Te imaginaste en 1991, que en 2016 habrá miles de millones de instalaciones de Linux? (Android – es Linux). ¿Se imaginó alguna vez en 1995, que en 2016 habrá miles de millones de intérpretes de JS trabajando activamente en casi TODOS los dispositivos informáticos? Me atrevería a poner en el mismo nivel estos eventos significativos.

El navegador puede interpretar JavaScript directamente, por lo que es lógico poder reutilizar partes del código en el servidor también. Desafortunadamente el lado práctico se ve de alguna manera diferente.

No hay ninguno. Es posible que pueda hacer todo en Javascript hoy, pero como ingeniero, debe evitar volver a inventar la rueda si ya hay soluciones sólidas disponibles. Si no lo haces, solo estás buscando satisfacerte y el único al que estás ayudando es a ti mismo.

Dicho esto, me di cuenta de que crear IU para aplicaciones con lenguajes de tipos dinámicos es mucho mejor que los lenguajes compilados. La velocidad y flexibilidad que obtienes es demasiado buena. Si alguien me pide que compile una aplicación de escritorio hoy, probablemente la compilaré con js y la enviaré con nodejs.

Hay más cosas que decir sobre los recién llegados que entran en la programación con js que van con la exageración y, desafortunadamente, muchos veteranos que hacen preguntas como, pero ¿cómo entrarán los desarrolladores de Java en JS si cambiamos? Es increíble.

Simplemente, escriba sus objetivos, mire y en realidad pruebe algunas tecnologías y elija la que sea mejor para usted.

No solo tiene una gran base de usuarios, sino una base de usuarios bastante diversa. Muchos artistas gráficos dominan JavaScript, por lo que en algunas plataformas tiene sentido. No estoy a favor o en contra de JavaScript, pero no veo que su popularidad disminuya en un futuro cercano, por lo que un desarrollador debería estar cómodo con su uso.