LARC Development Philosophy

Core Principle: Zero-Build Development, Optimized Production

Development: Zero Build Required

The Problem with Build-Required Development

Traditional modern web development forces developers into a build-first workflow:

• Write code → wait for bundler → refresh browser → repeat
• Edit one line → webpack rebuilds thousands of files
• Change CSS → entire app recompiles
• Every change requires a multi-second compilation step

The LARC Approach

LARC eliminates build requirements during development:

<!-- This works immediately, no build required -->
<script type="module" src="/src/pan.mjs"></script>
<pan-card>Hello World</pan-card>

• ✅ Instant feedback - Write code, refresh browser, see changes immediately
• ✅ Simple debugging - Use browser DevTools with actual source code, not transpiled output
• ✅ No toolchain - No webpack configs, no babel presets, no plugin hell
• ✅ Lower barrier - Beginners can start without understanding build systems
• ✅ Faster onboarding - New team members can be productive in minutes
• ✅ Reduced complexity - One less system to learn, configure, and maintain

How It Works

LARC achieves zero-build development by:

Production: Build Optimization Welcome

The Value of Production Builds

LARC's zero-build philosophy applies to development, not production. For production deployments, build processes provide significant value:

• 🚀 Minification - Reduce file sizes by 40-60%
• 🚀 Bundling - Reduce HTTP requests
• 🚀 Tree Shaking - Remove unused code
• 🚀 Code Splitting - Load only what's needed
• 🚀 Compression - Gzip/Brotli for faster transfers
• 🚀 Cache Busting - Versioned assets for optimal caching

• CSS purging and critical CSS extraction
• Image optimization and responsive images
• Font subsetting and preloading
• Service worker generation
• Static site generation (SSG)
• Server-side rendering (SSR) if needed

• Browser compatibility transformations (if targeting older browsers)
• Environment-specific configurations
• Secret management and API key injection
• CDN deployment and asset distribution

LARC's Production Strategy

• Specific build tools
• Proprietary toolchains
• Framework lock-in
• Complex configuration

Recommended Production Build Process

# Example production build with Vite
npm install -D vite

# Build optimized bundle
vite build

# Result: Minified, bundled, optimized assets ready for deployment

Philosophy in Practice

Development Workflow

# Clone and run immediately
git clone https://github.com/larcjs/larc.git
cd larc
python3 -m http.server 8000
# Open http://localhost:8000 - that's it!

• npm install (except for build tools if you want them)
• webpack.config.js
• babel.config.js
• tsconfig.json (optional)
• package.json (optional for pure HTML/JS)

• Write code
• Refresh browser
• See changes instantly

Production Workflow

# When ready to deploy
npm run build              # Run optimizations
npm run test              # Verify everything works
npm run deploy            # Deploy to CDN/hosting

# Or use your preferred build tool
vite build
esbuild src/index.js --bundle --minify
rollup -c

• Optimized, minified bundles
• Fast load times
• Production-ready assets
• Framework-agnostic output

Why This Matters

For Developers

• Edit → refresh → see results in < 1 second
• No waiting for webpack to rebuild
• No context switching while builds run

• Step through actual source code
• No source maps to break
• Direct console inspection

• One less system to understand
• Fewer configuration files
• Less tooling overhead

For Teams

• Junior developers don't need to understand build systems first
• Focus on learning web standards, not toolchains
• Less documentation overhead

• No webpack version migrations
• No babel plugin incompatibilities
• No build pipeline debugging

• Use build tools when beneficial
• Skip them when unnecessary
• Mix approaches as needed

For Projects

• Start simple, add complexity only when needed
• Begin with zero-build, add builds for production
• No forced architectural decisions

• Based on web standards
• Tools change, standards remain
• No framework version lock-in

Common Questions

"Isn't this just going back to the old days?"

No. We're using modern web standards (ES Modules, Web Components, native APIs) that didn't exist in "the old days." This is forward-looking, not backward-looking.

"What about TypeScript?"

TypeScript is optional for type checking during development. You don't need to transpile it to run code—use it for IDE support and pre-commit checks if desired.

# Optional: Type check without transpilation
tsc --noEmit

"What about older browsers?"

For development: Modern browsers only (Chrome 90+, Firefox 88+, Safari 14+).

For production: Add transpilation in your build step only if needed for your target audience. Most users are on modern browsers now.

"What about large applications?"

LARC scales well:

• Component lazy loading - Load on-demand
• Code splitting - Manual or via build tools
• Progressive enhancement - Start simple, optimize later
• Production builds - Bundle and optimize for deployment

"Can I use build tools if I want?"

Use Vite, esbuild, Rollup, webpack—whatever you prefer. LARC's architecture works with all of them.

The Bottom Line

✅ Development should be fast - Write code and see results immediately ✅ Production should be optimized - Use builds for performance ✅ Developers should choose - Use tools when beneficial, skip when not ✅ Standards should win - Build on what browsers provide

We believe developers should choose their tools based on actual needs, not because the framework mandates them. Start simple, add complexity when it provides clear value.

Further Reading

• Production Deployment Guide - Complete production build strategies
• Performance Optimization - How to maximize production performance
• Browser Compatibility - Targeting different browser versions
• Quick Start Guide - Get started in 5 minutes