Si estás tomando IIC2513 Tecnologías y Aplicaciones Web en la UC, seguramente llegaste pensando que “esto es solo hacer páginas web”. La I1 se encarga de sacarte esa idea rápido: no evalúa que sepas maquetar algo bonito, sino que entiendas cómo conversan el navegador y el servidor y por qué cada pieza está donde está. Esta guía es para ti si ya pasaste IIC2413 Bases de Datos o Intro a la Programación y quieres ordenar el desorden antes del control. No es para ti si buscas un tutorial de copiar-pegar: acá la idea es entender el modelo, porque eso es lo que la prueba castiga cuando falta.

Qué evalúa realmente la I1 de IIC2513 (y qué no)

La primera prueba de IIC2513 suele concentrarse en los fundamentos conceptuales más que en escribir un proyecto completo. En la mayoría de las secciones entra el modelo cliente–servidor, el protocolo HTTP, la estructura de una aplicación web y las bases de cómo se renderiza y se pide contenido. Lo que rara vez pesa en una I1 es el despliegue en producción, la parte más avanzada de frameworks o el detalle de librerías específicas; eso llega después.

El error de enfoque más común es estudiar “haciendo” sin parar a entender el flujo completo de una petición. Puedes tener un proyecto que funciona y aun así no saber explicar qué pasa entre que escribes una URL y ves la página. La I1 pregunta justamente eso: te pide razonar sobre el sistema, no solo hacerlo andar. Si logras narrar el viaje de una petición de principio a fin, tienes más de medio control resuelto.

El modelo cliente–servidor y HTTP: la base que ordena todo

Todo en IIC2513 cuelga de una idea simple: el cliente (el navegador) pide y el servidor responde. Suena obvio, pero en la prueba se cae quien confunde qué corre en cada lado. El navegador ejecuta HTML, CSS y JavaScript; el servidor recibe peticiones, decide qué hacer y devuelve una respuesta. Nada del servidor “se ve” directamente: solo llega lo que él eligió enviar.

HTTP es el idioma de esa conversación. Tienes que manejar los métodos (GET para pedir, POST para enviar datos, PUT/PATCH para actualizar, DELETE para borrar), los códigos de estado (200 OK, 301/302 redirecciones, 404 no encontrado, 500 error de servidor) y la diferencia entre lo que va en la URL, en los headers y en el body. Una pregunta clásica te da un intercambio HTTP y te pide interpretarlo o completarlo. Practica leyendo peticiones reales desde las herramientas de desarrollador de tu navegador: ahí ves el tráfico tal cual cae en la prueba.

HTML semántico, CSS y el DOM: lo que se subestima

Mucha gente asume que esta parte es “gratis” y la deja para el final. Craso error. La I1 no te pide diseñar, pero sí que entiendas el DOM: el árbol de nodos que el navegador construye a partir del HTML y que JavaScript después manipula. Si no tienes claro que el HTML es una estructura jerárquica y no un texto plano, te vas a enredar apenas aparezca código que recorre o modifica elementos.

Del lado del HTML conviene manejar la diferencia entre etiquetas semánticas y genéricas, los formularios (qué envían, con qué método y hacia dónde) y los atributos que importan para el envío de datos. De CSS basta con lo esencial: selectores, el modelo de caja y cómo se aplica la cascada. No memorices propiedades raras; entiende cómo el navegador decide qué estilo gana. Es el tipo de razonamiento que la prueba premia.

JavaScript en el navegador: eventos, fetch y asincronía

Acá es donde muchos pierden puntos por no dominar la asincronía. En el navegador, JavaScript reacciona a eventos (un clic, el envío de un formulario) y pide datos al servidor sin recargar la página usando fetch. El punto fino es que esas peticiones no son instantáneas: son promesas que se resuelven después. Si tratas un resultado asíncrono como si ya estuviera disponible, tu razonamiento se rompe, y la prueba tiene preguntas diseñadas exactamente para pillar ese hueco.

Asegúrate de poder explicar el ciclo completo: se dispara un evento, se lanza una petición fetch, el servidor responde, y recién ahí actualizas el DOM con lo que llegó. Entender then/await y qué corre antes y qué después vale más que memorizar sintaxis. Si te preguntan por qué algo “aparece vacío” en pantalla, casi siempre la respuesta es un tema de orden asíncrono.

Backend, MVC y persistencia: cómo conectar las piezas

El servidor no es una caja mágica: en la mayoría de los cursos se organiza con el patrón MVC (Modelo–Vista–Controlador). El controlador recibe la petición, el modelo habla con la base de datos y la vista arma la respuesta. Saber dónde vive cada responsabilidad te deja resolver rápido las preguntas de “dónde pondrías esta lógica”. Y sí, acá se nota si pasaste bien IIC2413 Bases de Datos: la persistencia y las consultas reaparecen.

El concepto que ordena el backend es REST: rutas que representan recursos y métodos HTTP que definen la acción sobre ellos. Una ruta como GET /cursos/1 pide el curso con id 1; POST /cursos crea uno nuevo. Si puedes mapear una operación a su ruta y método correctos, tienes controlada una de las preguntas más frecuentes de la I1. Este razonamiento de diseño se parece al de IIC2143 Ingeniería de Software, así que si vienes de ahí, tienes ventaja.

Plan de 12 días y errores que restan puntos

Si vas contra el tiempo, reparte el estudio por bloques en vez de intentar todo junto. Este plan asume que puedes dedicar entre una y dos horas diarias:

Los errores que más restan puntos son predecibles: confundir qué corre en el cliente y qué en el servidor, tratar código asíncrono como si fuera inmediato, mezclar métodos HTTP (usar GET donde va POST) y no distinguir entre un error 400 del cliente y uno 500 del servidor. Si revisas tus controles viejos, vas a ver que casi siempre pierdes puntos en el mismo tipo de confusión: atácala primero.

Preguntas frecuentes

¿Necesito saber programar mucho para la I1? No tanto como crees. Pesa más entender el modelo (cliente, servidor, HTTP, MVC) que escribir código extenso. Con la base de IIC1103 Introducción a la Programación te alcanza para razonar el resto.

¿Cuánto entra de CSS? Lo justo: selectores, modelo de caja y cascada. No se evalúa diseño avanzado en una I1; se evalúa que entiendas cómo el navegador aplica los estilos.

¿Qué es lo que más se cae? La asincronía de JavaScript y confundir responsabilidades entre cliente y servidor. Si dominas esos dos, subes harto tu nota esperada.

¿Sirve estudiar con controles de años anteriores? Muchísimo. La estructura de la I1 se repite: leer un intercambio HTTP, razonar sobre el DOM y mapear rutas REST. Rehacer controles viejos cronometrado es la mejor práctica.

Da el siguiente paso. Si quieres llegar a la I1 con todo ordenado y ejercicios resueltos paso a paso, revisa el curso preparado para este ramo:

Ver el curso de IIC2513 en aRomperla →

Y si estás armando tu semestre completo, mira todas las guías por ramo en el hub de la UC.