EDICIóN GENERAL

¡Dejad de construir sitios web con scroll infinito! (Eng)

#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.

En definitiva, volveríamos a los años 90.
#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.

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.
#57 Las 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).
#63 se controla en el servidor para que no hay inyección de código malintencionado, entre otras cosas.
#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?
#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.
#63 ¿No validas en servidor? :shit: ¿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.
#63 eres un loco temerario. En el cliente por usabilidad, en el servidor por seguridad.
#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?
#57

- 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.
#86

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.
#88 Cansas mucho.

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
#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.

menéame