Frontend development: interfaces built to be changed

Frontend work here is judged on how easily the interface accepts its twentieth feature, not its first — component architecture, state boundaries, accessibility and performance on real devices.

Every frontend codebase is easy at the start. The question worth asking is what happens on the day someone needs a variant of an existing component and the honest options are to add a fifth boolean prop or to copy the file.

That moment is decided months earlier, by how the component layer was structured.

The architecture decisions that matter

  • Composition over configuration

    Components that take children and slots, so a new variant is an arrangement rather than another flag.

  • A token layer under the styling

    Spacing, colour and type defined once so consistency is structural, not a matter of everyone remembering.

  • Server state kept separate from UI state

    Cached, invalidated and refetched — not copied into a client store where it becomes a second source of truth that goes stale.

  • Accessibility as construction, not audit

    Semantic elements, real focus management and keyboard paths, which are far cheaper to build in than to retrofit.

Performance, concretely

Code splitting so a route only ships what it needs. Image pipelines with responsive transforms and lazy loading — at MS Infracon, moving asset delivery to Cloudinary cut page load time by 40%. Fonts loaded with a real fallback so text paints immediately.

Animation driven on the compositor rather than through React re-renders, and expensive libraries loaded on demand rather than in the main bundle.

Responsive means mobile first, literally

Designed from 360px upward, with layout decisions that cannot be expressed in CSS made explicitly in JavaScript rather than shipped to a phone and hidden with display:none.

Hiding a heavy component on mobile still downloads it, still parses it and still runs its effects. Not mounting it is the only version that actually helps.

Common questions

What frontend stack does Soham Dang use?

React.js and Next.js with TypeScript, Redux where state is genuinely global, and Tailwind CSS over a design token layer. Three.js and React Three Fiber where the interface needs real-time 3D.

Can Soham Dang improve an existing frontend's performance?

Yes. The usual wins are code splitting by route, an image pipeline with responsive transforms and lazy loading, deferring non-critical libraries, and moving animation off the React render path.

Is accessibility included?

Yes, as part of construction rather than a separate phase — semantic markup, keyboard navigation, visible focus states and correct labelling. Retrofitting it later costs several times more.