FROSH 2K23 Website

FROSH runs the freshers' welcome at Thapar, which means its website is the first thing an incoming batch sees of the campus. Two jobs, then: look like an event worth turning up to, and answer the question every new student is actually asking: where is anything. This is the April 2023 first pass at that, built on a personal repo. The site that actually carried FROSH 2K23 to the roughly 3,000-strong incoming batch was frosh-tiet-website, which went up on froshtiet.com three months later and handed off to frosh-ticketing for the passes.

Those two jobs pull in opposite directions, which is the interesting part. The first wants atmosphere - a full-bleed hero, depth, motion, something that reads as an event rather than a noticeboard. The second wants a map and five labels and nothing between the reader and the answer. The site resolves it by ordering: one screen of atmosphere, and then the map immediately, before the about copy and before the gallery, because a first-year who has just landed on campus is not scrolling past three sections to find the library.

The hero is five images and one listener

The landing section is a stack of layered images, each tagged with a data-speed attribute. A single scroll listener reads window.pageYOffset and translates every element carrying .translateX or .translateY by its own speed factor, so the background layers drift slower than the foreground and the scene opens up as you scroll. No parallax library, one listener, a handful of transforms.

The axis assignment is what gives it depth rather than just movement. The moon slides horizontally at 0.25 and the title slides the other way at -2, so they separate fast as you scroll; the clouds and the mountain drift vertically at 0.35 and 0.15, so the sky moves faster than the ridgeline behind it; and the foreground base is tagged 0, pinned in place at a z-index that puts it over everything except the title. Five layers, each absolutely positioned at full size with object-fit: cover, inside a 100vw by 100vh section with overflow: hidden so nothing that slides out is ever visible.

The campus map

The #campus section loads a Bing Maps control centred on 30.3382, 76.3844 and drops five labelled pushpins: Main Auditorium, Academic Block, Central Library, Hostel K and Hostel Q. That list is not decorative - those are the five places a first-year needs during welcome week, and putting them on one map replaced a paragraph of directions nobody reads.

The pins are built in JavaScript from an array of name-and-coordinate objects rather than written into markup, which is the difference between "add a location" being a one-line edit and being a markup surgery. Zoom is fixed at 16, which is close enough that the five pins fill the frame without anyone having to pan.

What shipped

• Single-scroll layout with four anchored sections (#home, #campus, #about, #gallery) reachable from a fixed navbar.
• Scroll-driven parallax on the hero, driven by per-element data-speed values on a single listener.
• Bing Maps integration through loadMapScenario(), with pushpins constructed and titled in JavaScript from a coordinate array rather than hardcoded into markup.
• A hamburger control that takes over from the link list below 992px, drawn as one bar element with ::before and ::after pseudo-elements offset nine pixels either side - three lines, one DOM node.
• Active-link styling in the nav, inverting the pill to white-on-dark for the current section.
• An overlay gallery of six campus cards - Lecture Hall, Infrastructure, LT ramp, Library, Concert, Admin Block - with each image scaling under a title overlay that fades in on hover.
• An about block for who FROSH is and what the welcome week covers, set over a full-bleed background at a minimum of one screen height.
• A responsive pass at two breakpoints - 992px for the nav collapse, 768px for the hero type scale, the map going to 95% width and 600px tall, and the gallery dropping to one card per row.
• Hand-written CSS throughout - one stylesheet, one script, no framework and no build step, which is why it deploys as three files and an images folder.

Why it was built this way

Event sites have a short, sharp life. This one needed to be up before the batch arrived, to survive a traffic spike concentrated into a few days, and to be editable by whoever inherited it next year. Static HTML, CSS and one script file does all three. The only external dependency is the Bing Maps script, and the whole thing is small enough to serve off anything.

The framework question is worth being explicit about, because the default answer in 2023 would have been React and a build step. The argument against it is the handover: the person who inherits this site is a society member who may not have Node installed, and the difference between "open index.html and change a line" and "install the toolchain, run the dev server, find the component" is the difference between the site being updated next year and being rewritten from scratch next year. For a page with four sections and one interactive control, the framework buys nothing that offsets that.

Honest scope

The nav collapse is half-finished, and it shows on phones, which is where most of the traffic came from. Below 992px the CSS hides the link list and reveals the hamburger, but no click handler was ever written for it, so the icon is decorative and there is no way to reach the section anchors from a narrow screen. The active-link styling has the same shape of gap: the class is written onto the Home link in markup and styled in CSS, but nothing updates it as sections scroll into view, so it never moves.

Smaller things. The Bing script is loaded over plain http with a callback parameter naming a function that does not exist - the map actually initialises from the body's onload instead, which works but means the callback is dead weight. The maps key is committed to the repository rather than injected at deploy time, which is the kind of thing a static site with no build step makes easy to do and hard to undo. And id="text" is reused across the hero heading and two section headings, so the ids are not unique; the CSS selects them through their section, which is why nothing visibly breaks.