Gracias por el A2A. Los idiomas de los que habla son lenguajes de secuencias de comandos. Tampoco comentaría sobre PHP y Python, como C #, ya que son clones descuartizados de otra cosa. Java también tiene un par de clones, a saber, Groovy, que puede elegir entre mecanografiado y sin tipo.
Los idiomas del navegador deben interpretarse en lugar de compilarse. PHP y Python no son lenguajes de navegador. Se ejecutan en el servidor. No los juntes. Casi todo es “para el móvil” o “para la web” hoy en día. Node.js es otro extremo: un contenedor para ejecutar JavaScript fuera del navegador, lo que personalmente no haré, pero es una corrección menor. Por cierto, Java se creó primero para el navegador y todos los navegadores lo admiten: los llamados applets de Java. Sin embargo, no es HTML.
Si piensa implementar su propio lenguaje interpretado o marco universal de algún tipo, eso hace todo, pasaría algo genérico: el Objeto de Java o el vacío de C *. Me mantuve alejado de JavaScript durante años, utilizando Java “del lado del cliente” (traducido a JavaScript detrás de escena) a través de GWT. Google lo rechazó, así que no te molestes en aprender. Hasta hace poco, estaba realmente frustrado, porque una maravilla como GWT, la API de Android se basa principalmente en (los mismos patrones) ha llegado al final de su vida. Al igual que usted, me preguntaba por qué los navegadores no usarían un lenguaje del lado del servidor, por ejemplo, Groovy (Java interpretado) para escribir HTML.
- ¿Alguien ha usado wix para crear un sitio web?
- ¿Cómo es MVC diferente de PHP normal? ¿Por qué debería aprenderlo?
- ¿Cuáles son los buenos proyectos que uno puede hacer usando el web scraping?
- ¿Por qué el HTML se conoce como lenguaje de marcado?
- ¿Cuál es el punto de usar atributos de ID si los atributos de clase se pueden usar como ID?
Ellos podrian. Pero hasta que me vi obligado a rediseñar toda mi plataforma de desarrollo de GWT a JavaScript puro debido a las severas limitaciones de GWT, no aprecié la naturaleza dinámica de JavaScript, por ejemplo, agregar “métodos” a “clases” (usando la terminología OOP). Todavía no usaré Node.js en el servidor o React.js en el cliente, porque están muy lejos de los robustos frameworks OO de fuerza industrial como Spring.
Pensé mucho en React, y decidí en cambio la plantilla Groovy del lado del servidor. Facebook es una gran empresa influyente. No haría que React fuera menos una solución de OOP nacida de las limitaciones de JS. La representación de React del lado del servidor es tonta si tiene acceso a lenguajes OO fuertemente tipados normales como el combo Java / Groovy. Reaccionar es tan magnífico e incorrecto al mismo tiempo, como lo fue GWT. Nadie debe agregar patrones de OO avanzados a un lenguaje de script. Mantenlo simple. jQuery es la única “mejora” obligatoria de JavaScript.
La escritura fuerte no importa realmente. JS es tan depurable como Java. La clave no es construir jerarquías orientadas a objetos pesados con él, lo que no debe hacer de todos modos en un navegador. ¿No lo entiendes? JS es para escribir pequeños controladores de eventos, que deberían delegar todos los cálculos / lógica complejos al servidor a través de Ajax. Ese tipo de lógica pertenece al “nivel medio”. De lo contrario, volveremos a los formularios Oracle de dos niveles de alrededor de 1982.
JavaScript es un lenguaje de secuencias de comandos puramente de procedimiento con “punteros de función”, contenedores heterogéneos y administración automática de memoria. Cualquier secuencia de comandos es de procedimiento. Es una locura pensar que puedes modelar un genoma humano con él a través de una intrincada jerarquía OO. Como loco, como pensar, puede traer un centenar de esas clases detalladas más sus fachadas de interfaz de servicio y DTO en el navegador. Diferentes tipos de código pertenecen a diferentes capas.
Hay varios conceptos erróneos sobre JavaScript.
- No es el nuevo “Básico” presentar a 8y.olds a la programación en algún evento del Museo de Ciencias. No hay lenguaje digno de producción. Es robusto, elegante y debe tomarse con respeto.
- Tal vez tuve la suerte de trabajar con desarrolladores expertos de IU en lugar de diseñadores de Photoshop, que aprendieron JavaScript, su código era conciso y limpio. La gente no tiende a escribir más espagueti en JavaScript porque supuestamente es un lenguaje “fácil” y “aficionado”. De hecho, los principiantes más incompetentes han abarrotado Java en bootcamps de todo tipo, especialmente los “offshore”. He visto muchos más espaguetis de Java que los de JavaScript. Principios como SOLID y el consejo de Josh Bloch sobre inmutabilidad y medidas restrictivas inequívocas en “Java efectivo” son de poca ayuda, si el programador no tiene la capacidad de comprenderlos.
- Este no es específico de JS. Cualquiera, excepto un principiante educado en el campo de entrenamiento, entiende que un sistema de calidad industrial no se puede construir en un solo lenguaje o marco. Se pueden combinar varios idiomas en una herramienta específica: lo que estoy haciendo actualmente, pero no hay herramientas únicas para todos. Terminan hinchados de características y son buenos para nada.
Java es como un buen auto de conductor, por ejemplo, un BMW. No tolero infringir la ley, pero ¿cuántas personas se aprovechan del manejo preciso de BMW o son conscientes de las capacidades del automóvil? ¿Cuántos aspirantes a corredores que descuidadamente toman esquinas aprendiendo rápidamente los fundamentos de las curvas como la pizza de tracción y el ápice? La mayoría de los desarrolladores escriben código de procedimiento aburrido en Java: largas colecciones de métodos que llaman “clases” asistidas por tontos DTO.
