En teoría ya está, pero como es una API tan grande a cada rato están los navegadores levantando la mano por que encontraron un bug o no les parece como quedó la especificación y etc, etc. Gajes del oficio de la plataforma web
@@okamiBoom why you’d want that? Pug syntax and/or JSX looks much better to me and they are already in JavaScript. I am genuinely curious about what you are looking for, I might be missing something.
@@sonemonu Por qué lo pide? Quizá el usuario aprendió python y quiere usarlo en vez de Javascript. No comprendo por qué desean usar Python para web, o para todo, cuando hay lenguajes robustos que son mejores opciones para la solución que plantean 🤦
@@Antonnyk Quieren que su lenguaje favorito sea multiuso, aunque presente falencias que otros lenguajes especialmente dedicados a la rama en cuestión no poseen.
De echo ya esta disponible para usar... quizas no va a estar siempre al dia, obviamente, pero bueno dependiendo de lo que quieras hace con tus paginas deberias preveer si usar fast html u otra cosa
@@Xardimods Ya ahí comenten el error de casarse con un lenguaje. Capaz y pierden oportunidades de trabajo porque salen con "¡Yo no uso PHP... Yo solo sé Python o solo sé React sino entonces no!" 😂
imagina un archivo remoto, que cambia dinamicamente, al ponerle el type tu podrias consultarlo y darle a entender que el formato y la forma de tratar la data debe esperarse un json! Me refiero a una url que no termina en json 😉
Porque para qué añadir a la especificación que si el nombre del fichero termina en .json hay que tratarlo por defecto como {type: "json"} y que si el nombre termina como .js hay que tratarlo por defecto como {type: "javascript" } (y que si se deja el comportamiento por defecto y esto no coincide con el content-type, se lance el respectivo error de seguridad). Solo lo pondría como obligatorio para los imports dinámicos, donde puede usarse una variable cuyo contenido apunte a cualquier tipo de cosa. Y si se me escapa algo, que se me explique... porque yo lo veo claro como el agua.
Tu propuesta tiene mucho sentido y podría mejorar significativamente la seguridad y previsibilidad en el manejo de imports. Sin embargo, el desafío principal radicaría en equilibrar flexibilidad y compatibilidad con los sistemas existentes.
@@primiti1 Sinceramente, si se rompe la retrocompatibilidad con los casos donde algún iluminado haya introducido js en un fichero `.json`... creo que incluso saldríamos ganando todos (sobretodo en seguridad), porque no se me ocurre otra razón para hacer eso más que la de intentar engañar a algún incauto... de hecho, tal como la especificación queda, seguro que más de uno cae y sigue importando ficheros `.json` sin meter el `with {type: "json"}`, entendiendo que está importando un json cuando la realidad será que estará importando un js camuflado que va a ser ejecutado.
Por defecto sin el with es Javascript. El import en si no toma en cuenta la extensión del file. Si importas un file aunque le pongas de extensión .loquesea lo importará por defecto como Javascript. Json al ser otro formato al defecto, es lo que se debe especificar. Sería interesante si se fijara en el formato del archivo importado, supongo que tendrán sus razones.
@@rolandoa.rosalesj.1661 Poco más arriba contesto el porqué eso (que como bien dices es el comportamiento por defecto) es algo que en mi opinión debe cambiarse a costa de romper la retrocompatibilidad. Y no es un simple "no me gusta" y/o "lo hace verboso" (que también)
Agregan y agregan y agregan cosas pero no agregan lo que siempre me ha parecido importante: Include de un archivo HTML a otro HTML sin necesidad de algún lenguaje server-side. No quito méritos a la importación del JSON, pero no es prioritario.
Pero he visto gente usarlo bien aunque a mi nunca me ha funcionado siempre he usabdo fetch y siento que no le veo la ventaja de usarlo importado un js si alguien me puede explicar se lo agradecería
JSON no es un lenguaje de programación sino un específico formato textual de datos. Si se quiere tragar el JSON entonces ¿hará lo mismo para el XML y el HTML que también son otros específicos formatos textuales de datos?. Además, ¿se puede importarlos en tantas veces al principio, al medio o al final del código?. Lo que me temo es que se haga un evalexpr para convertir los datos en código ejecutable. Y acerca de las operaciones de conjuntos, lo que más me ha sorprendido es la posibilidad de tener estas operaciones en las colecciones, con diferencias de funcionalidad frente a las de los conjuntos.
El proceso para añadir una feature al lenguaje es muy extricta, JSON nació de javascript, imagino simplemente se importara como si usaras JSON.parce(data) y será un objeto. Puedes usar importaciones dinámicas si quieres importar donde quieras
Creo que formato textual es un archivo .txt. JSON o JSONC es un archivo de configuracion, es como el archvo .cfg del counter. Le pones un codigo o comando para interactuar con la aplicacion, juego o sistema. Solo se usa para interactuar y eso depende de la aplicación, en linux hay muchos software que usan archivo json o jsonc.
@@TyrellDev no soy frontend pero he toqueteado un poco y mi experiencia fue que era un coñazo configurar , vengo de Java y a veces era un jaleo el uso de tipos y macros que creo que se llamaban, se sentia muy inflexible el lenguaje. Añadirle tipos a javascript mejoraría enormemente el rendimiento y mataria otros lenguajes, no se porque no lo hacen la verdad.
Así que ahora JavaScript podrá importar JSON sin 'magia negra'. ¡Por fin podré decirle a mi abuela que soy un mago de verdad!
Genial que cada cierto tiempo mejoren el lenguaje de JS :)
Totalmente!
Jo, yo esperaba que añadieran la nueva sintaxis de try catch
Midu gracias. Algo difefente para la academia un backend en rust acompañado de un front que quieras.
Y la API nueva de las fechas cuando la van a implementar?
En teoría ya está, pero como es una API tan grande a cada rato están los navegadores levantando la mano por que encontraron un bug o no les parece como quedó la especificación y etc, etc. Gajes del oficio de la plataforma web
lo de JSON es darlo firmado lo que se tenía que hacer en node 20 que ponías assert {type JSON }pero ya en estable.😊😮
Habrá que ponerse las pilas! 🎉
Y yo esperando a que ya ya saquen fast html
@@okamiBoom why you’d want that? Pug syntax and/or JSX looks much better to me and they are already in JavaScript. I am genuinely curious about what you are looking for, I might be missing something.
@@sonemonu Por qué lo pide? Quizá el usuario aprendió python y quiere usarlo en vez de Javascript. No comprendo por qué desean usar Python para web, o para todo, cuando hay lenguajes robustos que son mejores opciones para la solución que plantean 🤦
@@Antonnyk Quieren que su lenguaje favorito sea multiuso, aunque presente falencias que otros lenguajes especialmente dedicados a la rama en cuestión no poseen.
De echo ya esta disponible para usar... quizas no va a estar siempre al dia, obviamente, pero bueno dependiendo de lo que quieras hace con tus paginas deberias preveer si usar fast html u otra cosa
@@Xardimods Ya ahí comenten el error de casarse con un lenguaje. Capaz y pierden oportunidades de trabajo porque salen con "¡Yo no uso PHP... Yo solo sé Python o solo sé React sino entonces no!" 😂
las gafas que estas usando son las de TecnoNauta?
pense que ya le habian agrego tipado :/
Hola, saludos desde Republica Dominicana, ¿cuando un curso de NestJS o ADONIS?
una preguntita si el archivo acaba en JSON no se supone que es de tipo JSON? o puede haber otros tipos??
imagina un archivo remoto, que cambia dinamicamente, al ponerle el type tu podrias consultarlo y darle a entender que el formato y la forma de tratar la data debe esperarse un json!
Me refiero a una url que no termina en json 😉
Porque para qué añadir a la especificación que si el nombre del fichero termina en .json hay que tratarlo por defecto como {type: "json"} y que si el nombre termina como .js hay que tratarlo por defecto como {type: "javascript" } (y que si se deja el comportamiento por defecto y esto no coincide con el content-type, se lance el respectivo error de seguridad). Solo lo pondría como obligatorio para los imports dinámicos, donde puede usarse una variable cuyo contenido apunte a cualquier tipo de cosa.
Y si se me escapa algo, que se me explique... porque yo lo veo claro como el agua.
Tu propuesta tiene mucho sentido y podría mejorar significativamente la seguridad y previsibilidad en el manejo de imports. Sin embargo, el desafío principal radicaría en equilibrar flexibilidad y compatibilidad con los sistemas existentes.
@@primiti1 Sinceramente, si se rompe la retrocompatibilidad con los casos donde algún iluminado haya introducido js en un fichero `.json`... creo que incluso saldríamos ganando todos (sobretodo en seguridad), porque no se me ocurre otra razón para hacer eso más que la de intentar engañar a algún incauto... de hecho, tal como la especificación queda, seguro que más de uno cae y sigue importando ficheros `.json` sin meter el `with {type: "json"}`, entendiendo que está importando un json cuando la realidad será que estará importando un js camuflado que va a ser ejecutado.
Probablemente la intención es que sea explícito el tipo que quieres importar. Igual imagino mostrará error en caso de no se json
Por defecto sin el with es Javascript. El import en si no toma en cuenta la extensión del file. Si importas un file aunque le pongas de extensión .loquesea lo importará por defecto como Javascript. Json al ser otro formato al defecto, es lo que se debe especificar. Sería interesante si se fijara en el formato del archivo importado, supongo que tendrán sus razones.
@@rolandoa.rosalesj.1661 Poco más arriba contesto el porqué eso (que como bien dices es el comportamiento por defecto) es algo que en mi opinión debe cambiarse a costa de romper la retrocompatibilidad. Y no es un simple "no me gusta" y/o "lo hace verboso" (que también)
A que hora hace los directos midu hora mexico?
De 11 am a 1 pm en Twitch
Agregan y agregan y agregan cosas pero no agregan lo que siempre me ha parecido importante: Include de un archivo HTML a otro HTML sin necesidad de algún lenguaje server-side. No quito méritos a la importación del JSON, pero no es prioritario.
Cuál es la academia? 🤔
Pero he visto gente usarlo bien aunque a mi nunca me ha funcionado siempre he usabdo fetch y siento que no le veo la ventaja de usarlo importado un js si alguien me puede explicar se lo agradecería
Temporal en stage 3 no parece algo temporal lleva una eternidad ahí
Pero el promise y el import subira a youtube? 😅
jajajaja
Ufff un duro...
Y yo esperando los tipos nativos
que dias intenté importar un json sin saber que no se podia XD
Python si puede hacerlo?
Python no es para web, no se aferren
JSON no es un lenguaje de programación sino un específico formato textual de datos. Si se quiere tragar el JSON entonces ¿hará lo mismo para el XML y el HTML que también son otros específicos formatos textuales de datos?. Además, ¿se puede importarlos en tantas veces al principio, al medio o al final del código?. Lo que me temo es que se haga un evalexpr para convertir los datos en código ejecutable. Y acerca de las operaciones de conjuntos, lo que más me ha sorprendido es la posibilidad de tener estas operaciones en las colecciones, con diferencias de funcionalidad frente a las de los conjuntos.
El proceso para añadir una feature al lenguaje es muy extricta, JSON nació de javascript, imagino simplemente se importara como si usaras JSON.parce(data) y será un objeto. Puedes usar importaciones dinámicas si quieres importar donde quieras
Creo que formato textual es un archivo .txt.
JSON o JSONC es un archivo de configuracion, es como el archvo .cfg del counter.
Le pones un codigo o comando para interactuar con la aplicacion, juego o sistema.
Solo se usa para interactuar y eso depende de la aplicación, en linux hay muchos software que usan archivo json o jsonc.
yo queria el pattern matching T_T
Alguien tiene el link de la academia de midu?
God 🗿
¡VL²C!
Hola, ggggggg.
y el tipado en js para cuando? arto de la basura de ts
Podrías decirme tus motivos porque no te gusta Typescript? (para tenerlo en cuenta)
@@TyrellDev no soy frontend pero he toqueteado un poco y mi experiencia fue que era un coñazo configurar , vengo de Java y a veces era un jaleo el uso de tipos y macros que creo que se llamaban, se sentia muy inflexible el lenguaje.
Añadirle tipos a javascript mejoraría enormemente el rendimiento y mataria otros lenguajes, no se porque no lo hacen la verdad.
Amigo, TS es literalmente JS pero con tipado, no se que otra cosa diferente esperas de "js tipado"
@@SoyGriff Difícil, es una característica típica de un lenguaje de scripting, no estar tipado
Utiliza deno 2
lenguaje mal hecho