@@helioshyperion3430 si, pero de c a c++ tiene sentido, de c++ a javascript, tiene sentido y si es cierto que "facilita" GRAN cantidad de cosas y sobre todo cambie el paradigma, el punto es adicinar complicaciones cuyo beneficio es, por decirmo menos, cuestionable!
de crear frameworks diaros, para luego hacer runtimes semanales, la humanidad supo como superarse a si misma. Ahora tendremos un nuevo JS todos los meses
Que bien, otra capa de complejidad en Javascript, junto con los frameworks infinitos que salen todos lo días, las miles de librerías para manejar cosas simples creo que lo mejor será que siga con C#
@@FranciscoRestivo96 Me explico: 1. Si ya conoces un lenguaje de backend como Java o C#: Aprender JS a un NIVEL DECENTE te toma 1 mes a lo mucho... JS es más sencillo que los lenguajes tipados y a nivel de arquitectura de software es más fácil implementar patrones en JS que en Java o C#. Hablo por experiencia propia y de mi entorno. 2. Si no conoces ningún lenguaje: Aprender JS a NIVEL BÁSICO o principiante probablemente te tome 1 mes.
Las bases siguen siendo las mismas amigo, no se me agobie. Esto te va a romper más las pelotas cuanto más alta sea la complejidad de tu trabajo con JS probablemente jajaj
La propuesta busca "Seguridad" y Performance para JavaScript, ya hay un estándar para aplicaciones compiladas y de alto rendimiento que se ejecutan en el navegador llamado WebAssembly. Esta gente si se hace una paja en la cabeza, y la propuesta escrita con Comic Sans me cago de risa jajaja.
el pepsi es el acceso al dom, a la camara y muchas apis del navegador ojalá despues la mayoria sean accesibles por webassembly y la gente escoja sus lenguajes y compliladores
@@raxis_crgamer1674 estoy igual que tú jaja, tranquilo dudo muchísimo que esto se haga realidad en ningún futuro cercano ni lejano, Javascript ya es muy maduro y simplemente crear otro estándar para satisfacer el ego de una persona es muy costoso. Esto tampoco tiene ninguna base de investigación, son solo palabrería
a mi me parece una buena idea. Hay que tomar en cuenta que en el momento en el que los navegadores entiendan otro lenguaje, automáticamente se estará iniciando el velorio de js.
Lo mejor que se puede hacer es que JS0 y JSSugar sean proyectos separados de los navegadores. Por ejemplo, JS0, al ser pequeño, sería fácil de agregar a un software que quiera utilizar JavaScript como si fuera Lua. Sin embargo, un software que desee utilizar todo, como un navegador, debería agregar JS0 y JSSugar. La ventaja es que de esta forma todos los navegadores tendrán JavaScript actualizado.
me parece que justamente lo que se busca es que los navegadores no tengan que implementar todo por un tema de costos. Entregar a las herramientas parte del trabajo para que sean los juguetes de desarrolladores pero esa sintaxis que manejarías en herramientas no los entendería el navegador sino que las herramientas escupan un código que finalmente puedan entender. O sea, en devtools solo podrían usar J0.
No está mal la propuesta ya que siempre he sentido que con JavaScript necesitas si o sí de los navegadores para que actualicen lo nuevo, algo así como una especie de monopolio... por otra parte, no me gusta depender de bundlers para poder usar javascript "moderno"... pero a quien engañamos, hoy en día todos usamos bundlers a final de cuentas jajaja
@@raul3515 Más allá del tecnicismo generaría temas emocionales y confusiones a los novatos, ya el hecho que exista babel permite hacer aquello que quieren hacer.
vaia movida, me asusta midu, suerte que te tenemos al lado para ir adaptandonos a los cambios. Lo de map sources es el arbol de parsear que explicaste el otro dia con OxC?
Básicamente un estandar que aplica para los frameworks o herramientas Sería como un typescript que en lugar de incluir los tipos de dato incluiría nuevos metodos y syntaxis?
@midulive, se podría decir que suena a lo que hacía "Apache Cordova" o "jQuery" en su momento ? Que le daba a Webview y a JavaScript funcionalidades que NO se soportaban de manera Nativa en JavaScript mientras se iban desarrollando y estandarizando ?
Pues... si en resumen es: que se delega la responsabilidad en los compiladores (Babel , Typescript..) de implementar las nuevas funcionalidades/APIs..etc entonces estoy de acuerdo SIEMPRE y CUANDO sea una forma de darle más tiempo a los motores de navegador de implementar al final las novedades.
Los frameworkeros ganaran si esto llega a suceder, por que tendras mas casos de personas que saben x framework pero no JS, en un principio todos se arrimaran a uno u otro compilador para su su versión azucarada pero inevitablemente todos querrán desarrollar sus propias features a nivel interno, nos encontraremos con diversos sabores de js, al dia de hoy un desarrollador de react puede pasar a Vue con poco esfuerzo, pero podríamos llegar a un punto de que cambiar de framework sería lo mismo que aprender otro lenguaje.
Bueno ya más o menos así funciona en la actualidad con rato framework y compiladores casi no se usa vanilla. Y durante mucho tiempo se usaba polyfills de terceros. Me gustaría más una iniciativa más fuerte como implementar una segunda opción de lenguajes se tenía pensado correr Python de manera nativa en el buscador pero ni idea de que pasó con eso.
Pues como tal ya se implementó que es webassembly, que permite traducir un lenguaje a un lenguaje compatible con el navegador, pero fuera de kotlin y alguna tecnologia concreta las empresas prefieren seguir usando javascript para el front
En ese caso no podrías usar javascript sugar en la consola del navegador. Otra cosa que podría pasar es la fragmentación del lenguaje porque ya no existiría ninguna presión en mantenerse en el estándar. Cada framework podría implementar su versión del lenguaje y los usuarios ni se enterarían.
Mis profesores: que bueno crack, ahora haz una app en js vanilla Pero profe yo ya se usar angular Mis profesores: que mierda es angular? alguna cosa moderna? no me importa, tu hazlo con js vanilla y no te olvides del backend (cree que el backend es la ui para administracion de la empresa)
Me parece raro dado que ahorita se le “pide” entre comillas a los navegadores que tengan la funcionalidad. Y esperar a que todos los navegadores tengas las mismas características El cambio que busca se entiende, pero lo malo es que ahora el desarrollador debe acoplarse a la empresa y no esta mal, pero no seria muy distinto a lo que hace google y apple con sus tiendas si quieres subir una aplicación tienes que respetar nuestros lineamientos y si no pues no se puede subir (por eso odio las apps) Si lo vemos asi no dudo que en muchos años nos empiecen a querer bloquear para subir archivos porque no respetamos sus directrices Espero a ver entendido, si no me pueden corregir
Pues como tal ya eso existe, hay cosas que no funcionan en los distintos motores, lo que proponen es que haya para todos los navegadores un lineamiento comun de que deben soportar, y el resto se va a los compiladores, asi que en teoria podrías implementar lo que quieras mientras ello sea traducible a el javascript que funciona en los navegadores
Quizás desde el punto de vista de JS parece un poco loco, pero a mí me recuerda mucho a la idea detrás de Java y otros lenguajes de la JVM. La JVM simplemente entiende el bytecode (equivalente a JS0 en este caso) y son los compiladores los que convierten Java, Groovy, Kotlin o Scala en bytecode (dichos lenguajes serían equivalentes a JSSugar). Ahora, la verdad es que a mí me gusta que esté todo en uno en el browser. Más que nada porque sería un lío tener que utilizar una sintaxis distinta en la consola de las DevTools, por ejemplo 🙁
No es la mejor idea la verdad. Lo único que realmente se es que necesitamos hacer algo con los navegadores y esa lentitud a la que implementan cosas. Los usuarios merecen mucho más, me atrevería a decir que ni la mitad de cosas que son fácilmente posibles no están ni cerca de ser implementadas pero los navegadores no dan realmente a basto (o es otra cosa, pero al final es lo mismo).
Sería más sencillo que el motor que implemente la ejecución fuese externo a los navegadores y ya está. De esa forma los navegadores solo tienen q coger uno u otro y no preocuparse de implementar nuevas features
La unica forma que esto se lograra bien seria que ellos lanzaran apis pensadas para ser usadas por los empaquetadores, sino, todo ese codigo para implementar un decorador no lo veo claro
Los navegadores por defecto usan js porque simplemente no hacer que usen typescript y dejar usar Transpilador y usar typeScript y que todo vaya apartir de alli
en realidad, yo sí estoy de acuerdo con la propuesta, es muy cansón que no pueda utilizar todas lss features de js por culpa de los distintos motores, ya que hay algunos navegadores que tienen soporte y otros no... ahora toda la responsabilidad recae de un compilador.
GOD las apps son para los usuarios; que los devs se la apañen. un usuario, alejado del desarollo web, no tiene porque saber si su navegador es compatible con cierta pagina web o no xd
entiendan, jajaj que el problema no es sustituir a javascript como lenguaje del navegador, sino sustituir todas las apis,modulos,etc. En fin sustituir todo el ecosistema es el problema.
no es por nada, pero es lo que yo pensaba que hacian los navegadores y por eso tanta traskilada. Según lo veo, quienes lo tienen duro son las librerias que se usan para añadir código en el front, verdad, porque todo lo otro ya va masticado sólo para que se lo trague el navegador... o por lo menos es lo que yo pensé. Igual, al final lo que van a pedir es que todo se compile a webassambly y html, para que el cliente esté satisfecho.
Las ideas técnicas pueden viables o no sin embargo hay que tener en cuenta que el desarrollo de los motores de JS está hoy en día monopolizado y dirigido principalmente por Google cuyos intereses no necesariamente tienen que ver con buscar una mejora técnica sin tener en cuenta su posicionamiento en el mercado. Para los desarrolladores sería excelente que el engine quede reducido al mínimo o que se estandarice la máquina virtual subyacente sea cual sea, sin embargo, desde la lógica de negocio no sería nada conveniente para Google (principalmente) darle libertad a los desarrolladores. Nadie va a resignar su posición en el mercado a menos que pueda reemplazar lo que acepta perder por una nueva dependencia que los agarre a todos aún más de los hue..vos
Básicamente, los que mantienen los motores de los navegadores dicen, estamos hasta los hu..vos de que ustedes mentan cosas en el lenguaje y despues nosotros tener que modificar nuestros motores para añadirlas, no no no, a mi me das un js base o cero y ustedes busquence la vida para igual que transpilan el TS a JS pues me lo recompilas, transpilas o chupilas todo y me das el js base que es lo que yo voy a usar y no me den mas el coñazo.
los navegadores son drenadores de recursos, el solo tenerlos abiertos ya genera un drenado de recursos increible si existe una manera de ahorrar esto sin perder la estandarizacion, no veo el problema, en general la propuesta esta bastante bien
Por fin, mi misión ha terminado.
XD
JAJAJAJAJA
Estaba buscando tu comentario xDD
jajajaja
"Change da world, my final message. Goodbye"
El compilador del compilador del compilador del compilador del compilador del compilador del compilador del compilador del compilador
por cosas como esa extrañamos algunos a jquery
compila
De eso se trata los lenguajes de alto nivel
😂😂
@@helioshyperion3430 si, pero de c a c++ tiene sentido, de c++ a javascript, tiene sentido y si es cierto que "facilita" GRAN cantidad de cosas y sobre todo cambie el paradigma, el punto es adicinar complicaciones cuyo beneficio es, por decirmo menos, cuestionable!
de crear frameworks diaros, para luego hacer runtimes semanales, la humanidad supo como superarse a si misma. Ahora tendremos un nuevo JS todos los meses
😂😂😂😂
XD
Y el acumulado de todos esos JS, trabajando en simultáneo. Puta, qué ofertón 🤣
Me parece bien la idea de hacer como un compilador general estilo web assembly asi evitar que ciertos navegadores tengan ciertas cosas que otros no.
Que bien, otra capa de complejidad en Javascript, junto con los frameworks infinitos que salen todos lo días, las miles de librerías para manejar cosas simples creo que lo mejor será que siga con C#
@@evelop3625 pues no debes usar todos mano 😅
que te quejas, si el 80% del trabajo se lo vasa dar al gpt
@@helioshyperion3430 sapbeeee😂
@@evelop3625 Viva C# con este se puede hacer de todo y más con .NET
30 años después a vueltas con el Javascript, un 'lenguaje muy bien parido'
La cámara: "ESTOY CANSADO JEFE".jpg
Honey wake up a new JavaScript just dropped
Jajajaja 😂 me hiciste el día.
Uno aprendiendo y me vienen con esto
@@Gax-x5n jajajaja ya sé
No te preocupes, para aprender JS decentemente te tomará 1 mes y eso...
@@jeysonsoto5343 que? Saber js realmente lleva mucho tiempo
@@FranciscoRestivo96 Me explico:
1. Si ya conoces un lenguaje de backend como Java o C#:
Aprender JS a un NIVEL DECENTE te toma 1 mes a lo mucho... JS es más sencillo que los lenguajes tipados y a nivel de arquitectura de software es más fácil implementar patrones en JS que en Java o C#. Hablo por experiencia propia y de mi entorno.
2. Si no conoces ningún lenguaje:
Aprender JS a NIVEL BÁSICO o principiante probablemente te tome 1 mes.
Las bases siguen siendo las mismas amigo, no se me agobie. Esto te va a romper más las pelotas cuanto más alta sea la complejidad de tu trabajo con JS probablemente jajaj
La propuesta busca "Seguridad" y Performance para JavaScript, ya hay un estándar para aplicaciones compiladas y de alto rendimiento que se ejecutan en el navegador llamado WebAssembly.
Esta gente si se hace una paja en la cabeza, y la propuesta escrita con Comic Sans me cago de risa jajaja.
😐🙃🤣
el pepsi es el acceso al dom, a la camara y muchas apis del navegador ojalá despues la mayoria sean accesibles por webassembly y la gente escoja sus lenguajes y compliladores
@@otaxhu hola disculpa, la vdd no entiendo que va a cambiar en javascript, me puedes explicar?
@@raxis_crgamer1674 estoy igual que tú jaja, tranquilo dudo muchísimo que esto se haga realidad en ningún futuro cercano ni lejano, Javascript ya es muy maduro y simplemente crear otro estándar para satisfacer el ego de una persona es muy costoso. Esto tampoco tiene ninguna base de investigación, son solo palabrería
@@otaxhu y si llegara a hacerse esto, que pasaría, que afectaría en el modo de uso?
No le creo a ninguna presentación en Comic Sans 😂
@@pablomorales3797 AJAJAKSHAHSHAG
Ufa, que kk lo de la imcompatibilidad en los navegadores... solución: ¡metámosle más capas para volverlo más imcompatible!
definitivamente a mucha gente le viene bien complicar las cosas !
@@gilbertobarbosa5136 a que gente?
@@piergox512 la gente que vende "soluciones" (frameworks, libros, librerías, clouds, cursos, etc)
Los mercaderes del código
Hacer Web antes era más sencillo.
Pese a todo lo que puede traer consigo esto, es emocionante, me gusta mucho la propuesta
El vídeo debería llamarse: "jQuery vuelve de entre los muertos - La propuesta"
Pero no tiene nada que ver con jQuery 😅😂
@@midulive si, muchos con esa idea, de complicar mas las cosas, diremos que "extrañamos la simpleza de Jquery" ...
@@gilbertobarbosa5136 simpleza? yo no diria eso de jquery
@@juandavid-fl7pbentiendo por qué lo dirías, en mi caso que aún lo uso, si me parece más simple
@@juandavid-fl7pb th-cam.com/users/shortsvBbKpSwbZW8?si=3c0t0b1z1i0brUqJ
a mi me parece una buena idea. Hay que tomar en cuenta que en el momento en el que los navegadores entiendan otro lenguaje, automáticamente se estará iniciando el velorio de js.
Cómo cual?
Ya lo hace con webassembly
@@FranciscoRestivo96 cualquier lenguaje, java, c#, c++, que son lenguajes fuertes y sin los problemas que tiene javascript.
@@2005bgva js no tiene ningún problema. Lo tienen los q no son capaces de comprender como funciona 🥱
Me recuerda mucho a postgres, que hay modulos que puedes activar o desactivar Al compilar
esto nos viene a recordar, que absolutamente todo es temporal, hasta javascript como lo conocemos.
Y por esa razón simplemente estudié lo suficiente para que el frontend funcione y me especialicé en PHP
Nice!
Y esto en que afecta al poderosísimo PHP?
reemplazado próximamente
@@alexisvillegas1953 Por cuál?
@@alexisvillegas1953 tienen como 20 años queriendo reemplazarlo y todavía sigue en todas partes.
não sabia que o php trabalhava no la do cliente, ou abestalhado
la tontería mató a PHP....
Me huele a un JavaScript Development Kit y un JavaScript Runtime Environment. 😆
Me huele a mierda, sinceramente
Lo mejor que se puede hacer es que JS0 y JSSugar sean proyectos separados de los navegadores. Por ejemplo, JS0, al ser pequeño, sería fácil de agregar a un software que quiera utilizar JavaScript como si fuera Lua. Sin embargo, un software que desee utilizar todo, como un navegador, debería agregar JS0 y JSSugar. La ventaja es que de esta forma todos los navegadores tendrán JavaScript actualizado.
me parece que justamente lo que se busca es que los navegadores no tengan que implementar todo por un tema de costos. Entregar a las herramientas parte del trabajo para que sean los juguetes de desarrolladores pero esa sintaxis que manejarías en herramientas no los entendería el navegador sino que las herramientas escupan un código que finalmente puedan entender. O sea, en devtools solo podrían usar J0.
@@JoseAlvarado-vd3ql pero como ellos lo quieren hacer va hacer que los proyectos pesen mucho mas de lo normal.
Básicamente hacer de JS una especie de JS compilado. Me gusta, ¡a ver si seguimos usando JS/TS pero detrás de JS0 está WASM!
Js0 jssuggar... Eso es lo que Java desde el siglo pasado... Con lo desordenado que crecen las herramientas de JS me imagino 20 tipos más de JS...😮
Enloqueció Javascript
PD: Que no se note la copia a St James SanN
No está mal la propuesta ya que siempre he sentido que con JavaScript necesitas si o sí de los navegadores para que actualicen lo nuevo, algo así como una especie de monopolio... por otra parte, no me gusta depender de bundlers para poder usar javascript "moderno"... pero a quien engañamos, hoy en día todos usamos bundlers a final de cuentas jajaja
Más tarda preparar un café que JS en sacar una nueva cosa.
que todo mundo programe en lo que se le de la gana, compilen a webassembly, y webassembly tenga acceso al dom eso estaria mas cool
No me puedo tomar en serio una presentación en cómic sans
No creo que esté mal, incluso creo que es mejor, así adiós preocupación si x propiedad es soportada en tal navegador
Es que no es solo eso
@@weengineers5999 y que más crees que implica? Adelante te leo amigo
@@raul3515 Más allá del tecnicismo generaría temas emocionales y confusiones a los novatos, ya el hecho que exista babel permite hacer aquello que quieren hacer.
vaia movida, me asusta midu, suerte que te tenemos al lado para ir adaptandonos a los cambios. Lo de map sources es el arbol de parsear que explicaste el otro dia con OxC?
Básicamente un estandar que aplica para los frameworks o herramientas
Sería como un typescript que en lugar de incluir los tipos de dato incluiría nuevos metodos y syntaxis?
@midulive, se podría decir que suena a lo que hacía "Apache Cordova" o "jQuery" en su momento ? Que le daba a Webview y a JavaScript funcionalidades que NO se soportaban de manera Nativa en JavaScript mientras se iban desarrollando y estandarizando ?
Pues... si en resumen es: que se delega la responsabilidad en los compiladores (Babel , Typescript..) de implementar las nuevas funcionalidades/APIs..etc entonces estoy de acuerdo SIEMPRE y CUANDO sea una forma de darle más tiempo a los motores de navegador de implementar al final las novedades.
Me suena algo similar a lo de java, sueltan la especificación y la implementación dependerá del JDK. Similar a lo de jakarta.
Los frameworkeros ganaran si esto llega a suceder, por que tendras mas casos de personas que saben x framework pero no JS, en un principio todos se arrimaran a uno u otro compilador para su su versión azucarada pero inevitablemente todos querrán desarrollar sus propias features a nivel interno, nos encontraremos con diversos sabores de js, al dia de hoy un desarrollador de react puede pasar a Vue con poco esfuerzo, pero podríamos llegar a un punto de que cambiar de framework sería lo mismo que aprender otro lenguaje.
Bueno ya más o menos así funciona en la actualidad con rato framework y compiladores casi no se usa vanilla.
Y durante mucho tiempo se usaba polyfills de terceros.
Me gustaría más una iniciativa más fuerte como implementar una segunda opción de lenguajes se tenía pensado correr Python de manera nativa en el buscador pero ni idea de que pasó con eso.
Pues como tal ya se implementó que es webassembly, que permite traducir un lenguaje a un lenguaje compatible con el navegador, pero fuera de kotlin y alguna tecnologia concreta las empresas prefieren seguir usando javascript para el front
Bueno llego el momento de aprender python
Lo primero sería un compilador base de js0, y que los editores de código lo implementen, algo así como js0make versión x.xx.xx.
No puedo tocar en serio una presentación en comic sans
JavaScript, Babel & TypeScript inician un ménage a trois
Medio incestuoso el menage a trois ese
But llega Kotlin Multiplatform y Jetpack Compose Multiplatform a salvar a los pibes
Javascript se convirtio en Java tan gradualmente que no me di cuenta
En ese caso no podrías usar javascript sugar en la consola del navegador. Otra cosa que podría pasar es la fragmentación del lenguaje porque ya no existiría ninguna presión en mantenerse en el estándar. Cada framework podría implementar su versión del lenguaje y los usuarios ni se enterarían.
No me extrañe que se apague la cámara al final, mucho estaba aguantando el ordena sin rebelarse jejeje
Midu, cual es tu personaje favorito de one piece :D
Exijo que midu responda!!!
ward
Lentamente Javascript se va convirtiendo en Java
Mis profesores: que bueno crack, ahora haz una app en js vanilla
Pero profe yo ya se usar angular
Mis profesores: que mierda es angular? alguna cosa moderna? no me importa, tu hazlo con js vanilla y no te olvides del backend (cree que el backend es la ui para administracion de la empresa)
Me parece raro dado que ahorita se le “pide” entre comillas a los navegadores que tengan la funcionalidad. Y esperar a que todos los navegadores tengas las mismas características
El cambio que busca se entiende, pero lo malo es que ahora el desarrollador debe acoplarse a la empresa y no esta mal, pero no seria muy distinto a lo que hace google y apple con sus tiendas si quieres subir una aplicación tienes que respetar nuestros lineamientos y si no pues no se puede subir (por eso odio las apps)
Si lo vemos asi no dudo que en muchos años nos empiecen a querer bloquear para subir archivos porque no respetamos sus directrices
Espero a ver entendido, si no me pueden corregir
Pues como tal ya eso existe, hay cosas que no funcionan en los distintos motores, lo que proponen es que haya para todos los navegadores un lineamiento comun de que deben soportar, y el resto se va a los compiladores, asi que en teoria podrías implementar lo que quieras mientras ello sea traducible a el javascript que funciona en los navegadores
@@juanpablogarcia6293 gracias!! ya me quedo claro.
Quizás desde el punto de vista de JS parece un poco loco, pero a mí me recuerda mucho a la idea detrás de Java y otros lenguajes de la JVM. La JVM simplemente entiende el bytecode (equivalente a JS0 en este caso) y son los compiladores los que convierten Java, Groovy, Kotlin o Scala en bytecode (dichos lenguajes serían equivalentes a JSSugar).
Ahora, la verdad es que a mí me gusta que esté todo en uno en el browser. Más que nada porque sería un lío tener que utilizar una sintaxis distinta en la consola de las DevTools, por ejemplo 🙁
Hola, disculpa será que me podrías explicar que cambia en javascript, la vdd no entiendo
Kotlin + WASM es una dupla muy buena
No es la mejor idea la verdad.
Lo único que realmente se es que necesitamos hacer algo con los navegadores y esa lentitud a la que implementan cosas. Los usuarios merecen mucho más, me atrevería a decir que ni la mitad de cosas que son fácilmente posibles no están ni cerca de ser implementadas pero los navegadores no dan realmente a basto (o es otra cosa, pero al final es lo mismo).
Si me dieran una moneda por cada vez que dicen que ahora si se ira Javascript tendria más dinero del que me deja programar en Cobol...
Así es el ciclo de vida, se muere un software y se nace otro software.
😂😂😂😂 ahora que framework será nuestro sugar 🥰
Javascript se está complicando un poco más, lo bueno es que tenemos la solución y es complicarlo más
que mouse usan? el mio ya no anda bien y ando viendo opciones tengo el g305 🤓
MX Master 3S
Yo he empezado a usar trackball y es bastante cómodo. Uso este modelo: ProtoArc em03.
yo uso uno vertical desde que me dio tendonitis, en concreto uso el Logitech MX Vertical
Sería más sencillo que el motor que implemente la ejecución fuese externo a los navegadores y ya está. De esa forma los navegadores solo tienen q coger uno u otro y no preocuparse de implementar nuevas features
Sigo diciendo que Javascript es una ensalada que lastimosamente debemos usar
No puede ser, espero que esta propuesta se quede en lo que es, porque simplemente es complicar muchas cosas.
La unica forma que esto se lograra bien seria que ellos lanzaran apis pensadas para ser usadas por los empaquetadores, sino, todo ese codigo para implementar un decorador no lo veo claro
pero lpm midu yo me iba a poner a estudiar js despues de los parciales
Osea vamos a volver a php sera llamarlo PJP
Al final cambiaron el nombre de web asembly a jssugar jaajjaa
6:26 JS0 seria LLVM y JSSugar seria c, c++, rust
Yo creo que al final tendríamos cosas parecidas al electron, tauri y cualquiera de sus competidores
Sería válido hacer una analogía con el JDK y el JRE en el caso de Java?
Los navegadores por defecto usan js porque simplemente no hacer que usen typescript y dejar usar Transpilador y usar typeScript y que todo vaya apartir de alli
en realidad, yo sí estoy de acuerdo con la propuesta, es muy cansón que no pueda utilizar todas lss features de js por culpa de los distintos motores, ya que hay algunos navegadores que tienen soporte y otros no... ahora toda la responsabilidad recae de un compilador.
Hola disculpa, me podrías explicar bien que es lo que cambia, y esto sería algo bueno o malo o como?
Leyendo entre lineas, lo que quieren es: ir mas alla del browser y meterse a estandarizar las tools.
GOD
las apps son para los usuarios; que los devs se la apañen.
un usuario, alejado del desarollo web, no tiene porque saber si su navegador es compatible con cierta pagina web o no xd
Para mi que el futuro es web assembly sinceramente
Que maravilla
entiendan, jajaj que el problema no es sustituir a javascript como lenguaje del navegador, sino sustituir todas las apis,modulos,etc. En fin sustituir todo el ecosistema es el problema.
no es por nada, pero es lo que yo pensaba que hacian los navegadores y por eso tanta traskilada.
Según lo veo, quienes lo tienen duro son las librerias que se usan para añadir código en el front, verdad, porque todo lo otro ya va masticado sólo para que se lo trague el navegador... o por lo menos es lo que yo pensé.
Igual, al final lo que van a pedir es que todo se compile a webassambly y html, para que el cliente esté satisfecho.
No me asustes midu
me cansé de contar las veces que este man ha anunciado el fin de algo este año
Las ideas técnicas pueden viables o no sin embargo hay que tener en cuenta que el desarrollo de los motores de JS está hoy en día monopolizado y dirigido principalmente por Google cuyos intereses no necesariamente tienen que ver con buscar una mejora técnica sin tener en cuenta su posicionamiento en el mercado. Para los desarrolladores sería excelente que el engine quede reducido al mínimo o que se estandarice la máquina virtual subyacente sea cual sea, sin embargo, desde la lógica de negocio no sería nada conveniente para Google (principalmente) darle libertad a los desarrolladores. Nadie va a resignar su posición en el mercado a menos que pueda reemplazar lo que acepta perder por una nueva dependencia que los agarre a todos aún más de los hue..vos
Yo creo que llegó el momento de quitarle features a js. La propuesta de js0 y jsusgar le daría una oportunidad a la competencia de google como Firefox
y por qué no bytecode? o WASM que permita acceder al DOM?
Que mal lo de Javascript y lo de tu camara tambien 😂
Un BLOB de WebAssembly en vez de texto plano de lenguaje visible de JavaScript es una amenaza a la seguridad de los ordenadores clientes.
¿Entonces para el desarrollador promedio que tanto cambiaría lo que uno hace?
que ya integren de nuevo el motor de dart a chromium
Mataroooon mataron a un inocente 🎶🎵
Y xq no se centran en wasm?
suena como si quisieran hacer una JVM JAJAJAJA
Madre mia esta gente vive en jupiter, yo trabajao en web3 y uso bigint todos y cada uno de los dias
Lo seguiré usando no importa 😅
Básicamente, los que mantienen los motores de los navegadores dicen, estamos hasta los hu..vos de que ustedes mentan cosas en el lenguaje y despues nosotros tener que modificar nuestros motores para añadirlas, no no no, a mi me das un js base o cero y ustedes busquence la vida para igual que transpilan el TS a JS pues me lo recompilas, transpilas o chupilas todo y me das el js base que es lo que yo voy a usar y no me den mas el coñazo.
chupilas... 😂
los navegadores son drenadores de recursos, el solo tenerlos abiertos ya genera un drenado de recursos increible
si existe una manera de ahorrar esto sin perder la estandarizacion, no veo el problema, en general la propuesta esta bastante bien
Mierda ahora que me aprendi 50 frameeorks de js
Como es planteado los frameworks no cambiarian nada, solo abria que preparar los navegadores y compiladores
Pues podrían compilar Javascript to wasm y el motor de los exploradores solo ejecuten wasm
Mejor nos pasamos al mundo Kotlin o Python y sus frameworks para web
y node.js qué haría ?
Me parece una mala idea. Ahora si quieres debuguear o hacer pequeños códigos en el browser me obligarán a usar un ide de la nube??
No entiendo.
JS0 no vendria a ser vanilla y JSSugar TS? No es lo mismo que tenemos ahora con otros nombres? lol
Mi humilde reacción: xd
El error inicial fue haber cambiado scheme por javascript
Para los usuarios significa para los navegadores. Y eso de que los bigint no se han utilizado es falso, todo el mundo blockchain y financiero los usa.
La solución es volver a usar JQuery 😌
Performance, menor consumo de recursos por el mismo resultado $
Todavía ni aprendo bien JS , y ya lo van a cambiar XC