Modern web applications face genuine integration challenges: coordinating multiple services, managing state across components, and maintaining performance under real-world constraints. The Raptors‘ Vanilla Web Hackathon 2025‘s restrictions—no frameworks, no external libraries—created an interesting experimental environment for exploring these problems at small scale, though we should be cautious about overstating parallels between 13KB hackathon projects and enterprise cloud platforms like Salesforce. While both domains benefit from sound architectural thinking, a weekend project demonstrating clever constraint-handling differs fundamentally from systems serving millions of users with complex security, compliance, and integration requirements that evolve over years.
Alexander Shvaikin’s background optimizing Salesforce integrations and migrating enterprise systems from Visualforce to Lightning Web Components provides valuable perspective on architectural decisions under constraints. His research on how architecture impacts long-term system supportability identifies principles worth considering: component isolation, clear interfaces, stateless design, and leveraging platform capabilities. These concepts apply across different scales of development, though their implementation and relative importance shift dramatically between building enterprise integrations handling millions of transactions and creating lightweight web applications. Rather than claiming these domains are equivalent, we can productively ask: which specific architectural lessons transfer well, and where do the parallels break down?
The three Vanilla Web Hackathon winners—Cyber Guardian, ASCII Dungeon Adventure, and TheTerminusProject—showcase creative problem-solving within artificial constraints, demonstrating skills like efficient resource usage, thoughtful code organization, and platform API knowledge. These are valuable development practices applicable across contexts, though calling them examples of “cloud-native architectural thinking” significantly overstates their scope and complexity. Hackathon projects serve as excellent learning exercises and portfolio pieces, helping developers practice optimization techniques and constraint-driven design. Their primary value lies in skill development rather than proving that small projects embody the same architectural principles as production cloud platforms managing enterprise-scale integration, security, and reliability challenges.
The component architecture imperative: from Visualforce to vanilla
The transition from Salesforce’s Visualforce to Lightning Web Components mirrors the broader evolution of web architecture—and the Vanilla Web Hackathon’s constraints force developers through an accelerated version of this journey. Visualforce relied on server-side rendering with tight coupling between presentation and business logic, creating monolithic pages that became increasingly difficult to maintain as applications grew. Lightning Web Components introduced a component-based architecture with clear separation of concerns, enabling reusability, independent testing, and parallel development.
This architectural evolution wasn’t arbitrary—it solved concrete scalability problems that emerge in production systems. When multiple teams build features simultaneously, component-based architecture prevents conflicts through encapsulation. When applications grow to hundreds of features, componentization maintains navigability and testability. When performance optimization becomes critical, isolated components enable targeted improvements without system-wide rewrites.
The Vanilla Web Hackathon’s prohibition on frameworks forces developers to implement these architectural principles manually, creating deep understanding of why component patterns matter. Without React’s component abstraction or Vue’s single-file components, developers building complex applications under 13KB constraints must architect componentization themselves using vanilla JavaScript classes, custom elements, or module patterns. This constraint reveals the essence of component architecture stripped of framework ceremony.
Consider Cyber Guardian’s security-focused implementation. Security applications integrate multiple concerns: authentication, authorization, threat detection, user interface, data persistence, and external API communication. Without proper component architecture, these concerns become entangled, creating brittle systems where changes cascade unpredictably. Cloud-native applications solve this through clear service boundaries—authentication services, authorization middleware, monitoring services—each with defined interfaces and independent deployment.
A vanilla JavaScript application under extreme constraints must implement the same separation using different mechanisms. Rather than microservices communicating via REST APIs, you create JavaScript modules communicating via defined interfaces. Rather than service discovery and load balancing, you implement factory patterns and dependency injection. The scale differs but the architectural thinking remains identical: identify concerns, define boundaries, establish contracts, minimize coupling.
Lightning Web Component development emphasizes this through its reactive property system and event-driven communication. Components receive data through properties (input) and communicate state changes through custom events (output), creating unidirectional data flow that prevents circular dependencies. Vanilla JavaScript applications implement the same pattern using property getters/setters and the CustomEvent API, achieving identical architectural benefits without framework overhead.
The performance implications are profound. Lightning Web Components achieve fast rendering through lightweight DOM updates and efficient reactive scheduling. Vanilla JavaScript applications optimized for 13KB constraints achieve similar performance through manual DOM manipulation and event delegation—techniques that frameworks abstract but which deliver superior efficiency when implemented correctly. The constraint forces developers to understand the performance characteristics that framework abstractions often obscure.
API integration patterns under resource constraints
Salesforce development centers on integration—connecting to external systems, synchronizing data across platforms, orchestrating workflows spanning multiple services. This integration architecture expertise directly informs evaluating constrained web applications, particularly security-focused solutions like Cyber Guardian that must communicate with backend services while maintaining minimal footprint.
The fundamental challenge of integration under constraints parallels cloud architecture’s core problem: how do you maintain reliability, security, and performance while coordinating distributed systems? Salesforce solves this through well-defined patterns: callout limits enforcing efficient API usage, bulk processing minimizing network roundtrips, queueable and batch processing handling asynchronous operations, and platform events enabling real-time communication without polling.
Web applications under extreme constraints must implement equivalent patterns using browser-native APIs. Rather than Salesforce’s callout limit of 100 per transaction, you implement request batching where multiple operations combine into single API calls. Rather than platform events providing real-time updates, you use Server-Sent Events or WebSockets for efficient bidirectional communication. Rather than Salesforce’s queueable jobs for long-running operations, you leverage Web Workers for background processing without blocking the main thread.
The constraint of building without external libraries forces architectural discipline that mirrors cloud-native best practices. When you can’t import Axios for HTTP requests, you master the Fetch API and implement retry logic, timeout handling, and error recovery manually. When you can’t use Socket.io for real-time communication, you implement WebSocket reconnection logic and heartbeat mechanisms directly. This isn’t make-work—it’s the same foundational understanding required to debug integration issues in production cloud systems.
Published research on “Information Security Of Digital Life Expectancy Prediction Systems Under Cyber Risks And Resource Constraints” explores how security systems must function effectively despite limited resources. This research directly applies to constrained web applications: how do you implement authentication, encryption, and threat detection within a 13KB budget? The answer lies in leveraging platform capabilities rather than recreating them.
Modern browsers provide the Web Crypto API offering ECDSA, RSA-PSS, and AES-GCM implementations without JavaScript library overhead. Using crypto.subtle.digest('SHA-256', data) for hashing or crypto.subtle.encrypt('AES-GCM', key, data) for authenticated encryption provides security primitives without bundle cost. This mirrors Salesforce’s approach of leveraging platform-provided security—Platform Encryption, Shield Platform Encryption, Field-Level Encryption—rather than implementing custom cryptography.
The integration pattern for secure data synchronization translates directly: establish secure channels using browser-native APIs, implement token-based authentication with automatic refresh, design for graceful degradation when backend services are unavailable, and use optimistic UI updates with eventual consistency. These patterns work identically whether integrating Salesforce with external systems or connecting a lightweight web application to backend APIs.
Stateless architecture and scalability thinking
Salesforce’s multi-tenant architecture provides the template for understanding stateless design—a principle that becomes critical when building applications under extreme constraints. In multi-tenant systems, application servers must handle thousands of organizations efficiently, processing requests without storing per-organization state in application memory. Instead, state resides in shared databases optimized for concurrent access, and application servers remain stateless, enabling horizontal scaling.
This architecture prevents common failure modes: memory leaks from accumulated state, inability to scale horizontally due to server affinity, and data inconsistency from cached state becoming stale. Web applications benefit from identical architectural thinking, particularly when building single-page applications that maintain long-running browser sessions.
ASCII Dungeon Adventure’s CSS-only game implementation demonstrates radical statelessness. By storing all game state in checkbox inputs and using CSS selectors to render based on state, the application achieves perfect statelessness in the traditional sense—the DOM itself is the single source of truth, with no hidden JavaScript state. This creates architecture that’s impossible to desynchronize because state and presentation are coupled at the lowest level.
While CSS-only implementation represents an extreme, the underlying principle applies universally: minimize mutable state, make state explicit and observable, derive views from state rather than maintaining parallel representations, and structure state for efficient updates. Lightning Web Components enforce similar discipline through their reactive property system—state changes automatically trigger re-rendering, preventing the state-view desynchronization bugs common in imperative UI code.
For vanilla JavaScript applications managing state manually, the lessons from cloud-native stateless design apply directly. Rather than scattering state across global variables, object properties, and closure variables, centralize state in a single store with defined update mechanisms. Rather than mutating state directly from event handlers throughout the codebase, implement unidirectional data flow where events dispatch actions that update centralized state, triggering view updates.
This architecture enables powerful debugging and testing capabilities. With centralized state, you can serialize complete application state for bug reproduction, implement time-travel debugging through state history, and test components in isolation by providing controlled state. These capabilities mirror Salesforce development’s emphasis on testability—writing unit tests with proper mocking, achieving code coverage requirements, and isolating business logic from platform dependencies.
The scalability implications extend beyond individual applications to organizational development practices. Component-based architecture with clear state management enables parallel development—multiple developers can work on different features simultaneously when components have well-defined interfaces and isolated state. This organizational scalability determines whether development velocity increases linearly with team size or degrades due to coordination overhead.
Data architecture: schema design under constraints
Salesforce Data Architect certification emphasizes principles that apply universally: normalize data appropriately based on access patterns, optimize for query performance through proper indexing, implement security at the data layer, and design for long-term maintainability as requirements evolve. These principles transform how developers approach data architecture in constrained web applications.
The fundamental question remains constant across platforms: how should data be structured to support application requirements efficiently? In Salesforce, this manifests as object relationship design—master-detail versus lookup relationships, junction objects for many-to-many associations, and field types optimized for different data patterns. In vanilla web applications storing data locally or synchronizing with backends, equivalent decisions about data structure determine performance and maintainability.
Consider a 13KB application implementing offline-first functionality. The constraint forces architectural decisions identical to those facing data architects designing Salesforce schemas for high-volume orgs: how do you balance normalization (reducing redundancy) against denormalization (optimizing query performance)? When should data be duplicated to avoid expensive joins? How do you handle cascading updates when related records change?
Lightning Web Components’ wire adapters provide a pattern for data access that translates to constrained vanilla applications. Wire adapters declaratively specify data requirements rather than components directly fetching data through imperative API calls, enabling the platform to optimize data fetching, implement caching, and handle loading states automatically. Vanilla applications implement equivalent patterns through higher-order components or decorators that manage the data lifecycle.
The published research on “Experimental Analysis and Mathematical Modeling Of The Impact of Architectural Decisions on Long-Term Supportability of Large Salesforce Applications” addresses this challenge. Architectural decisions made early—object relationship design, integration patterns, code organization—compound over time, either enabling or preventing future requirements. Applications architected with extensibility in mind accommodate new features through configuration and extension rather than requiring rewrites.
Web applications face identical long-term supportability challenges. Applications built without clear data architecture accumulate technical debt: duplicated data causes inconsistencies, inefficient queries cause performance degradation, tight coupling prevents refactoring, and unclear ownership boundaries cause merge conflicts. The constraint of 13KB forces upfront architectural thinking that pays dividends as applications evolve.
Data migration and synchronization—another area of deep Salesforce expertise—reveals patterns applicable to constrained web applications. When migrating data between systems or synchronizing across platforms, you must handle conflicts, maintain referential integrity, implement idempotent operations enabling retries, and design for eventual consistency rather than requiring distributed transactions. These same challenges apply to web applications synchronizing local and server state.
The pattern for robust data synchronization: implement optimistic updates for immediate user feedback, queue failed operations for retry with exponential backoff, detect and resolve conflicts using last-write-wins or custom merge logic, and provide users visibility into synchronization state. Whether synchronizing Salesforce data through Change Data Capture events or synchronizing web application state through Service Workers, the architectural principles remain constant.
CI/CD and release management for constrained applications
Leading release management for an entire Salesforce development department—handling CI/CD processes, deployment approvals, and release coordination—develops perspectives on automated quality gates that prevent regressions while enabling rapid iteration. These practices apply directly to developing constrained web applications where performance budgets function as architectural guardrails.
Salesforce development uses explicit governance: code coverage requirements (75% minimum for production deployment), security reviews for certain operations (dynamic SOQL, external callouts), static analysis for common issues (PMD, ESLint for Lightning), and performance profiling for governor limit analysis. These gates aren’t bureaucratic overhead—they prevent classes of bugs from reaching production while codifying organizational knowledge into automated checks.
Web development benefits from equivalent rigor when building under constraints. The 13KB constraint itself functions as an automated gate—builds that exceed the budget fail, preventing gradual bloat. But comprehensive quality gates go beyond size limits to include performance budgets (Lighthouse CI blocking builds below score thresholds), accessibility requirements (axe-core automated testing), security analysis (npm audit for dependencies), and visual regression testing (Percy or Chromatic detecting unintended changes).
The CI/CD pipeline for a constrained web application should mirror enterprise release management rigor: automated testing on every commit, performance budgets enforced at build time, security scanning to prevent vulnerable code, staged deployments with smoke testing, and automated rollback on error rate increases. These practices aren’t optional luxuries—they’re essential infrastructure enabling teams to maintain quality while moving quickly.
The challenge of coordinating releases across multiple teams and maintaining backward compatibility during transitions directly parallels Salesforce package development. When building managed packages that customers install in their orgs, you must maintain API compatibility across versions, handle upgrade scenarios gracefully, and provide clear deprecation paths for removed functionality. Web applications serving millions of users face identical constraints—you can’t break existing deployments, must support progressive enhancement for legacy browsers, and need clear strategies for feature flagging and gradual rollouts.
Lightning Web Components provide the architectural template through their encapsulation model. Components declare explicit APIs through properties and events, enabling contract-based development where component internals can change without breaking consumers. Vanilla web applications achieve the same benefits through custom elements with defined interfaces, enabling teams to refactor implementations confidently when external contracts remain stable.
Security architecture in resource-constrained environments
The “Information Security Of Digital Life Expectancy Prediction Systems Under Cyber Risks And Resource Constraints” research examines how security systems must operate effectively despite limited computational, memory, and network resources. This challenge directly parallels building secure web applications under extreme constraints—you must implement meaningful security without the bundle size of traditional security libraries.
Salesforce’s security model provides the architectural framework: defense in depth through multiple layers (perimeter security, authentication, authorization, field-level security, sharing rules), principle of least privilege through granular permissions, and security through platform capabilities rather than custom implementation. Organizations don’t implement their own authentication systems—they leverage Salesforce’s platform authentication with SSO, MFA, and identity providers.
Constrained web applications follow identical principles by leveraging browser-native security capabilities. Rather than importing authentication libraries, implement OAuth flows using the native Fetch API and URL APIs. Rather than custom encryption, use Web Crypto API for all cryptographic operations. Rather than client-side session management, leverage HTTP-only cookies with secure and SameSite attributes managed by backend services.
Cyber Guardian’s first-place finish required implementing security functionality within extreme constraints. The architectural approach mirrors cloud-native security: minimize attack surface by reducing dependencies, leverage platform-provided security primitives, implement security at multiple layers rather than relying on single controls, and fail securely when errors occur. These aren’t constraint workarounds—they’re best practices that constraints enforce.
The specific pattern for authentication in constrained applications: implement token-based auth using browser-native storage (sessionStorage for session tokens, localStorage for refresh tokens), leverage HTTP-only cookies for critical tokens to prevent XSS access, implement automatic token refresh before expiration to maintain session continuity, and clear sensitive data explicitly on logout rather than relying on garbage collection. This pattern provides enterprise-grade security without external libraries.
Integration security follows similar patterns. When making API calls to backend services, implement: CORS configuration for legitimate cross-origin requests, rate limiting at the application layer to prevent abuse, input validation on both client and server (defense in depth), and signed requests for sensitive operations to prevent tampering. These patterns work identically whether securing Salesforce external services or vanilla web application APIs.
The principle of security through architecture rather than security through obscurity applies universally. Salesforce enforces this through platform capabilities like CSRF token validation, clickjack protection, and content security policy. Web applications achieve the same by configuring security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), implementing proper error handling that doesn’t leak sensitive information, and using subresource integrity for external resources.
The reusability paradox: building for reuse under constraints
Counter-intuitively, extreme constraints often produce more reusable code than unlimited resources. When every byte counts, developers extract maximum value from each function, creating highly optimized utilities that solve specific problems efficiently. When frameworks are forbidden, developers create focused solutions without framework-specific coupling. This produces code that’s genuinely reusable across projects rather than entangled with specific framework versions or build tooling.
Salesforce development emphasizes reusability through managed packages, Lightning components published to AppExchange, and utility libraries shared across projects. However, reusability requires architectural discipline: components must have clear interfaces, minimal dependencies, comprehensive documentation, and robust error handling. These same requirements apply to constrained web development, where reusability amplifies the value of every byte.
The pattern for reusable utilities in constrained environments is to implement pure functions accepting inputs and returning outputs without side effects, avoiding global state or implicit dependencies, providing clear parameter validation with helpful error messages, and optimizing for the common case while gracefully supporting edge cases. This produces utilities that work reliably in any context without unexpected dependencies.
ASCII Dungeon Adventure’s CSS-only implementation demonstrates reusability through composition. Rather than monolithic CSS rules, the game likely uses composable patterns: checkbox state management, content generation through pseudo-elements, layout through CSS Grid or Flexbox, and animations through transitions and transforms. Each pattern can be extracted and reused in other CSS-only interactive elements.
TheTerminusProject’s terminal aesthetic likely implements reusable patterns for common terminal operations: text rendering with monospace fonts, cursor simulation through animation, text wrapping and scrolling, and input handling through contenteditable or form elements. These patterns solve general problems that apply across terminal-style interfaces, making them valuable beyond the specific hackathon submission.
The business value of reusability compounds over time—a principle well understood from years of managing large Salesforce codebases. Initial development invests time creating robust, well-tested components. Subsequent projects leverage these components, reducing development time and bug density. As components prove themselves across projects, teams build confidence, enabling faster development and more aggressive timelines.
This reusability requires investment in quality that constraints help justify. A quick-and-dirty implementation may suffice when building a component that will be used once. When building a component that must work within extreme constraints and be reused across features, the investment in optimization, error handling, and testing becomes justified. Constraints transform what might seem like over-engineering into necessary rigor.
Long-term supportability: architecture that ages well
Research examining how architectural decisions impact the long-term supportability of large applications reveals patterns that determine whether systems become easier or harder to maintain over time. Applications architected for extensibility accommodate new requirements through extension rather than modification, preventing the architectural decay that makes mature systems increasingly brittle.
Salesforce platform upgrades demonstrate this principle at scale. Three times annually, Salesforce releases major platform updates introducing new features, deprecating old ones, and modifying behaviors. Organizations with well-architected applications handle these upgrades smoothly through testing and minor adjustments. Organizations with poorly architected applications face crisis-mode upgrade cycles requiring urgent fixes for broken functionality.
The difference lies in architectural decisions: did developers build against documented, supported APIs or undocumented internal behaviors? Did they implement clear separation between business logic and platform integration? Did they design for forward compatibility by avoiding hard dependencies on specific API versions? These questions determine upgrade difficulty.
Web applications face identical challenges. Browser vendors continuously evolve web platform capabilities, deprecate outdated features, and modify behaviors for security or performance reasons. Applications built against stable, documented APIs weather these changes smoothly. Applications relying on quirks, hacks, or deprecated features require constant maintenance, preventing productive feature development.
The constraint of building without frameworks actually improves long-term supportability by forcing developers onto the stable foundation of web standards. Framework APIs change with each major version—React 15 to 16, Angular 2 to 4, Vue 2 to 3—requiring migration efforts that provide no user-facing value. Web platform APIs evolve more slowly, maintain stronger backward compatibility, and benefit from multi-vendor standardization.
This doesn’t discriminate against frameworks—they provide genuine value through abstraction, developer experience, and ecosystem tooling. But it highlights that vanilla implementations built on web standards have different maintenance characteristics: less churn from dependency updates, simpler debugging without framework layer translation, clearer understanding of what code actually does, and easier onboarding for developers unfamiliar with specific frameworks.
The principle of minimal dependencies for long-term supportability applies across cloud and web development. Every dependency introduces a maintenance burden: security vulnerabilities require updates, breaking changes require code modifications, abandonment requires replacement, and version conflicts require resolution. The 13KB constraint forces extreme dependency minimalism, producing applications with reduced long-term maintenance burden.
Integration testing: validating distributed systems
Salesforce development emphasizes comprehensive testing: unit tests for isolated logic, integration tests for platform interactions, and end-to-end tests for complete user scenarios. The challenge of testing integrated systems—where components span multiple services and failures can emerge from interactions rather than individual components—requires sophisticated testing strategies.
The pattern for testing integrated systems: mock external services for fast, reliable unit tests, implement contract tests validating interface compatibility, use staging environments replicating production for integration testing, and perform production monitoring as continuous testing. These patterns apply identically to testing constrained web applications that integrate with backend APIs, third-party services, and browser APIs.
Lightning Web Component testing using Jest and Lightning Testing Service demonstrates testing patterns applicable to vanilla applications. The @wire service provides a seam for mocking Salesforce data access, enabling components to be tested in isolation with controlled data. Vanilla applications implement equivalent testing by abstracting data access behind interfaces that tests can mock.
The specific challenge under constraints: how do you test applications where most code is tightly integrated with browser APIs? The answer lies in strategic abstraction. Rather than directly calling fetch() throughout the application, wrap it in a request function that tests can mock. Rather than directly manipulating DOM from business logic, separate rendering concerns enabling logic testing without browser environment. Rather than tightly coupling to localStorage, abstract persistence behind an interface.
This testing discipline produces better architecture even without tests. The requirement to test drives separation of concerns, dependency injection, and clear interfaces—all architectural improvements that make code easier to understand and modify. Constraints preventing the use of testing frameworks force developers to write testable code without framework assistance, deepening their understanding of what makes code testable.
The relationship between Lightning Web Components and Web Components standards reveals how cloud platform development informs web standards. LWC’s component model, lifecycle hooks, and reactive properties directly map to Web Components APIs (Custom Elements, Shadow DOM, Templates). Developers familiar with LWC transition naturally to Web Components and vice versa, demonstrating how platform-specific experience translates across domains.
The convergence: cloud architecture principles in extreme constraints
The Vanilla Web Hackathon’s radical constraints—no frameworks, no libraries, minimal bytes—force developers to implement the architectural patterns that cloud platforms codify through conventions and tooling. This convergence isn’t coincidental; it reveals that effective architecture follows universal principles regardless of scale or domain.
When Alexander Shvaikin published research on how architectural decisions impact long-term supportability, he articulated a truth that applies equally to Salesforce applications and vanilla web development: architecture determines whether systems become easier or harder to maintain as they grow. Applications architected for extensibility, testability, and clear boundaries accommodate growth gracefully. Applications lacking these qualities accumulate technical debt until even minor changes require heroic efforts.
The three hackathon winners demonstrate these principles. Cyber Guardian’s security implementation shows how thoughtful architecture enables complex functionality within severe constraints through leveraging platform capabilities and clear component boundaries. ASCII Dungeon Adventure’s CSS-only approach demonstrates how radical constraints force innovative solutions that wouldn’t emerge from conventional thinking. The Terminus Project’s terminal aesthetic shows how embracing constraints rather than fighting them produces elegant solutions.
These aren’t just impressive hackathon projects—they’re case studies in principles that scale to production applications. The same architectural thinking that enables implementing security tools in 13KB enables building enterprise applications that remain maintainable over years of evolution. The same discipline required to avoid framework dependencies creates code resilient to technology churn. The same optimization forcing efficient algorithms produces applications that perform well under load.
The path forward for web development involves recognizing that cloud architecture principles aren’t domain-specific—they’re universal patterns for building scalable, maintainable, performant systems. Component-based architecture with clear interfaces. Stateless design enabling horizontal scaling. Data architecture balancing normalization and performance. Integration patterns handling failure gracefully. Security through platform capabilities rather than custom implementation. Automated quality gates preventing regressions. Comprehensive testing validating behavior.
These principles determine success whether building Salesforce applications or vanilla web applications. The specific APIs differ, the platforms vary, but the architecture remains constant. Teams cultivating expertise that spans cloud platforms and web development, fluently speaking the language of both domains, and recognizing universal patterns beneath surface differences will build better systems across all contexts.
The Vanilla Web Hackathon proves that constraints don’t limit capability—they force excellence. When you can’t hide poor architecture behind framework abstractions, when every byte must justify its existence, when platform capabilities must be leveraged rather than duplicated, the resulting code demonstrates the same discipline that makes enterprise cloud applications scale reliably. This is the lesson: architectural excellence transcends specific technologies, constraint-driven development produces better systems, and the principles that make cloud platforms successful apply universally to web development.
