Eyes Above The Waves

When considering massive changes to existing code, to cope with fundamental new requirements, it's appropriate to think about whether there is an opportunity to do something completely new. Joel Spolsky isn't always right.

As I mentioned before I think there is an opportunity for someone to create a new browser engine and possibly win. Here's what they could do:

• Target 8 cores or more --- i.e., pay no attention to performance on fewer cores. Existing engines can't afford to do this, so there's a market niche that they can't enter that will eventually grow to become the entire market --- a classic disruptive play.
  
• Leverage the incredible work of the WHATWG on documenting HTML parsing, DOM APIs, etc, to really design code based on specifications that are close to Web-compatible, instead of designing something and having to hack it a hundred different ways to get Web compatibility. Where the WHATWG hasn't covered a topic yet, help them out. Existing engines couldn't do this because they predate the WHATWG work.
  
• Use a new programming language with the following features:
  
  
  
  • Memory safety
    
  • Non-sucky exceptions
    
  • Real modules
    
  • UTF8 strings with an iterator API
    
  • Real global optimization with profile-driven, whole-program, ahead-of-time compilation
    
  • Immutable types
    
  • Generators and other syntactic sugar du jour
    
  • Garbage collection, of course
    
  • Safe manual memory management using ownership types (I'll write more about this later)
    
  • Copy-on-write cloning
    
  • Transactional memory and/or other modern parallel programming primitives
    
  • Typed message passing (messages should be typed for the same reasons as functions; see Microsoft's Singularity)
    
  • No crappy, hard-to-optimize, but inexplicably popular features such as identity and synchronization primitives on every object
    
  • Pluggable runtime, so at compile time you can choose what ABI, GC, etc you want to use ... so you can build components that will play nice in a variety of environments
    
  
  This is worth doing because if you're going to make a clean break, you should take the opportunity to make things so much better than C++. Memory safety alone would be a giant step forward for security (and many of the other items are ways to claw back the performance hit of memory safety).
  

While I think this approach might be a winner, it's still an extremely hard and risky road. Beyond the Joel risks, the biggest problem is the Web compatibility catch-22: you won't really be Web-compatible until you have enough market share that Web developers test against your engine, but you can't get that market share without being Web-compatible. (I suspect this is almost the entire reason why Opera hasn't been a runaway success.) To break out, you either have to work incredibly hard and be astonishingly compelling, or you have to be backed by some organization with great market power. Having said that, WHATWG and Mozilla are working to erode this catch-22, with some success, so things might be easier now than they used to be.

Clearly this approach would be much too risky for an established player to bother with. I would love to see a startup working in this area, though.

Update I should add to the above language requirements list:

• Natural and efficient mapping to commodity hardware (sorry Haskell fans)