FP kickoff · Browser APIs · Real-World Tech Stack

Two things today. First, a tour of browser APIs, the free capabilities every browser hands you: localStorage to remember things, timers for delays, plus geolocation, clipboard, text-to-speech, and file upload. Second, the real-world tech stack behind a project that outgrows GitHub Pages, framed for your final project. The habit to keep: when your app needs something GitHub Pages cannot do (hide a key, store data across devices), you do not start over, you add one piece, Vercel, Cloudflare, or Supabase. The walkthroughs are in the browser APIs slides and the tech stack slides. Your final project proposal is due tomorrow, Tuesday 7/14.

• Two lightning talks: AI and the future of work, and an open-source model (LongCat2) that got popular before anyone knew who built it.
• A quick review (three poll questions) on await, hiding API keys, and separating data from logic.
• A tour of browser APIs: localStorage, setTimeout/setInterval, geolocation, clipboard, text-to-speech, and file upload.
• The real-world tech stack: when and how to move past GitHub Pages, and how to scope a project so it stays finishable.

Browser APIs are free capabilities you did not have to build. localStorage is a good example: notice it "comes from nowhere," you never declared it with const, which is the tell that the browser provides it. Use it to remember small, non-critical things (a theme choice, a display name). It stores text only, so wrap objects and arrays in JSON.stringify. Never keep passwords or API keys there, and never treat it as the source of truth, it lives in one browser on one machine and the user can clear it anytime.

Timers let things happen later, not all at once. A for loop repeats immediately; setTimeout(fn, ms) runs something once after a delay, and setInterval(fn, ms) repeats it every interval until you stop it. The reaction-time game in the slides is worth reading: a setTimeout with a random delay flips the box green, and a click listener measures how fast you reacted.

There are more of these than you will ever use, and that is fine. Geolocation (ask permission, then read position.coords), clipboard, text-to-speech, file upload (<input type="file">), reading the ?key=value tail of a URL. You do not need them all. The point: when your final project wants a capability, check whether the browser already gives it to you. The full list is MDN Web APIs.

GitHub Pages runs entirely in the visitor's browser, that is its limit. There is no server doing work when someone visits your page. That is why it cannot truly hide an API key and cannot store data that everyone shares. When you hit that wall, add one piece rather than rebuilding:

• Need to hide a key or run server code? Vercel (serverless functions) or Cloudflare sit in the middle so visitors never see the key.
• Need a real database (data that persists across devices and users)? Supabase is free and easy to start with.
• Want a real address? Buy a cheap domain (a few dollars a year) and point it at your site. Cloudflare is a good registrar; skip GoDaddy. This is optional and never required for the course, but it is how you treat a project like a real product.

Ask AI why it recommends a tech stack. One-prompt builders and coding agents reach for the "average" stack (TypeScript, React, Next) even when a plain HTML/CSS/JS page is all you need. That is not wrong, but ask the follow-up: "Why this? Is it required for a feature I actually need, or just a default?" Often you can drop it.

Scope is what you leave out on purpose. For a final project, name the one or two core features and write down what the project deliberately does NOT do. An online store's core might be "show products" and "add to cart," with logins and payments explicitly out of scope for now. Writing the "does not do" list is the best defense against a project that quietly grows until you cannot finish it.

• The Founder's Playbook — a short, practical read on building a real product with AI. Worth going through before you lock your final project scope.
• Following where AI is actually changing work, my three go-to sources: the Anthropic Economic Index (real usage data across jobs), Stanford HAI (research and public talks), and Ethan Mollick's One Useful Thing (a Wharton professor writing plainly about how people actually use AI).
• For a full list of what your browser can do, MDN Web APIs.

1. Finish your final project proposal, due tomorrow (Tuesday, 7/14). Read the final project instructions, create a new public repo first, and write a PROPOSAL.md: what it does, who it is for, and what it deliberately does not do. Make it public. Bring the idea to Wednesday, no slides needed.
2. Get ready to present on Wednesday (7/15). Two short things: (a) your MP3, name the API it uses and show where the live data appears, and (b) your final project idea. Then we pair up in breakout rooms to give each other feedback on the proposals.
3. Switch off the shared class API key. The course OpenAI key is deactivated as of today. If your MP3 or any project used it, swap in your own key (any provider) so your AI features keep working.
4. Try today's exercise: a dark-mode toggle. In your oim3690 repo, add a light/dark theme button that remembers the choice with localStorage, so the page stays in your chosen theme after a refresh. Small, and the cleanest way to feel how localStorage works.
5. Keep your weekly log current (logs/wk09.md). Write down what you built and what you learned this week, including one real AI interaction. The logs are swept at Checkpoint 5 (due Friday, 7/24), the final check of your full semester log plus a clean oim3690 repo.

Next class (Wednesday, 7/15): MP3 and final-project-idea showcase, plus proposal peer review.