I understand how Cappuccino works (I am one of the GWT authors, and I often have to tell people the same about GWT, is it not a "widget framework"), but what I'm saying is, from what I observe, people often spend more time debugging CSS and HTML than they do code.
There are lots of reasons why JS needs fixing, I'm onboard with that. But honestly, you could fix it 100%, and it would still be easier to develop native apps on iOS/Android. 280 North's Slides for example as a great example of what you could do, but let's not kid ourselves, it was also pretty slow.
If you look at the herculean efforts the Google Docs team went through to get that running fast, and it's still not fast enough, I'd say there's there a lot more work do be done on the Web-as-app-UI-renderer model side.
If it weren't for all of the other things you'd have to reinvent, and what you'd lose from indexability and transparency, I'd almost say built a framework on using WebGL rendering.
I think different people have different concepts of what smooth and buttery feels like. Native apps have taught people to expect a mostly constant fixed 30fps or 60fps. As smooth as you think Slides was, I doubt it achieved this, because the tooling neccessary to monitor repaint regions and framerates, not to mention GPU compositing, wasn't available in 2008.
DOM programming is still a minefield. GPU compositing tricks is not only not fully portable between browser rendering engines, they aren't even fully portable across GPUs, as differing GPU restrictions like maximum texture size, texture memory, et al, impose different limitations on the maximize size of composited regions, how many can animate or update at once, etc.
It's a shame that 280 Slides is no longer online, because I'd love to be able to challenge your performance assertion.
Back when we released it, in 2008, browsers were a hell of a lot slower than they are now. And even then, 280 Slides launched faster than PowerPoint or Keynote on our machines, and had comparable runtime performance with manipulating objects on the slide. Of course, we did not have many of the most resource intensive Keynote features like 3D animations, but I don't think that's what you meant.
> I'd almost say built a framework on using WebGL rendering.
I've had that thought many times. But then I start to wonder why bother with the web browser at all? It begins to look like a pointless abstraction. In many ways, it already is.
There are lots of reasons why JS needs fixing, I'm onboard with that. But honestly, you could fix it 100%, and it would still be easier to develop native apps on iOS/Android. 280 North's Slides for example as a great example of what you could do, but let's not kid ourselves, it was also pretty slow.
If you look at the herculean efforts the Google Docs team went through to get that running fast, and it's still not fast enough, I'd say there's there a lot more work do be done on the Web-as-app-UI-renderer model side.
If it weren't for all of the other things you'd have to reinvent, and what you'd lose from indexability and transparency, I'd almost say built a framework on using WebGL rendering.