JavaScript: The Elephant in the Room
We know what modern web applications need. React and Vue proved it: declarative components, proper state management, predictable rendering. Yet we're still implementing these patterns in JavaScript, a language designed in 10 days for form validation. Why?
The patterns are clear:
@component function UserProfile({ userId }: { userId: ID }) { const user = @state(async () => await api.getUser(userId)) return <Card>{user.name}</Card> }
This could be native. Instead, we transpile, bundle, and ship framework implementations.
The Missing Standard Library
Want to check if a string contains another string? There's an npm package for that. Want to format a date? Another package. Basic data structures? More packages.
Python developers get import datetime
. JavaScript developers get npm install moment date-fns luxon
. Something's wrong here.
Established Patterns Need Standard Implementation
Vercel shouldn't have to build Next.js. These patterns - file-based routing, server components, data fetching - should be platform features. Private companies are doing the standardization work that the platform should handle.
Developer Experience Over Academic Purity
Tailwind's success isn't accidental. Developers chose it over "proper" CSS because:
/* CSS "the right way" */ .button { display: inline-flex; padding: 0.5rem 1rem; background-color: var(--primary); border-radius: 0.25rem; } /* Tailwind: Just get work done */ <button class="inline-flex px-4 py-2 bg-primary rounded-sm">
The lesson? Approachability beats theoretical purity every time.
Learning From Success Stories
TypeScript's adoption tells us something: developers want types. Python's popularity isn't mysterious: readable syntax matters. These aren't mere preferences - they're data points about what works in practice.
What if we had:
// Native types, Python-like clarity fn getUser(id: ID) -> Result<User, Error> { // Pattern matching, proper error handling match api.get(`/users/${id}`) { Ok(user) => user, Err(e) => Err(e) } }
Signs of Progress
Bun showed us JavaScript tooling could be fast. Elysia proved TypeScript could be a first-class server language. The ecosystem is moving forward despite the platform, not because of it.
CSS: The Case for 2.0
Tailwind and CSS Modules weren't rebellion against CSS - they were developers voting with their keyboards. What if instead of:
.component { composes: base from './base.css'; display: flex; justify-content: center; }
We had:
@component Button { @extend base; layout: flex center; }
Performance For Real World Use
Chrome's JavaScript engine is a marvel of engineering. It's also solving the wrong problem. We don't need faster JavaScript - we need less JavaScript. Native implementations of common patterns would outperform any framework.
The Path Forward
We need a clean break. Not another framework, not another build tool, but a new platform that:
- Ships with a proper standard library
- Implements proven patterns natively
- Prioritizes developer experience
- Learns from TypeScript, Python, and Rust
- Optimizes for real-world use cases
The web platform has evolved through community innovation. Frameworks prove patterns, developers adopt them, and eventually they become standards. It's time to accelerate this cycle.
Why wait for the next framework when we could build the platform developers actually need?