Choosing a tech stack is one of the most consequential decisions in a web project. Get it right and development is smooth, performance is excellent, and maintenance is manageable. Get it wrong and you’re fighting your tools for years.
The problem is that most tech stack discussions are driven by hype, not by your actual needs. Here’s a practical framework for making the right choice.
Start with your constraints, not the technology
Before looking at any framework or language, answer these questions:
What does the application actually need to do? A content website, a real-time dashboard, an e-commerce platform, and a data processing pipeline have fundamentally different requirements. The right stack for one may be wrong for another.
What’s your team’s expertise? The best technology is the one your team knows well. A mediocre framework wielded by experts will outperform an excellent framework in the hands of beginners. Every time.
What’s your budget and timeline? Some stacks have larger ecosystems with more ready-made solutions. Others require more custom work but give you more control. Your budget determines where on this spectrum you can operate.
What are your scaling expectations? “It needs to scale” is not a useful requirement. Scale to what — 100 users? 10,000? A million? The answer changes everything.
The major categories
Server-rendered with minimal JavaScript
Technologies: Phoenix LiveView (Elixir), Laravel Livewire (PHP), Hotwire/Turbo (Ruby on Rails), HTMX (any backend)
Best for: Most web applications. Content sites, dashboards, admin panels, booking systems, CMS platforms, anything where real-time interaction matters but you don’t need offline capability.
Why it works: The server handles the logic and renders HTML. The browser displays it. Interactivity happens through lightweight mechanisms (WebSockets, HTTP streaming) rather than a full JavaScript application. Less code, fewer bugs, simpler architecture.
Trade-off: Requires a persistent server connection for real-time features. Not suitable for offline-first applications.
This is our stack at Linjerum. Phoenix LiveView gives us real-time interactivity with a fraction of the complexity of a JavaScript SPA.
Single-page applications (SPA)
Technologies: React, Vue, Svelte, Angular (frontend) + a separate API backend
Best for: Applications that need rich client-side interactivity, offline capability, or complex state management. Think Figma, Google Docs, Spotify’s web player.
Why it works: The browser runs a full application. Complex UI interactions (drag-and-drop, real-time collaboration, offline editing) are handled entirely on the client.
Trade-off: Significantly more complexity. You’re building two applications (frontend + API), managing state in two places, and shipping hundreds of kilobytes of JavaScript to every visitor. SEO requires additional work (SSR or static generation).
Static site generators
Technologies: Next.js (static export), Astro, Hugo, Eleventy, Jekyll
Best for: Content-heavy sites with infrequent updates. Blogs, documentation, marketing sites, portfolios.
Why it works: Pages are pre-built at deploy time. No server processing per request. Extremely fast, extremely cheap to host, extremely secure (no server to hack).
Trade-off: Dynamic features require external services or client-side JavaScript. Not suitable for applications with user-specific content or real-time requirements.
Headless CMS + frontend
Technologies: Contentful, Sanity, Strapi (CMS) + any frontend framework
Best for: Content teams that need to update content frequently without developer involvement, while maintaining a custom frontend.
Why it works: Content editors use a familiar CMS interface. Developers build the frontend however they want. Clean separation of concerns.
Trade-off: Another service to pay for and depend on. API calls add latency. More moving parts means more potential points of failure.
Questions to pressure-test your choice
Once you have a candidate stack, run it through these questions:
- Can I hire for this? If you need to grow the team, can you find developers with this expertise in your market?
- What happens when something breaks at 2am? Is the community active? Is the documentation good? Can you debug issues without the original developer?
- What are the hosting costs at my expected scale? Some stacks are cheap at low scale but expensive at high scale, or vice versa.
- What’s the upgrade path? Frameworks evolve. How painful are major version upgrades? Check the framework’s track record.
- Am I choosing this because it’s right for the project, or because it’s exciting? Be honest. New and shiny is not a business requirement.
The unsexy truth
For the vast majority of web projects — business websites, internal tools, SaaS products, e-commerce — the boring choice is the right choice. A mature, well-supported framework with a strong ecosystem will serve you better than the latest frontier technology.
What matters is not which framework you choose, but how well you use it. Clean architecture, good testing practices, and thoughtful design decisions matter far more than whether you’re using React or Vue, Rails or Phoenix.
That said, we chose Phoenix LiveView deliberately. For the type of applications we build — real-time, interactive, performance-critical — it offers the best balance of developer productivity, runtime performance, and long-term maintainability. But it’s not the right choice for every project, and we’ll tell you if yours is one of them.
Want to discuss which stack makes sense for your project? Reach out at support@linjerum.com.