#14#1 Cuando dices "voy a hacer clic en ese enlace"... ¡que estás viendo y al que estás apuntando mentalmente! Mueves el ratón o dedo hacia él, estás encima y en los 0,01 segundos que tardas en hacer clic ha terminado de cargar nosequemierda de por arriba, se reajusta todo y haces clic en .. ¡tachán! sí, la publidad...
Yo cuando veo una web de esas, me salgo al momento... me parece una estupidez eso del scroll infinito, lo mismo con duckduckgo (encima la mierda de cambios de google, tiene su versión sin paginar...)
Si quieres ver algo, tienes que ir hasta el final para que cargue más, y encima muchas páginas no puedes siquiera darle a la tecla "fin"...
Yo no pediría que pararan de usarlo, yo pediría que dejaran al usuario elegir como quiere ver el contenido. Yo tengo claro que, en general, lo prefiero paginado. Por que además es la forma en la que te permite buscar texto en una página en condiciones.
Otra cosa que odio es cuando tienen videos que nada más acabar pasan directamente y automáticamente al siguiente, cambiando la noticia sin que puedas impedirlo, pasa en ciertos medios deportivos
#1 Cuando dices "voy a hacer clic en ese enlace"... ¡que estás viendo y al que estás apuntando mentalmente! Mueves el ratón o dedo hacia él, estás encima y en los 0,01 segundos que tardas en hacer clic ha terminado de cargar nosequemierda de por arriba, se reajusta todo y haces clic en .. ¡tachán! sí, la publidad...
El desarrollo frontend se ha convertido en un auténtico desmadre: Cargar decenas de archivos JS en ejecución para una mierda de funcionalidad que sin hacer uso de N librerias, sería una función de 4 o 5 lineas que encima va en contra de la más esencial UX y accesibilidad.
El uso intrusivo de JS que impide utilizar de la forma más básica cualquier página, y el lameculismo a las peticiones absurdas de los clientes o del diseñador que se deja llevar por las modas, han convertido a la web en un frankenstein pesado, lento e inusable.
SI una web no se puede utilizar (leer, reproducir, navegar, comprar, contactar) con el Javascript desactivado, está mal hecha.
Menos es más.
Y las listas en galerias? Cuando hablaremos de esa lacra?. Quien la tiene más grande?. Y cada posiblidad en una imagen que te lleva a otra página. Y luego dale para atrás para volver al principio...
#11 Que cada vez tengamos más memoria en los dispositivos no implica que debamos derrochar recursos por que haya desarrolladores vagos.
Puedo querer navegar con el movil y no me apetece pagar 300€ por el nuevo movil de moda que está obsoleto antes de comprarlo. O puedo querer revisar una página web mientras mato marcianitos en un videojuego. ¡Y vaya! me parece absurdo que una página web de texto y cuatro fotos chupe más memoria que el videojuego a fullhd.
A todo esto yo pediría a los diseñadores gráficos y publicistas que se ocupen de los diseños y la publicidad, pero que dejen el código web a los desarrolladores de verdad.
#15 lo que yo digo, 200 mb de fibra óptica, procesador i7 de 8 núcleos, 16GB de RAM y una puta web va lenta.
El cuello de botella de la web hoy en día son los programadores de JavaScript.
#19 no esta calculado porque no saben cuando vas a hacer clic. Es una mala implementación del código, que hasta que no carga una imagen no sabe que tamaño tiene, y se ve obligado a reajustar todo lo demas. Es evitable pero no se hace
Pues a mi me gusta mucho, yo dejaría elegir como verla, en la mayoría de los casos prefiero el scroll infinito, sobretodo si estoy leyendo cosas rápido, como revisando el timeline de Twitter.
#31 todas las de Atlassian por ejemplo, van lentas, sobre todo Jira. El propio GMail cada vez más lento lo que es el correo en sí.
Los periódicos y eso ya ni hablamos y aunque sea por publicidad ahí está.
Y casi todas las demás, porque como decían en un artículo el otro día con los ordenadores que tenemos menos de 60fps no debería de ser aceptable en nada.
La cultura de optimizar se ha perdido hace 20 años por lo menos.
#35 en casa Debian, en el curro Ubuntu o Windows 10. Máquinas parecidas. Con Chrome o con Firefox (con ese más lento), o la cosa esa de Microsoft, da igual, va lento.
Si me dices que Jira no te va lento es que tienes una percepción distinta de la velocidad, porque Jira va lento en cualquier ordenador.
#38 Hombre, si hiciera un clic en un sitio y marcara en otro sí. Si tuviera una mega fibra óptica cuántica de 30Gbps no pasaría eso, pero con mi ADSL de 10Mbps (que no llegan) y soliendo tener el emule en segundo plano..., pues me sucede.
#15SI una web no se puede utilizar (leer, reproducir, navegar, comprar, contactar) con el Javascript desactivado, está mal hecha.
¡Amén!
#20 A lo mejor deberías probar a bloquear contenido.
Desde que instalé uBlock Origin soy un poco más feliz cuando navego. Lo tengo configurado de tal manera que bloquee todo JS y demás porquería. Es flipante ver cómo algunas Webs se quedan bloqueadas al 70%, otras ni las veo directamente. En esos casos me pregunto si el contenido me va a aportar algo realmente. Casi siempre es no y entonces cierro y a seguir navegando.
Ahorro tiempo y no lleno mi cerebro de tanta basura.
#15 Dejad de decir tonterías. Sin Javascript no hay:
Llamadas AJAX
No puedes consumir API'S
No puedes hacer validaciones complejas.
No existirían las SPA.
La web dinámica volvería a ser renderizada en el lado del servidor.
No habría websockets.
#20 a mi cuando una web va lenta primero suelo pensar (y acierto normalmente ) que la culpa es del sistema operativo.
Pero habiendo visto lo que pasa cuando intentas cargar un dominio grande de más de 10.000 elementos o algunas muy mal implementadas pues no descarto que tengas toda la razón.
El otro día entré en la única página sobre el pueblo de mi abuelo buscando información sobre mi familia. El creador de la página no había puesto etiquetas ni categorías a nada y después de media hora no había pasado de septiembre de este año en las entradas.
#37 2g es un derroche, uno de 512k y tropecientos años debería servir tambien y de sobrs, 512m es muuucha memoria, hablamos de 512 millones de bytes, es increible el derroche de recursos que se acepta hoy en dia, y esto ya sin hablar de los montones de cores que por alguna razon parecen hacer falta ahora.
#24 ... a ver era una coña no coña... pero venga va ya que alguien ha contestado...
Era una coña pq a todos nos ha pasado y suele ser azar... pero no era una coña porque yo mismo lo he montado y mil personas como yo... usando mapas de calor y tiempos medio de reaccion, teniendo 4 visitas no sacas nada teniendo cientos de miles si, y pasar de un 2.4% de ctr de a un 4 o a un 5 (tengo webs con un 6 o 7% sin hacer cosas raras y no google no dice nada siempre y cuando les cuadren las cosas) hace que merezca la pena estas mierdas con la diferencia mensual.
Ahora recuerdo incluso un sitio conocido que tira las imagenes de un CDN que no es un CDN realmente y que todas las imagenes tardan 1.8segundos en cargar siempre... que puede ser mala implementacion, pues si, pero que resulta curioso cuanto menos que con conexiones con latencias grandes o minimas y 100, 300 o 600 megas sea igual siempre los tiempos...
#51 Pues en esto estoy en contra. Que sí, que es memoria. Pero los assets cada vez son de mayor calidad y para dar una mejor experiencia hay que cachear lo máximo posible (o te jodes porque la velocidad de acceso a disco físico sigue siendo una mierda). Cuanto más, mejor.
#47 Obviamente decir "Sin Javascript" es una exageración para que se entre en razón respecto al abuso de JS para la más mínima funcionalidad.
- AJAX es de los 90.
- En cualquier api RESTful se puede devolver información en el formato que se quiera: JSON, YAML... y XML / HMTL: existen los formularios y su propiedad method.
- Las validaciones del lado de cliente, deben está siempre también controladas del lado del servidor. En caso contrario es mala práctica.
- ¿Y eso es malo? Otra moda sin sentido adamsilver.io/articles/the-disadvantages-of-single-page-applications/
- ¿Y la respuesta de las API's no se tienen que "renderizar" del lado del servidor?
- Si erradicas el JS por completo claro que no, pero es algo que no tiene nada en dar un paso atrás por el abuso actual.
#15 Estoy de acuerdo contigo, pero es que hay cosas que claman al cielo. Que tenga que importar la librería 'moment.js' porque en 2018 javascript todavía es una mierda con el tratamiento de fechas, tiene guasa, por poner un ejemplo.
#33 Gmail cambió su web hace un par de semanas, y desde entonces la experiencia de usuario con una conexión lenta, es pésima. De marcar correos, darle al botón de eliminar, y tener que esperar 5-10 segundos a ver si los borra o no.
#57Las validaciones del lado de cliente, deben estar siempre también controladas del lado del servidor. En caso contrario es mala práctica.
¿Mande? Yo hago las validaciones en cliente, y conecto con un servicio WCF para escribir esos datos en la base de datos, y punto. No sé por qué motivo voy a tener que hacer un paso extra totalmente innecesario.
Respecto a las SPA, llevo más de una década trabajando con ellas, y nos ha ido de fábula. Simplemente el usuario se acostumbra a trabajar en el navegador como si tuviese abierta una aplicación de escritorio. No espera el comportamiento convencional del navegador (que son las "desventajas" que cita tu enlace).
#25 Tampoco sería muy complicado que en perfil de usuario pudiésemos elegir un theme, o al menos unos cuantos colores (botones, barra superior, etc.). De hecho, deja hacerlo cuando creas un sub.
#58 No es que se haga larga o no, si no que hay páginas donde van añadiendo contenido y todo está en esa misma página. #49 te da un ejemplo de eso. A mí me ha pasado con galerías de imágenes, que he visto alguna que me ha gustado, dos semanas después he vuelto a entrar para ver esa foto, y me he hinchado de hacer scroll para abajo y para arriba, y al final dejarlo por imposible. Habían metido más fotos diariamente, y aquello era intratable. Es como un chat de whatsapp donde todos los días escriben 100 mensajes, que si buscas algo de hace 2 semanas, te vuelves loco (y eso que whatsapp pone la fecha de cada día).
#8 Tú mismo puedes forzar las estadísticas desde javascript. Hace ya bastantes años hice un sistema de galerias para un medio digital en me pidieron que en cada foto contara como otra página vista. Fue un bombazo, todos los redactores se dedicaron a hacer fotogalerías porque de cara a los jefes, las estadísticas de tus artículos se multiplicaban por 10 y era un autoengaño. Después empecé a ver que muchas páginas se dedicaban a hacer noticias, galerías de fotos y vídeos divididas en muchas partes, así tenían más impresiones de publicidad y de visitas.
#68 ¿Sólo cargan en versión HTML por defecto? Eso no lo he visto, pero me interesa, porque cada vez que entro me toca hacer click en el enlace inferior antes que termine de cargar. Al final me he pasado a Thunderbird definitivamente para ahorrarme las interfaces ajax de todo gmail y hotmail.
#15 no estoy de acuerdo con lo último. El js permite aliviar la carga del servidor y utilizar una serie de cosas que hacen más cómoda la navegación como las peticiones asíncronas.
En lo que sí estoy de acuerdo es que la optimización se ha dejado de lado en muchos casos. La última actualización de gmail creo que es uno de los casos más sangrantes (al menos por la masividad del problema).
La mayoría de webs con scroll infinito han sido diseñados por gente que curra con Macs, donde les mola mucho hacer scroll, por eso sus ventanas no se maximizan nunca, es mejor tener un pantallón de 21" y aprovechar solo 1/6 parte para así tener scroll con el que disfrutar ese suave tacto del touchpad.
#36 Pues el jira a mi me va bastante bien. El login no, eso se lo piensa bastante, pero una vez logueado se menea bastante bien. Vamos, que nunca me ha dado esa sensacion de querer tirar el ordenador por la ventana mientras espero que cargue la puta incidencia.
#63 ¿No validas en servidor? ¿Y cómo te aseguras que un usuario no modifica el JS y te envía datos que no son válidos por ejemplo?
No tengo ni idea que es eso de WCF, pero si tu no lo haces, me imagino que WCF lo hará por tí bajo unas premisas que hallas indicado en la base de datos, sino es un agujero de seguridad enorme.
#66 En mi caso, todo el código susceptible de ser manipulado está en el cliente. El servidor es una DLL. La aplicación cliente sólo puede solicitar al servidor datos de la base de datos, o enviar datos para guardar. Las consultas son predefinidas y están en una tabla, de manera que la aplicación cliente sólo puede decir "dame los datos de la consulta con id=PROVEEDORES12", pero en ningún caso puede inyectar sql en esas consultas. Y lo mismo para guardar datos.
#77 En el servidor se valida que el cliente tenga abierta una sesión (ha tenido que hacer login). También se hace un hash de los datos enviados, y se valida en el servidor para comprobar que no han sido alterados. No tengo que validar cada campo de un formulario, si no solamente el hash, y en caso de no coincidir, rechazar esa petición.
#79 Suena interesante lo que dices de la validación mediante hash pero no me queda claro.
Generas un hash con los datos una vez validados, haces el submit y ¿con qué lo comparas en el servidor? ¿O es que pones un input hidden con un hash asociado a una session del usuario y compruebas ese hash enviado con el del servidor?
- AJAX no es de los 90 y menos en web. A finales de los 90 había iframes y era lo más parecido. Hasta inicios del 2000 en las webs no se podía cargar contenido parcial sin recargar.
- Una llamada de un API Restful no puede devolver una página web completa, bueno, no debería porque desarrollar un API para renderizar webs completas es absurdo.
- Las validaciones se deben hacer en ambos lados, ¿yo he dicho lo contrario?. En el lado del cliente por usabilidad y evitar llamadas al servidor inútiles y en el lado del servidor por seguridad y porque no siempre es una web la que consume un API, puede ser cualquier otro dispositivo.
- Las SPA una moda sin sentido..., apúntatelo y vuelve a leerlo dentro de 20 años.
- La respuesta de un API, por ejemplo si es JSON, se crea en el servidor pero es infinitamente más liviano que renderizar html e insertar los datos donde se deba hacer. Además te permite que esa API sea consumida por dispositivos móviles o integrar con sistemas de terceros.
#81 En el cliente, genero un hash que depende de los datos que voy a enviar y que incluye algunos datos de la sesión abierta. P.e., puedo enviar un id de sesión, para que el servidor sepa qué usuario está realizando la petición, y en el hash puedo incluir el timestamp del momento del login. Ese timestamp es un dato que no viaja, si no que lo tiene por un lado la aplicación cliente, y por otro lo tiene guardado el servidor desde que se hizo dicho login.
El propio hash también se envía. En el servidor recalculo el hash con los datos que me han llegado y los datos de sesión que tengo almacenados (y que no han viajado), y lo comparo con el recibido. Si no coincide, es que me han hecho una inyección, y la petición es rechazada.
#84 Entiendo. Pero entonces podría simular ese POST, pongo datos que no validan, genero el hash y te hago el submit, cuando tu recibas los datos, generas el hash con esos datos que no validan pero coincidirá el hash y por lo tanto lo tomarías como válido.
#17: A veces conviene recordar que un 486 a 66 mHz podía navegar por Inernet, leer foros con fotos, dibujitos, colorines... que alguno se piensa que Internet hace 15-20 años era en blanco y negro.
Parece mentira que con procesadores muchísimo más potentes sigamos haciendo... casi lo mismo y pensando que nuestro ordenador podría estar anticuado.
Dices que "Hasta inicios del 2000 en las webs no se podía cargar contenido parcial sin recargar" y eso es falso.
Después que "¿Que tiene que ver ActiveX, Applets de Java o VBScript en esto?" y tiene que ver mucho.
A finales de los 90 ya se utilizaba en muchísimas webs tecnologías como los objetos ActiveX, applets JAVA, VBScript y JavaScript, e incluso objetos Flash para la carga dinámica de información sin recargar de nuevo la página completa.
Siguiente cosa. Paso de escribir, te pego los párrafo y lees:
The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.
With the release of Internet Explorer 5.0, Microsoft released the first version of XMLHttpRequest (XHR), giving birth to Ajax (even though the term "Ajax" was not coined until years later.) XMLHttpRequest is an API that can be used by JavaScript, and other Web browser scripting languages to transfer XML and other text data between a page's client side and server side,[17] and was available since the introduction of Internet Explorer 5.0[18] and is accessible via JScript, VBScript and other scripting languages supported by IE browsers
Menuda panda de brontosaurios. Si quereis podemos volver a 56k para entrar a la web de Terra.
Nose si os habeis dado cuenta que en cuestion de diseño y programacion web, los que mandan son las grandes empresas.
Decir que una web esta mal hecha porque no funciona sin javascript, es una tonteria como una casa.
#89 La que cansa eres tu que quieres hacer lo blanco negro.
Dices que AJAX es de los 90 y no es cierto. Que un objeto ActiveX te permitiera a partir de marzo de 1999 ,hacer lo que haría AJAX en el futuro, no significa que AJAX fuese de los 90. Tampoco era un estándar y ni muchísimo menos se adopto ActiveX como solución para cargar contenido parcial.
#63 No sé cómo funcionan los WCF porque nunca los he usado, pero si no validas en el servidor, ¿cómo evitas que se manipulen los datos en el lado de cliente y te envíen datos sin validar?
#3 en la de scroll infinito, intenta llegar a la información que está en la página 20 desplazando por ella. Ahora hazlo en una paginada y piensa cual es más cómoda.
#87 Muy cierto, pero cada vez se van añadiendo más y más capas para facilitar que cualquiera pueda hacer sus chapuzas en la web sin aprender a programar. Y eso consume. Además, los textos predictivos y la recolección de datos en redes sociales también consume una barbaridad. Y siendo paranoica, no me extrañaría que los programas minen bitcoins con nustro idle y no tan idle.
#87... usando mosaic o similares, que no admitían css, el Javascript apenas se usaba (porque era lentísimo y no existía Ajax) y el propio Html estaba aún muy limitado
#15 decenas de miles de programadores que usan Angular, React, Vue... no están de acuerdo contigo. Esa era la teoría hace 10 años, hoy día nadie espera que no uses JS.
Yo cuando veo una web de esas, me salgo al momento... me parece una estupidez eso del scroll infinito, lo mismo con duckduckgo (encima la mierda de cambios de google, tiene su versión sin paginar...)
Si quieres ver algo, tienes que ir hasta el final para que cargue más, y encima muchas páginas no puedes siquiera darle a la tecla "fin"...
No debe ser una decisión fácil el renunciar a ello. Solo que Google un dia diga que hasta aquí.
El uso intrusivo de JS que impide utilizar de la forma más básica cualquier página, y el lameculismo a las peticiones absurdas de los clientes o del diseñador que se deja llevar por las modas, han convertido a la web en un frankenstein pesado, lento e inusable.
SI una web no se puede utilizar (leer, reproducir, navegar, comprar, contactar) con el Javascript desactivado, está mal hecha.
Menos es más.
Puedo querer navegar con el movil y no me apetece pagar 300€ por el nuevo movil de moda que está obsoleto antes de comprarlo. O puedo querer revisar una página web mientras mato marcianitos en un videojuego. ¡Y vaya! me parece absurdo que una página web de texto y cuatro fotos chupe más memoria que el videojuego a fullhd.
A todo esto yo pediría a los diseñadores gráficos y publicistas que se ocupen de los diseños y la publicidad, pero que dejen el código web a los desarrolladores de verdad.
El cuello de botella de la web hoy en día son los programadores de JavaScript.
en una raspberry pi:
cineando.plus (cartelera de cine de Zaragoza, Huesca y Teruel)
transbordoszgz.es (tiempos de espera y hora de llegada a tu destino de una línea de autobús urbano de Zaragoza)
Lo que si veo cada vez más preocupante es el alto consumo de recursos de aplicaciones nativas en ordenadores, tabletas y móviles.
Parece que se ha perdido la cultura de la optimización de código y recursos.
Los periódicos y eso ya ni hablamos y aunque sea por publicidad ahí está.
Y casi todas las demás, porque como decían en un artículo el otro día con los ordenadores que tenemos menos de 60fps no debería de ser aceptable en nada.
La cultura de optimizar se ha perdido hace 20 años por lo menos.
Porque ya te digo, he estado en trastos como Core 2 Duo y 2GB con XP y eso iba bien.
¿No estarán usando tu fabuloso ordenador para minar bitcoins?
Si me dices que Jira no te va lento es que tienes una percepción distinta de la velocidad, porque Jira va lento en cualquier ordenador.
Cualquier movil con 2gb de ram sirve para navegar o jugar, tampoco es que tengas que comprar un movil cada año, uno de hace 3 años te vale
¡Amén!
#20 A lo mejor deberías probar a bloquear contenido.
Desde que instalé uBlock Origin soy un poco más feliz cuando navego. Lo tengo configurado de tal manera que bloquee todo JS y demás porquería. Es flipante ver cómo algunas Webs se quedan bloqueadas al 70%, otras ni las veo directamente. En esos casos me pregunto si el contenido me va a aportar algo realmente. Casi siempre es no y entonces cierro y a seguir navegando.
Ahorro tiempo y no lleno mi cerebro de tanta basura.
Visto en reddit.
Llamadas AJAX
No puedes consumir API'S
No puedes hacer validaciones complejas.
No existirían las SPA.
La web dinámica volvería a ser renderizada en el lado del servidor.
No habría websockets.
En definitiva, volveríamos a los años 90.
Pero habiendo visto lo que pasa cuando intentas cargar un dominio grande de más de 10.000 elementos o algunas muy mal implementadas pues no descarto que tengas toda la razón.
Era una coña pq a todos nos ha pasado y suele ser azar... pero no era una coña porque yo mismo lo he montado y mil personas como yo... usando mapas de calor y tiempos medio de reaccion, teniendo 4 visitas no sacas nada teniendo cientos de miles si, y pasar de un 2.4% de ctr de a un 4 o a un 5 (tengo webs con un 6 o 7% sin hacer cosas raras y no google no dice nada siempre y cuando les cuadren las cosas) hace que merezca la pena estas mierdas con la diferencia mensual.
Ahora recuerdo incluso un sitio conocido que tira las imagenes de un CDN que no es un CDN realmente y que todas las imagenes tardan 1.8segundos en cargar siempre... que puede ser mala implementacion, pues si, pero que resulta curioso cuanto menos que con conexiones con latencias grandes o minimas y 100, 300 o 600 megas sea igual siempre los tiempos...
- AJAX es de los 90.
- En cualquier api RESTful se puede devolver información en el formato que se quiera: JSON, YAML... y XML / HMTL: existen los formularios y su propiedad method.
- Las validaciones del lado de cliente, deben está siempre también controladas del lado del servidor. En caso contrario es mala práctica.
- ¿Y eso es malo? Otra moda sin sentido adamsilver.io/articles/the-disadvantages-of-single-page-applications/
- ¿Y la respuesta de las API's no se tienen que "renderizar" del lado del servidor?
- Si erradicas el JS por completo claro que no, pero es algo que no tiene nada en dar un paso atrás por el abuso actual.
Toma, igual te sirve está guía de IBM: www.ibm.com/developerworks/library/wa-aj-unobtrusive/
Lo que ocurre es que los script kiddies han tomado el mundo.
wc pagina_de_meneame.txt
290 2502 13930
Creo sinceramente que todo depende de como se haga. Una página interesante y bien estructurada no se hace larga.
Si Maxwell Smart hubiera tenido un smart shoe en su época...
¿Mande? Yo hago las validaciones en cliente, y conecto con un servicio WCF para escribir esos datos en la base de datos, y punto. No sé por qué motivo voy a tener que hacer un paso extra totalmente innecesario.
Respecto a las SPA, llevo más de una década trabajando con ellas, y nos ha ido de fábula. Simplemente el usuario se acostumbra a trabajar en el navegador como si tuviese abierta una aplicación de escritorio. No espera el comportamiento convencional del navegador (que son las "desventajas" que cita tu enlace).
En lo que sí estoy de acuerdo es que la optimización se ha dejado de lado en muchos casos. La última actualización de gmail creo que es uno de los casos más sangrantes (al menos por la masividad del problema).
No tengo ni idea que es eso de WCF, pero si tu no lo haces, me imagino que WCF lo hará por tí bajo unas premisas que hallas indicado en la base de datos, sino es un agujero de seguridad enorme.
#77 En el servidor se valida que el cliente tenga abierta una sesión (ha tenido que hacer login). También se hace un hash de los datos enviados, y se valida en el servidor para comprobar que no han sido alterados. No tengo que validar cada campo de un formulario, si no solamente el hash, y en caso de no coincidir, rechazar esa petición.
Generas un hash con los datos una vez validados, haces el submit y ¿con qué lo comparas en el servidor? ¿O es que pones un input hidden con un hash asociado a una session del usuario y compruebas ese hash enviado con el del servidor?
- AJAX no es de los 90 y menos en web. A finales de los 90 había iframes y era lo más parecido. Hasta inicios del 2000 en las webs no se podía cargar contenido parcial sin recargar.
- Una llamada de un API Restful no puede devolver una página web completa, bueno, no debería porque desarrollar un API para renderizar webs completas es absurdo.
- Las validaciones se deben hacer en ambos lados, ¿yo he dicho lo contrario?. En el lado del cliente por usabilidad y evitar llamadas al servidor inútiles y en el lado del servidor por seguridad y porque no siempre es una web la que consume un API, puede ser cualquier otro dispositivo.
- Las SPA una moda sin sentido..., apúntatelo y vuelve a leerlo dentro de 20 años.
- La respuesta de un API, por ejemplo si es JSON, se crea en el servidor pero es infinitamente más liviano que renderizar html e insertar los datos donde se deba hacer. Además te permite que esa API sea consumida por dispositivos móviles o integrar con sistemas de terceros.
El propio hash también se envía. En el servidor recalculo el hash con los datos que me han llegado y los datos de sesión que tengo almacenados (y que no han viajado), y lo comparo con el recibido. Si no coincide, es que me han hecho una inyección, y la petición es rechazada.
msdn.microsoft.com/en-us/library/ms950811.aspx
msdn.microsoft.com/en-us/library/ms950807.aspx
en.wikipedia.org/wiki/ActiveX
en.wikipedia.org/wiki/VBScript
en.wikipedia.org/wiki/ActionScript
en.wikipedia.org/wiki/Java_applet
en.wikipedia.org/wiki/XSL
www.w3.org/TR/NOTE-AS
en.wikipedia.org/wiki/XMLHttpRequest
De regalo: codingninjas.co/blog/should-you-build-a-single-page-application-in-201
Parece mentira que con procesadores muchísimo más potentes sigamos haciendo... casi lo mismo y pensando que nuestro ordenador podría estar anticuado.
AJAX = Asynchronous JavaScript And XML
¿Que tiene que ver ActiveX, Applets de Java o VBScript en esto?
Lo único que tiene que ver es XMLHttpRequest y se creó en el 2000 para Outlook Web Access.
Dices que "Hasta inicios del 2000 en las webs no se podía cargar contenido parcial sin recargar" y eso es falso.
Después que "¿Que tiene que ver ActiveX, Applets de Java o VBScript en esto?" y tiene que ver mucho.
A finales de los 90 ya se utilizaba en muchísimas webs tecnologías como los objetos ActiveX, applets JAVA, VBScript y JavaScript, e incluso objetos Flash para la carga dinámica de información sin recargar de nuevo la página completa.
Siguiente cosa. Paso de escribir, te pego los párrafo y lees:
The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.
With the release of Internet Explorer 5.0, Microsoft released the first version of XMLHttpRequest (XHR), giving birth to Ajax (even though the term "Ajax" was not coined until years later.) XMLHttpRequest is an API that can be used by JavaScript, and other Web browser scripting languages to transfer XML and other text data between a page's client side and server side,[17] and was available since the introduction of Internet Explorer 5.0[18] and is accessible via JScript, VBScript and other scripting languages supported by IE browsers
Nose si os habeis dado cuenta que en cuestion de diseño y programacion web, los que mandan son las grandes empresas.
Decir que una web esta mal hecha porque no funciona sin javascript, es una tonteria como una casa.
Dices que AJAX es de los 90 y no es cierto. Que un objeto ActiveX te permitiera a partir de marzo de 1999 ,hacer lo que haría AJAX en el futuro, no significa que AJAX fuese de los 90. Tampoco era un estándar y ni muchísimo menos se adopto ActiveX como solución para cargar contenido parcial.