Infrastructure & Languages

A quick reference for how a typical web app's infrastructure fits together, and which languages make sense for frontend vs. backend work.

What infrastructure typically looks like

DNS resolves the domain to an IP before anything else happens.
CDN / Edge serves static frontend assets (HTML/CSS/JS/images) from a location close to the user, and shields the backend from that traffic.
Load balancer terminates TLS and spreads requests across multiple backend instances.
Backend / API runs the application logic and talks to the data layer.
Database stores persistent, structured data.
Cache (e.g. Redis) holds hot data in memory to avoid hitting the database on every request.
Object storage (e.g. S3) holds large unstructured files: uploads, backups, media.
Monitoring/logging runs alongside every layer to catch failures and performance issues.

Frontend languages

Language	Pros	Cons	Best use case
JavaScript	Runs natively in every browser, huge ecosystem (npm), no build step required	Dynamically typed — type errors surface at runtime, easy to write messy code at scale	Small scripts, quick prototypes, projects too small to justify a build pipeline
TypeScript	Static typing catches bugs at compile time, great editor autocomplete, superset of JS	Requires a compile/build step and extra tooling knowledge	Any medium-to-large, long-lived frontend app, especially with a team
Dart (Flutter Web)	One codebase shared with mobile/desktop apps, statically typed, decent performance	Smaller ecosystem than JS, larger bundle sizes, doesn't feel like "native" web	Apps that already share a Flutter codebase across mobile and web
Rust / C++ → WebAssembly	Near-native performance in the browser, reuse of existing native code	Awkward for DOM manipulation, steep learning curve, bigger toolchain	CPU-heavy in-browser work: image/video editing, games, simulations, crypto
Angular (TypeScript)	Full-featured framework out of the box (routing, DI, forms, HTTP), strong TypeScript integration, opinionated structure keeps large teams consistent	Steeper learning curve, more boilerplate, heavier bundle size than lighter frameworks	Large-scale enterprise single-page apps needing structure and long-term maintainability

Backend languages

Language	Pros	Cons	Best use case
Node.js (JS/TS)	Same language as the frontend, huge package ecosystem, excellent for async I/O	Single-threaded event loop struggles with CPU-heavy work	Real-time apps (chat, APIs), full-stack JS/TS teams, microservices
Python	Very readable, huge libraries (especially data/ML), fast to prototype	Slower raw execution, GIL limits true multithreading	APIs, data pipelines, ML/AI backends, internal tooling
Go	Compiles to a fast single binary, built-in concurrency (goroutines), simple language	Verbose error handling, smaller ecosystem, less expressive type system	High-throughput APIs, microservices, infrastructure/CLI tools
Java / Kotlin	Mature ecosystem, strong typing, excellent tooling, solid JVM performance	Verbose (especially Java), slower startup, heavier memory footprint	Large enterprise systems, long-running services, Android backends
C# (.NET)	Strong typing, excellent tooling, fast (ASP.NET Core), now cross-platform	Historically Windows-centric, smaller OSS community outside Microsoft's ecosystem	Enterprise apps, Windows-integrated systems, Unity game backends
Rust	Memory safety without a garbage collector, excellent performance and concurrency	Steep learning curve (borrow checker), slower development speed, smaller talent pool	Performance-critical or safety-critical services, systems programming
Scala	Runs on the JVM (full Java interop), combines OOP and functional programming, powerful type system, strong fit for concurrent/distributed systems (Akka)	Steep learning curve, slower compile times, smaller community than Java/Kotlin, flexible syntax can lead to inconsistent styles across teams	Big data processing (Spark), reactive/distributed systems needing strong type safety