Since we've worked on the same browser engine before, I should ask the obvious question: what do you plan to do differently that will make it better than existing engines?
Regardless, the main things I aim to do differently:
1. No JS JIT, only interpreter. I don’t care that much about JS performance as a user and the difference in complexity is astounding.
2. I prefer the web as a platform for smart documents, not for applications. I don’t want to relinquish any control of my computer to the web, and don’t want most desktop integrations like notifications, etc.
3. In that same vein, very light on animations/transitions, that type of stuff.
4. Way less aggressive memory caching. I don’t like the sight of 100MB+ web content processes that’s so common these days.
One of the cool techniques we used in earlier versions of JSC (although someone told me it's been dialed back since then) was caching property accesses / method calls in the bytecode interpreter. This technique ended up getting published by someone else in a different context:
https://web.cs.upb.de/cp/download.py?key=ecoop10
I think there's more to be explored along these lines.
>I prefer the web as a platform for smart documents, not for applications. I don’t want to relinquish any control of my computer to the web, and don’t want most desktop integrations like notifications, etc.
I wish more people share the same opinion. We haven't even perfected the Smart Documents yet, but browsers has abandoned that work and moved to Web Apps instead.
And along the 'control' axis, stuff running in the browser probably has less of that than the same stuff running outside of that sandbox.