This graph shows how many times the word ______ has been mentioned throughout the history of the program.
¿Por qué odias JavaScript? ¿Qué pasa con JavaScript?
No es tanto odio, más bien, mira...
Que no te gusta, no te gusta, literalmente.
Tú cuando sabes a correr tienes unos tenis preferidos, ¿no?
Sí.
Imagínate que no te puedes poner esos tenis, te vas a poner otros.
Y esos otros tenis te sacan callo.
Ah, no te das cuenta, eso es JavaScript.
JavaScript es un lenguaje de programación que nace en el 94, 2005.
Yo cuando me adentré a JavaScript, yo había trabajado con Visual Basic 6,
había trabajado con PHP,
y yo veía JavaScript, también se menosprecia JavaScript, ojo.
Sí, sí, sí.
Yo lo veía como un lenguaje de programación que era nomás para hacer animaciones, ¿no?
Cositas.
En el 2003.
De formularios, básicamente.
En el 2003, o sea, imagínate.
Sí.
Entonces, para mí era esa parte como, ok, está el lenguaje de programación,
y aparte de ese entonces estaba mucho también sonando ActionScript 2, ActionScript 3,
que eran muy parecidos, y era para situaciones parecidas, ¿no?
Animaciones, hacer todo de Flash.
Entonces, yo creo que esa parte,
yo venía de lenguajes de programación después, me metí mucho a C Sharp,
lenguaje de programación muy tipados, o sea, Java.
Entonces, en pasarme a JavaScript, a mí me costaba mucho trabajo,
porque yo estaba, a mí entender patrullo de diseño con Java me costó muchísimo trabajo,
y yo quería aplicarlos en JavaScript, y decían, a ver, ¿qué mierda es esto?
O sea, te estoy hablando de un JavaScript muy primitivo.
Claro, que no es el mismo que hay ahora.
No, no, claro que no.
De hecho, creo que ni siquiera existía el concepto de class.
O sea, entonces, hacer patrullo de diseño, pues, será muy raro, ¿no?
Pero no es que esté bien o mal hacer patrullo de diseño.
Estoy hablando de mi contexto.
O sea, por eso hablo de mi contexto.
Y cuando entiendes que realmente JavaScript está hecho como un lenguaje de programación
que tiene que ser flexible por la interactividad,
de agarrar elementos que son muy dinámicos, como el DOM,
entonces entiendes que su naturaleza, pues, es esa.
Ahora, yo no me siento cómodo hacer DOM o hacer todo lo que es Frontend,
y también es parte de eso del JavaScript que no me siento a gusto.
Pero a final de cuentas tengo que hacer Frontend.
Pero yo cuando hago Frontend utilizo TypeScript.
O sea, ya llegó TypeScript y dije, a la mierda, ya escribí, y agarré TypeScript.
Pero...
Ya ahí te quedas.
No, no, y si puedo aceptar,
JavaScript es el lenguaje de programación que desde el 2014 han crecido más,
han tenido muchísima más expansión en sus funcionalidades.
Para mí, cuando manejas Arrays con JavaScript,
es de los lenguajes de programación más fácil de utilizar Arrays.
O sea, y están creciendo y agregándole.
Y ahorita que está el concepto, ya que quieren agregar récords y tuplas,
pues, va a ser muchísimo más práctico utilizar programación funcional con JavaScript.
Lo que no sepa qué es un récord, un récord es una entidad que es inmutable.
Entonces, por sí misma ya no puedes mutarla.
Y hay mucha complejidad.
Y de repente las personas que están adentrando ese JavaScript,
porque hay muchos métodos que tienen los Arrays.
Unos son mutables, otros son inmutables.
Y de repente dice, ¡ay, mi Array se cambió, ¿no? El push.
Y ahí no mi Array, el map.
Voy a enseñar lo de los récords y las tuplas,
para que la gente, sobre todo la gente que es programadora de JavaScript, entienda.
Esto es una cosa que va a llegar al lenguaje.
No sabemos exactamente cuándo, pero están trabajando en ello.
Porque uno de los problemas que tenemos en JavaScript de forma histórica
es que si tú intentas comparar un Array o un objeto con otro Array o objeto, ¿no?
Y visualmente parecen que son lo mismo.
Por ejemplo, un Array que tiene el número 1.
Si tú haces igual, igual, igual al Array con el número 1, te va a decir false,
porque las referencias son diferentes, ¿no?
Lo que dice Héctor se refiere a esta...
Todavía no está en el lenguaje, ¿vale?
Pero están trabajando en ello.
Los récords y las tuplas van a ser dos tipos de datos nuevos
que vienen a ser tanto los objetos y los arrays inmutables, ¿vale?
No son exactamente eso, porque conceptualmente son otra cosa,
pero para que nos hagamos una idea.
Y, claro, vas a poder hacer cosas como esta, ¿no?
Puedes hacer una comparación aquí.
Si no me equivoco, estos serían los récords.
O sea, los récords son los que parecen objetos.
Y aquí teníamos la comparación de un récord, incluso con un récord anidado.
Y esto te daría true.
Bueno, esto, imaginaos, si lo tenga JavaScript,
esto nos va a volar la cabeza directamente.
Porque la verdad es que cambia un montón.
El hecho de cómo cuesta mucha gente entender los arrays,
pues si ahora ponemos las tuplas y los récords
y podemos hacer este tipo de cosas, pues va a ser tremendo.
Perdona, que era para poner contexto para que la gente estuviera ahí.
Aparte, el récord muchas veces viene acompañado de un clon.
Es decir, viene acompañado de métodos de clonación.
Que tú puedas clonar el objeto y ya es otro.
Porque muchas veces las personas que están adentrándose en la programación,
la referencia no la entienden, ¿no?
No saben qué es un paso por referencia, por valor.
Y la mutabilidad, ¿no?
Lo que es esto de que se me muta la récord,
que le va a salir las garras de lobez, ¿no?
¿Qué coño, sabes?
Y cuando estás trabajando con concurrencia,
es un infierno, si no entiendes, sin mutabilidad.
Entonces, yo creo que son las cosas...
O sea, hay que aceptar que está creciendo bastante.
Las últimas cositas que le agregaron los privados, ¿no?
También eso era como parte de lo que se pedía mucho,
el hash y la propiedad.
¿Te gusta la sintaxis de los hashes?
No, me siento raro.
Pienso que estoy en Twitter.
Es que...
Pero no había de otra, ¿no?
O sea, ¿qué puedes tener?
Claro.
Es que tienes que ponerle un símbolo o una palabra.
Podrían haber puesto la palabra clave private.
Y aparte porque las arrobas las utilizan mucho para decoradores
en los frameworks, ¿no?
O sea, no puede ser un arroba.
Pero bueno, yo creo que eso hay que aceptar, ¿no?
JavaScript al final de cuentas es un lenguaje de programación inevitable.
O sea, tarde o temprano, ¿todos saben?
Es muy raro un programador que no termina haciendo algo
en JavaScript en su vida.
O sea, mejor hace algo y se sale.
Pero es muy raro, ¿no?
Y yo, pues, al final de cuentas,
como también tengo una faceta de frontend medio frustrado,
tengo que hacer frontend al final de cuentas todos los días.
Últimamente estoy haciendo más frontend.
Entonces, tengo que utilizar, por lo menos, TypeScript,
pero no deja de utilizar JavaScript en todas formas.
Entonces, al final de cuentas,
vas agarrándole el gusto al desmadre.
Pues, no soy como que diga,
ah, JavaScript no quiero trabajar hoy, no.
Pero sí, siento que todo,
yo creo que todo mejoraría si tuviera tipos.
Eso te iba a preguntar, te iba a preguntar,
vale, no te gusta JavaScript,
pero ¿qué necesita esas tres cosas que diría?
Mira, si tuviese tres deseos
de que le llegase a JavaScript la semana que viene,
¿qué serían esas tres cosas?
Entiendo que la primera, tipos.
Sí, la segunda, yo creo que tener un mejor control de los decimales,
sin utilizar algo externo, ¿no?
Como Big Decimal o con eso sí.
Yo creo que esa es otra.
El decimal, porque a veces,
aunque tengas el tipo y transformas esas cosas medio raras,
los decimales,
sobre todo cuando estás trabajando con muchas cantidades decimales,
se hacen cosas raras.
Que hay truquitos, ¿eh?
Puedes multiplicarlo por cien, por mil,
tus cantidades,
y ya no tienes ese tipo de desplazamientos.
Pero cuando estás haciendo cosas muy de,
no sé, diez decimales, imagínate.
Entonces, yo creo que eso.
Y lo otro, yo creo que esa cosa que van a llegar a los récords.
¿Por qué?
Yo soy muy...
Me cuesta mucho trabajo hacer backend con JavaScript.
He hecho muy pocas veces backend con JavaScript.
Lo último que hice fue hace muchos años.
Cuando estaba, salió Node.js
y traía Socket.io
y el Socket.io traía esa parte de hacer
programación en tiempo real, ¿no?
Hacer Sockets de manera muy práctica.
Y eso fue lo último que he hecho con esto.
Y a mí me costaba mucho trabajo
trabajar como el tipo de situaciones de concurrencia
por el tema de la inmutabilidad.
Entonces, con los récords ya estás protegiendo
la inmutabilidad de cierta manera.
Y eso hace que ya me dé un punto extra
para decir, ok, a mejor JavaScript estaría buena idea
usarlo en el backend, pero hasta que salga el récord.
Los que no entienden estas situaciones es la siguiente.
Cuando tienes muchísima carga de data,
imagínate que esa carga de data la tienes que estar...
Va a llegar toda de muchas solicitudes.
Y estas muchas solicitudes dependen de cierto recurso...
Van a depender de un recurso en...
Todas del mismo.
¿Y qué pasa si una de estas cambia ese recurso?
¿Cómo te enteras cuál fue la que lo cambió?
Lo que se hace con la inmutabilidad
es que este recurso no cambie
y lo que haces es clonarlo y utilizarlo
y haz lo que tú quieras.
Y ya estás protegiéndolo.
Y tú dirás, yo soy un buen programador
y voy a protegerlo.
Sí, pero cuando estás trabajando en equipo,
créeme que pasan cosas muy curiosas.
Entonces ya el hecho de que el récord
te protege desde su naturaleza,
pues ya...
O sea, sí, sí hace que este tipo de trabajos
puedan ser menos tediosos.
Exacto.
Es que la mutabilidad,
el problema que tiene es que es muy,
muy difícil de detectar.
Cuando tú tienes un problema de mutabilidad
que en algún sitio,
en algún punto se está mutando,
el problema es que dices,
mierda, no tienes ni idea.
Mejor es una propiedad,
es bastante jodido.
Entonces, claro,
por eso entiendo lo que comentas.
Oye, no sé si lo sabes,
pero te lo voy a comentar
para ti y para todo el mundo,
que hay una propuesta para los decimales,
que está justamente la semana pasada,
lo estuve mirando,
que se había actualizado,
¿ves?
Que pone last week.
Se ha actualizado
y es porque están en ello.
Está en la fase 1,
pero la idea es justo lo que comentas,
¿no?
Que puedas utilizar un nuevo objeto
que se llama decimal,
que tienes una clase que puedes crearlos
y justamente lo que te ayude
es con lo que comentaban, ¿no?
Porque ves,
¿por qué JavaScript para este caso?
El problema que dices,
¿no?
Que siempre necesitamos una biblioteca
y todo esto.
Bueno, pues la idea ahora
es que tendríamos
como una biblioteca nativa
nuestra propia
para trabajar con decimales
en condiciones.
Que yo creo que estoy totalmente de acuerdo.
Es una cosa que necesita totalmente.
Así que 3.
Es que sí es loco.
3 cosas has dicho, ¿no?
Los decimales
que están trabajando en ello.
Tendríamos
los records y las tuplas
que también están trabajando en ellos.
Y el tipo.
Y los tipos.
Pero, claro,
aquí hay un temazo, Héctor,
con los tipos, ¿eh?
Porque hay un tema
y es que JavaScript,
ya sabemos que JavaScript
tiene que ser siempre, siempre,
tiene que ser retrocompatible
con todo el código.
Es una cosa que yo alucino
que la gente de esto
no lo entiende.
El otro día me decía alguien,
¿pero por qué no quitan,
¿sabes?
¿Por qué no rompen la retrocompatibilidad?
Ya, ¿sabes?
Porque este error lleva mucho tiempo.
¿Por qué no lo arreglan
y a tomar por saco?
Y yo, joder, tío,
si te lo tengo que explicar, macho,
pues, tío,
imagínate que de repente
rompes toda internet.
Porque, por ejemplo,
me decían también con CSS.
CSS ahora va a salir
la versión 4,
bueno,
que es algo de marketing, ¿vale?
Y entonces me dice alguien,
bueno,
¿y por qué no aprovechan
para arreglar el margen
que se pone por defecto al body?
Y yo,
porque entonces de repente
mitad de internet
se vería diferente,
¿sabes?
Es muy jodido.
Sí.
Y ya en su día
intentaron utilizar como tags
que ponías en el head
para decirle
qué versión usabas,
pero sería muy jodido
el hecho de que cada navegador
a ver qué versiones tiene,
las que se...
O sea,
yo no quiero abrir esa puerta.
No,
y aparte ahorita
con lo que viene,
yo estaba alucinándolo otra vez
con la realidad mixta.
Los lentes.
Imagínate todo el desarrollo
que se va a hacer
para esas nuevas interfaces
en las cuales estás mezclando
el entorno.
Yo estaba pensando,
o sea,
imagínate las aplicaciones
Frontend,
cómo van a migrar
con este tipo de cosas.
O sea,
cuando estás utilizando
el entorno,
realidad aumentada,
combinada con realidad.
Va a estar bien cabrón.
Total.
Y yo creo que aquí
es donde van a empezar
a utilizar mucho JavaScript
porque es el lenguaje
que utilizan para las pantallas,
¿no?
Se puede decir.
Pero bueno,
eso es algo mío
y estaba alucinando
solamente de qué es lo que se viene,
de la revolución
que se viene con esto.
Luego comentamos
de la revolución,
luego hablamos de la revolución,
pero mira,
vamos a comentar
dos mensajes
que nos han dejado por aquí.
Uno que es curioso,
¿no?
Que dice,
¿qué sentido,
dice Leviato,
dice,
¿qué sentido tiene cambiar
un lenguaje?
Ya deja de ser ese lenguaje.
¿Tú qué opinas?
Pero es que no es que cambie,
es que crece.
Evoluciona.
Revoluciona.
Evoluciona.
Y de hecho,
uno de esos lenguajes
de programación,
que es el,
le digo,
el Kakashi Sensei
de los lenguajes
de programación,
C Sharp,
que está copiándose todos
los lenguajes,
está agarrando cosas.
Pero es eso,
para crecer en ciertas situaciones.
Por ejemplo,
cuando tú estás trabajando
con Arrays,
te das cuenta
que cuando utilizas
el operador Spread,
el operador de JavaScript
para hacer cosas mágicas
con los objetos,
los Arrays,
en JavaScript,
pues ves que es muy fácil
trabajar con ello.
Entonces,
C Sharp también lo toma.
Yo también puedo hacerlo
para hacer azúcar sintáctica,
¿no?
Azúcar sintáctica
para escribir menos código
y hacer lo mismo.
Entonces,
es eso,
es un crecimiento,
no es que mute.
Es un crecimiento.
Es claro.
Yo creo,
justamente para contestar
lo que decía Leviato,
¿no?
¿Qué sentido tiene que cambiar
el lenguaje?
Es que tiene todo el sentido
del mundo.
Si eso es lo mejor,
aunque yo creo que a Héctor
no le guste,
estoy seguro que aprecia,
aunque no le guste JavaScript,
seguro que aprecia
su evolución.
O sea,
no puede ser el mismo.
O sea,
si ahora no le gusta,
imagínate hace 20 años
a lo mejor.
Pues 20 años
le daría la triquinosis,
seguramente,
utilizando JavaScript.
Sí,
¿te acuerdas del bar?
Joder,
el bar,
el bar,
no el de hacer vetas.
Todo global,
loco.
Sí,
sí.
El bar y las magias negras,
podías utilizar más de una vez,
poner bar A,
bar A,
podías poner 25 veces
si querías,
que no pasaba nada.
Y era global,
o sea,
y eso es parte,
es parecido
a lo de la inmutabilidad.
¿Dónde cambió la variable?
Exacto.
O sea,
que evolucionar,
yo creo que justamente
un lenguaje
se mantiene vivo,
fuerte y con salud
si no para de evolucionar.
Y yo creo que es una
de las mejores cosas
que por suerte
hace JavaScript.
O sea,
JavaScript te puede gustar
más o menos,
pero al final lo que sí que ves
es,
guau,
se está poniendo las pilas.
Hubo una época oscura
que no evolucionaba
y justamente
hubo bastante
molestia en la comunidad
de,
oye,
necesitamos tipos,
necesitamos clases.
No había clases
en JavaScript.
No había clases.
No tenía sentido.
Entonces,
no se trata de que deje
de ser ese lenguaje,
se trata de que se adecue
a los tiempos
y a las necesidades
de la gente
porque si no,
deja de ser útil
y se deja de ser útil
como PHP.
Se deja de ser útil.
No,
es broma,
es broma.
Es broma porque PHP
le pasa lo mismo
de forma positiva.
PHP ha evolucionado
un montón.
Mucha gente se ha quedado
con PHP 5,
qué asco me da PHP 5
y la versión 8.3
a mí me parece
espectacular
lo que ha evolucionado.
Es increíble.
Fíjate que yo te...
Te voy a decir
que este año
yo he trabajado mucho
con PHP,
o sea,
bastante,
diría,
y es muy distinto.
O sea,
yo he trabajado
con PHP desde el 2003.
Entonces,
yo sí he visto
sus transformaciones.
Hubo un año
en desmadre
con PHP 6
que nunca salió
y por eso también
hubo ahí
como de repente
se detuvo.
Pero sí,
ahorita PHP,
que eso sí
tiene interfaces,
PHP sí tiene interfaces,
pero tiene unas cositas
bien interesantes
llamadas traits,
rasgos traits,
que lo utilizan bastante
en Laravel,
que es que tú puedes
crear una funcionalidad,
encapsular esa funcionalidad
y hacerla...
Esa funcionalidad independiente
puedes tener
cinco funcionalidades
y anexarlas
a una clase.
O sea,
hace como el típico
la multiherencia
de una forma distinta.
Eso se me hace curioso,
pero bueno,
PHP sí ha evolucionado bastante.
Claro,
que eso es lo importante.
Yo creo que PHP
ha evolucionado un montón
y me alegro un montón
y no entiendo
la gente que le echa hate
de,
ah,
qué asco,
porque me da la sensación
que hay veces,
no sé si esto te pasa a ti
a veces, Héctor,
que se quedan como
creencias antiguas,
como la creencia esta
de solo hay que hacer
un return en una función
en mala práctica
si haces dos returns.
Como la SQL.
O SQL,
¿no?
Que no es un lenguaje,
pero SQL es un lenguaje
de programación,
¿o no, Héctor?
He visto tu vídeo.
Yo he visto el vídeo.
El lenguaje de programación,
fíjate que eso,
es parte de esto mismo,
de que las personas
se quedan con una idea
de SQL,
de que es que también
tenemos SQL
y tenemos los gestores
de base a ti,
¿no?
SQL es un estándar
y los motores
agarran este estándar
y le van agregando
sus cositas,
¿no?
Tenemos SQL Server,
Oracle,
lo que sea.
El problema es que
la gente piensa
que el estándar
se quedó en los 70s.
El último estándar
salió este año,
2023.
A partir del 99,
los sector plus-series
son parte del estándar.
Tú puedes ir a revisar
el ISO,
el ISO es de paga,
ojo,
pero puedes ir a revisar
un resumen
en Wikipedia del ISO
de ver qué cosas
se han agregado
en todos los estándares
y vas a ver
que los tropes-series
son agregados
desde el 99,
los case-when
fueron agregados
también de los 90s.
Ahorita,
lo último que se agregó
al estándar de SQL,
al estándar,
en este año,
fue los JSON,
JSON.
Los JSON para hacer,
y ya lo estamos viendo
también en los motores,
en SQL Server,
en MySQL,
en MariaDB,
y a columnas
de tipo JSON
que le dan una particularidad
como no SQL parecido,
un híbrido ahí
curioso.
Ahora,
si tú tienes procedures,
tienes variables,
tienes funciones,
dime qué le falta
para hacer un lenguaje
de programación.
Claro,
claro,
a ver,
yo sinceramente
no entiendo muy bien
la gente cuando tiene
esta polémica,
porque entiendo
si por ejemplo
una persona
quiere entender
que como lenguaje
de programación puro,
SQL,
que si vamos
a la definición
lo es,
como dice Héctor,
porque al final
puedes crear funciones,
al final puedes hacerlo,
¿no?
A día de hoy
lo puedes hacer,
pero lo que no he llegado
a entender,
porque yo puedo entender
que cada uno
piense lo que quiera,
pero lo que no puedo entender
es que la gente
se enfade,
no lo entiendo.
Sí,
se pone bien brutal
y luego digo,
ok,
pues pon tu fuente,
pero vas a la fuente liso
y el liso te dice
lo que yo he dicho,
o sea,
no lo he inventado yo.
Y luego hay estas cosas,
si SQL es lenguaje
de programación,
HTML también,
lo cual no tiene sentido,
no tiene sentido
este comentario,
porque es como decir,
como un perro
es un animal,
pues,
yo que sé,
mi armario también,
es como decir,
pero,
¿por qué?
Y hay otra cosa
bien chistosa,
me dicen,
a ver,
¿qué significa SQL,
no?
O sea,
claro,
pero bajo esa premisa,
JavaScript es Java con script,
¿no?
O sea,
los nombres no tienen mucha...
Y los nombres evolucionan,
que como decías,
SQL nació con esa misión,
que sí,
que quizás en ese momento
era un lenguaje de consultas,
pero es como CSS,
CSS yo creo que eventualmente,
y de hecho ya se acerca bastante,
puede llegar a ser
un lenguaje de programación,
porque le están añadiendo
un montón de funcionalidades
y sintaxis en las que llegar,
puede llegar a programar,
y el día que le pongan funciones,
que llegará,
ya os lo digo yo,
que va a llegar,
porque SAS tiene funciones,
y ya os digo yo,
que llegará,
que tenga funciones,
lógica,
variables y todo esto,
llegará un momento
que podría ser considerado
un lenguaje de programación,
porque tiene,
como dice Héctor,
todas las cosas
que lo definen,
pero que está bien
que entiendan,
no,
no es un lenguaje de programación,
es un lenguaje de estilos,
vale,
tienes razón,
porque el origen y tal,
pero tampoco nos vamos a enfadar,
joder,
o sea,
ya está,
la idea que cada uno lo haga
como le dé la gana,
pero que no os enfadéis,
joder.
Y es parte de lo que decías,
¿no?
Que los lenguajes cambian,
y crecen,
y al final yo creo que
todo ese tipo de debates,
en realidad,
que cada quien crea lo que quiera,
que mejor aprenda a utilizar las cosas,
y ya está,
o sea,
a veces están criticando algo
y ni siquiera saben usarlo,
no digo,
porque aprenden a usarlo.
Me parece muy interesante esta,
porque esta es la típica,
el típico de,
¿creen que HTML algún día
se vuelva un lenguaje de programación?
Y yo,
sinceramente,
creo que nunca,
bueno,
nunca,
nunca digan nunca,
pero lo veo bastante diferente a SQL,
porque HTML,
aunque sí que ha añadido elementos
que son bastante potentes,
que no es programación,
pero que sí que puedes hacer cosas
bastante chulas,
creo que no,
creo que HTML se va a quedar siempre
en la intentada semántica,
en lenguaje de marcado,
justamente para dejar esa sencillez
y separar,
y porque ya tiene un lenguaje muy cerca,
que es JavaScript,
que le puedes dar la interactividad,
entonces no tiene esa necesidad
de evolucionar hacia allí,
pero imagina que no existiese JavaScript,
pues ya podría existir una cosa
como HTMLX,
que sí que le daría cierta funcionalidad,
pero yo creo que no va a ocurrir
con HTMLX,
porque no tiene la necesidad.
Aparte,
yo creo que el caso de CSS,
que sí va más a una tendencia
a ser lenguaje de programación,
es por las necesidades
de que es un lenguaje que,
que a final de cuentas,
tienes condicionantes al poner,
por ejemplo,
colores,
o tienes animaciones
que tienen un tiempo,
o sea,
el poder intervenir
entre ese tipo de situaciones,
pues es como necesaria,
¿no?
Para que JavaScript
se dedique a lo suyo
y CSS a lo suyo.
JavaScript,
no me toques animaciones,
tú dedícate a lo tuyo,
¿no?
Y ya está.
Y de hecho es lo mejor,
¿no?
O sea,
creo que lo mejor
que tiene la programación web
a día de hoy,
¿no?
Que aunque hay mucho hate
respecto a los frameworks y tal,
pero si miramos a su base,
lo mejor que tiene
es que han sabido evolucionar
cada lenguaje
que, digamos,
es la columna vertebral
de internet
o de la web,
JavaScript,
CSS y HTML
de forma separada
y que cada uno
se dedique exactamente
a lo que tiene que hacer,
¿vale?
Porque hace unos años
sí que tuvimos estos pifostios
de utilizar JavaScript
para los estilos,
HTML para los estilos también,
entonces tenían la etiqueta Center
y yo creo que han hecho muy bien
de,
eh,
vamos a centrarnos.
de hecho hubo situaciones
cuando se combinaba PHP
junto con el HTML
donde con el PHP
imprimías con un eco
tu tag
y metías el style dentro,
¿no?
O sea,
desde el server
ya estabas especificándolo.
Todo ahí a medias,
¿no?