280slides was nothing more than a demo app that hasn't been touched in 3 years. Atlas was the real product of 280north. I suggest trying Cappuccino today. If you're dealing with any significant browser issues, the problem is certainly not Cappuccino.
You can talk benchmarks all you want, but it doesn't change the fact that for 99% of consumer facing applications you won't have any noticeable benefit from those native speed.
You can talk benchmarks all you want, but it doesn't change the fact that for 99% of consumer facing applications you won't have any noticeable benefit from those native speed.
I'm not talking about benchmarks, I'm talking about actual application development, and the real impact the tremendous number of hours we spend as consumer app decelopers on performance has on the user experience.
I honestly can't even fathom your position, given the context of my experience maximizing application performance. All available CPU cycles are spent quite directly on performance and functionality.
Your position implies to me a myopic inexperience with development beyond the web.
Exactly what kind of applications are you building that require lower level languages in order to be performant? I can't think of an application I use on a daily basis that can't be done equally well in the browser. Of course there will always be certain applications that will need lower level support, but those are a very small minority.
Your position implies to me a myopic inexperience with web development.
Exactly what kind of applications are you building that require lower level languages in order to be performant?
All of them. You don't necessarily need C, you simply need to not waste CPU cycles on things that neither improve the user experience nor decrease development costs. You could achieve this with a higher-level language, including something like ObjC and ARC.
Your position implies to me a myopic inexperience with web development.
I'm very familiar with the space. Every cycle counts -- if a cycle is not spent on user experience or decreasing development costs, it's a completely wasted cycle. Browsers waste mountains of cycles.
Modern desktop and mobile software makes heavy use of SMP (threads), SIMD, specific CPU-optimized code paths (in addition to SIMD, and requires that the basic platform infrastructure be as low cost as possible. You simply could not achieve glassy-smooth scrolling and other near-instantaneous UX otherwise.
I seriously doubt that you've ever built a desktop/mobile application given that you "can't think of an application I use on a daily basis that can't be done equally well in the browser.".
You can talk benchmarks all you want, but it doesn't change the fact that for 99% of consumer facing applications you won't have any noticeable benefit from those native speed.