>This is why so many people want to see the browser execution environment offer more complete, low-level APIs instead of high-level APIs locked to HTML/CSS and legacy browser technology.
It's called the desktop and offers all the native and low-level stuff you can possibly imagine.
And the only people that want to see it, are the ones who have forgotten about it.
Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.
> It's called the desktop and offers all the native and low-level stuff you can possibly imagine.
Actually, I'd say it's called 'mobile'; The desktop failed to solve the sandboxing problem.
> And the only people that want to see it, are the ones who have forgotten about it.
As a desktop-turned-mobile developer, I haven't forgotten anything.
Simply put, I want a future in which we aren't forced to re-implement our applications multiple times for disparate, proprietary mobile platforms.
I already lived through that on the desktop. The only reason I haven't embraced the web for application development is that the technology stack is, by comparison, hobbled.
> Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.
Treating the browser as the sacrosanct temple of HTML, CSS, and JavaScript is throwing away the limited opportunity browsers have to pre-empt Android and iOS as a first-class, standardized application platform.
It might just be me, but it seems profoundly silly to implement what basically amounts to a complete operating system in a browser. Why not use something reasonable like the Java or .Net VM to implement your cross platform applications? I think browsers should stay programs to browse webpages and therefore keep their focus on scripting that enables fancier HTML and CSS manipulation. While running Linux in a browser is an impressive feat, to me it is similar in spirit to simulating a Turing machine in the Game of Life.
You're always going to feel hobbled by a standards-based, compatibility-driven platform like the web where you must maintain compatibility with fairly ancient software. This is just the way things are. If it wasn't the web, it'd be whatever layer was used to allow your applications to run across multiple devices.
Qt Quick with its QML environment (UI markup + Javascript + native extensions if you need them) is a great middle ground.
It seems that the plan for Qt 5 is to move the enitre Qt toolkit over to the "QML first" model - that is, QML becomes the default way to create interfaces, for both mobile and desktop apps, and native widgets are only used when you require them. They also want to better integrate webkit and web content. In a recent Qt desktop app of mine, I was already doing this: QML + webkit + native backend for the heavy lifting and it works very well. Be awesome to have it as the default in all environments.
FWIW, I think QML/JS would have made a greate HTML/CSS/JS alternative.
We've used QML in a recent QT/C++ desktop app and it's performance is comparatively poor compared with WebKit rendering and its CSS subset support is woefully inadequate.
The HTML/CSS/JS dev model is fine as it is, there's no need to hope for nirvana grass-is-greener frameworks that don't exist.
Learn HTML5 like the rest of us.
The desktop has several limitations. First, you have to code separately for each platform because there's not even a common runtime, let alone API. Second, installation and updates are not seamless. Third, it is less secure since native code can have many long-lasting side effects, even without security exploits.
Web apps more or less solve all these problems (code can't be completely browser-agnostic, but it's close). Why not add also the benefits of desktop apps?
It's called the desktop and offers all the native and low-level stuff you can possibly imagine.
And the only people that want to see it, are the ones who have forgotten about it.
Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.