This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing
What I Built
A scroll-driven cinematic landing page...
For further actions, you may consider blocking this person and/or reporting abuse
You had me at vada pav! Nice
Thanks Bebashish!
Mahn this is outstanding
Thank You So Much Salman Bhai.
Good coverage of the fundamentals. For teams working at scale, I'd also recommend setting up strict ESLint configuration — catching these anti-patterns at lint time saves hours of runtime debugging.
Absolutely agree!! Strict ESLint rules can catch these antipatterns early and help us maintain code quality and consistency as the team grow.
Spot on. Pairing strict ESLint configs with automated CI checks ensures that consistency becomes a hard requirement before code even hits the main branch. Have you found any specific custom rules particularly useful for catching scaling-related antipatterns in your own projects?
honestly for this project there wasnt much to lint its literally vanilla html css and js with zero dependencies. but on my actual work projects yeah a fewcustom rules have saved me. no-restricted syntax to block nested ternaries that people sneak into jsx. a maxlines per function rule set to 50 because anything bigger is usually doing too much. and import no cycle which catches circular dependencies before they become that one bug nobody can trace. for scaling specifically i like no awaitinloop because sequential awaits in a loop is the number one silent perf killer ive seen in production code. people dont realize theyre making 200 api calls one at a time instead of batching. what about you any rules youve found that caught something nasty early?
It makes perfect sense to skip heavy linting for a zero-dependency vanilla project where the scope is so contained. Those custom rules for your day job are excellent, especially capping functions at 50 lines to prevent god-functions from creeping in. I usually pair import/no-cycle with strict TypeScript module boundaries to keep the architecture clean as the codebase scales. Have you found any other specific rules particularly useful for keeping JSX maintainable?
Thanks!
Excellent brother did you build using Ai?
Yes ive generated all the images using Chatgpt and bit of code polish.
The scroll-story format hits so much harder than the usual hero-features-cta grid we all copy from each other. I'm currently rebuilding my own landing after realising I'd shipped the same tired SaaS template as everyone else, and this is genuinely making me reconsider going narrative-first.
Also: no build step, no framework. Chef's kiss. I keep forgetting you can just... write HTML.
man thank you. this is exactly what i was going for. vada pav doesnt need a features section or a pricing table lol. it needed a story. and yeah i think we all forgot that html just works. no bundler no hydration no 200kb runtime for a page that literally just scrolls. good luck with your rebuild, go full narrative youll love how much simpler the design decisions become when every section either moves the story or gets deleted.
Ha, exactly what I keep re-learning. Bundler-brain is a real disease. Every time I ship something in plain HTML I remember pages used to load in 200ms and nobody had to configure anything.
Rooting for the rebuild. Post it when it's live, I want to see the story version.
bundler-brain is such a perfect name for it lol. we've all been there, spending 2 hours configuring webpack for a page that could've been done in 20 minutes with a single html file. will definitely share it when its live, drop me a follow so you dont miss it. and honestly just start with the story first, write it out like youre telling a friend, then wrap html around it. the design figures itself out when the narrative is strong.