Bienvenido a Internet ■Volver al BBS■ Hilo completo ▼Bajar▼

■ Este hilo se encuentra guardado en el archivo

Por que los millenials estan traumandos con Javascript? (17 respuestas)

1 : root@bienvenidoainternet.org:~# : 28/03/20(sab)14:55:52 ID:EeSQnk0c0

>portafolio sencillo
Gatsby con React y 10 dependencias mas
>aplicacion de escritorio
No se porque pero electron es la mejor opcion
>quiero cambiarle los colorcitos a mi terminal
Hare una desde cero con Electron
>trabajar con un arduino
Lo manipulare desde Node.js

2 : : 28/03/20(sab)16:23:29 ID:oLMNTuHja

Lo mismo se podría haber dicho de C en su época o de Python si estás en la U.

¿Es algo bueno, algo malo? Solo el tiempo o los papiros lo dirán.

3 : : 28/03/20(sab)19:19:05 ID:SoMDMgGh0

Zoomer del 2000 aquí.
Usaría electron sólo para programas / apps móviles para end users, cerdos corporativos y "normies" porque honestamente, la única forma de obtener interfaces modernas rápidamente, de esas que le gustan a las empresas con material design™ que hacen que a la gente normal le de un orgasmo visual.

Para todo lo demás me quedo con GTK, C y python.

4 : root@bienvenidoainternet.org:~# : 28/03/20(sab)19:19:50 ID:pnUQozKY0

Es el mal de nuestros tiempos. Hacer un sitio web ineficiente del lado del cliente. Hacer un sitio ineficiente del lado del servidor. Paradójicamente, usan nginx y mongodb porque supuestamente apache y mysql son ineficientes. El resultado es desastroso como era de esperar.

https://es.wikipedia.org/wiki/Ley_de_Wirth

5 : : 28/03/20(sab)20:06:01 ID:pnUQozKY0

Otro ejemplo de por qué se está abusando de JavaScript. El problema es sobre todo del lado del cliente. Estás ejecutando un programa al cargar una página. Ese programa tiene capacidad de realizar bastantes actividades, de las cuales solo unas pocas pide permiso. No viene firmado por una fuente de confianza como pueden ser los paquetes de una distribución, sino que puede variar el contenido en cualquier momento. Puede cargar de CDNs de terceros, solo se usan certificados para seguridad, pero no para certificar que haya habido cambios del lado del servidor que sean cuestionables. Recordemos que se puede hacer fingerprinting con tener JavaScript habilitado, por el comportamiento del mismo, midiendo tiempos de proceso. Sin canvas ni nada similar, aparte de la huella única de otras características que también lo permiten. Es casi imposible evitar fingerprinting sin JavaScript.

El problema es que cada vez más características interesantes del navegador dependen de JavaScript. Shadow DOM no permite usarse desde HTML de forma declarativa para poder disfrutar de componentes web (html y CSS aislado) que no reciban afectación del resto del CSS de la página.

Por ejemplo, no podrías mezclar PDF.js con Bootstrap porque hay resets, modifican a partir del selector universal o de elementos genéricos, y ambos lo hacen. Shadow DOM requiere JavaScript para poderlo usar.

Otro ejemplo, acceder a ubicación. ¿Por qué se requiere JavaScript? Tenemos color pickers sin Javascript en puro HTML, selector de fecha y hora en puro HTML, podemos subir ficheros con puro HTML. Entonces, ¿por qué se está forzando a habilitar un intérprete adicional, que es lento en procesadores de bajo consumo, sin que hubiera una necesidad real a la hora de diseñarlo? La geolocalización solo requiere latitud y longitud, que podrían proporcionarse de forma muy sencilla en texto plano en un elemento input, por ejemplo.

6 : : 28/03/20(sab)20:16:31 ID:pnUQozKY0

Para más información sobre shadow dom y demás:

https://dev.to/richharris/why-i-don-t-use-web-components-2cia
https://discourse.wicg.io/t/declarative-shadow-dom/1904

Y la propuesta, detenida por falta de interés por ahora, que permitiría includes del lado del cliente, todo estático:

https://github.com/whatwg/html/issues/2791

7 : root@bienvenidoainternet.org:~# : 28/03/20(sab)20:25:51 ID:1pof+i1/0

>>4
¿Mongo(lico)DB y no PostgreSQL?

8 : : 28/03/20(sab)20:27:46 ID:pnUQozKY0

>>7 usaría SQLite en mi caso. Se puede optimizar un poco con WAL. Y si tuviera mucha carga, se puede usar MariaDB con TokuDB o la que sea. Si se optimiza, vuela. Ojo, PostgreSQL también es genial, aunque todavía no le he sacado tanto partido al no haberlo utilizado demasiado en entornos de mucha carga.

9 : : 28/03/20(sab)20:40:59 ID:pnUQozKY0

Otro tema que no había comentado: aunque JS puede funcionar en asíncrono bastante bien, funciona con solamente un hilo, por lo que no es bueno escalando. Existen los web workers, pero tienen sus limitaciones. Si quieres un servidor eficiente, JS no es desde luego lo mejor. Incluso PHP rinde mejor hoy en día que Node en entornos realistas. Es cierto que el intérprete de JS de V8 está muy optimizado, pero PHP también ha mejorado y todavía tiene margen de mejora. En consumo de memoria, PHP gana.

Benchmarks al final:
https://thinkmobiles.com/blog/php-vs-nodejs/

No sé si usarn el intérprete de PHP directo o con un servidor HTTP aparte, pero además PHP puede correr asíncrono con reactphp o similar si se deseara (y para ciertas cargas es muy bueno).

Si realmente buscas eficiencia de scripts en servidor, PHP es una buena opción. Si puedes compilar, puedes considerar Go, Rust o incluso C/C++. Rust es probablemente una de las opciones que mejor combina eficiencia y seguridad.

En conclusión, hay muchas tecnologías en el mercado, pero creo que a mí también me pasó cuando era más joven, solo conocía unas pocas que me presentaban, hasta que comienzas a investigar, comparar y ver la evolución. Entonces vi que las cosas se pueden hacer de otra manera y a la vez simplificar el desarrollo y mantener las entregas rápidas. Quizás por eso la gente todavía usa WordPress, a pesar de su deuda técnica y de usar más funciones que clases en su código.

10 : root@bienvenidoainternet.org:~# : 30/03/20(lun)00:58:09 ID:rY07HmRF0

Me encanta C, sencillo y rapido

11 : root@bienvenidoainternet.org:~# : 31/03/20(mar)00:33:52 ID:???T

Creí que OP estaba exagerando hasta que me tope con https://sicp.comp.nus.edu.sg/

12 : root@bienvenidoainternet.org:~# : 31/03/20(mar)03:25:31 ID:AESaX+fba

Dios, no :(

13 : : 31/03/20(mar)18:25:19 ID:Nm7NtMod0

>El problema es sobre todo del lado del cliente
Hace un tiempo vengo trabajando en un proyecto donde se debe mantener una lógica para juegos de azar, donde el jefe de proyecto (no informático) solicitó explícitamente que el sistema fuese inmodificable dado que involucran premios en dinero y otras productos, el problema es que es todo a través de JS + HTML/CSS. Lo he dicho hasta el infinito, que todo lo que implique Javascript es inseguro a nivel de entrada/salida proveniente del usuario. Hay gente que falsea pantallazos para presentarlos ante el SERNAC en rebajas no supervisadas de precio y no lo van a hacer con un servicio que regala dinero.

14 : root@bienvenidoainternet.org:~# : 01/04/20(mie)22:14:12 ID:T5VBJgEg0

Cuando aparezcan pruebas de concepto prácticas y exploits, scripts greasemonkey y demás verás qué risas, >>13-san. Lo peor es que te echarán la culpa a ti aunque no la tengas. :o)

15 : root@bienvenidoainternet.org:~# : 01/04/20(mie)22:21:23 ID:lkeTAz5G0!

>>13
>juegos de azar
culpa tuya por meterte en un tete así

16 : root@bienvenidoainternet.org:~# : 01/04/20(mie)23:10:40 ID:kSVemb7d0

>>13
ww, todo por apoyar a los capitalistas especuladores

17 : root@bienvenidoainternet.org:~# : 01/04/20(mie)23:41:36 ID:LYTOz/am0

>>13
Avísanos de los exploits de la plataforma y nos lucramos todos.
8 KB

■ Este hilo se encuentra guardado en el archivo

weabot.py ver 0.10.9 Bienvenido a Internet BBS/IB