Lions, Tigers and Cloud HTML5 .. oh my!
I've written about this from various points of view before, and I just love Larry Ellison's response to a question about "the cloud", but it bears repeating and looking at the core issues from different angles because people continue to find themselves confused on the matter. This time we'll look at it from the perspective of "form factors are not programming languages".
Reality is that well over 300 million new desktops and laptops are sold every year. That number is even growing, albeit slowly as one would expect from a mature market segment that is also seeing displacement pressure from new (or revived) form factors. So the "large screen, got a keyboard and a pointing device" form factor is really not going anywhere. It's a good form factor that works for a lot of real world use cases and it will be with us for a while.
HTML5 and the "cloud" do not change that one bit. That's because those technologies are not drivers of physical form factor. I could use those technologies equally well on a phone or a laptop or a T.V. or a fancy billboard at a sports stadium. That is why coming to the conclusion that "Our idea of the desktop is gone." is so wrongheaded.
Now, our way of writing applications for "the desktop" may change over the next decade, but the desktop will still be with us. People will still want a way to launch their apps, manage the shapes they appear in on the screen (aka "windows", since I assume that HTML5CloudAwesomeness doesn't mean "everything is fullscreen with one app at a time" for most people), will want to place these HTML5CloudAwesomenesses around their screen (aka "desktop widgets"), etc. That could, indeed, be written in HTML and Javsacript, but it will still exist.
So what appears inside of our windows may change in the form of where some or all of the data being manipulated is stored and/or what language is used to write them .. but it will still be a lot like a laptop computer.
Just like a tablet doesn't become a desktop just because you run a desktop application on it. If you don't get that one, try running one of the games that are available for the N900 that are just re-compiles of games made for a desktop. It's pretty evident that the language used doesn't magically change the form factor or render it useless.
Network centric computing is awesome and is changing the landscape. How it will change the landscape in the future is not how it is changing it now in terms of creating all these walled gardens that require you to pay with your attention (ads) or with your wallet (rental sites), and I think it is imperative that Free software does provide network storage solutions that work well in this new reality to prevent all the technology from aggregating behind those walled gardens, such as Google.
We will change how we write apps
On that note, I am fairly confident that we will radically change how we write applications with a graphical interface over the next few years. This will not just be on the desktop, but across all kinds of devices. The most exciting thing won't actually be the language used (e.g. HTML vs C++ vs $WHATEVER), but in the level of modularity and subsequent re-use that happens as a result.
Ryan Rix published a screen cast about the Plasma Dashboard KPart that he worked on, particular with regards its use in Kontact. The first comment on his blog asked why use Plasma there at all. The answer is wrapped up in a new way of thinking about application development. This is something I've also blogged about in the past, but that we're starting to actually see happen now.
Instead of writing applications as monolithic things, or at best as collections of components that work with each other only, we're starting to see the emergence of applications that are written as collections of self-contained components that are then collected together into a single interface.
In the specific case of Kontact and it's summary view, it needed to be rewritten for Akonadi anyways. So it was decided to do it in a way that (a) improved what is already there and (b) made new things possible at the same time.
The version shown in Ryan's screencast isn't finished, and the layout and graphic design still has tweaking left to do so it looks a bit nicer in certain places, but even in its current state it gives Kontact's summary dashboard some nice improvements.
I'm not sure how many people new that you could actually move items around in the summary. This is both more obvious now (which is mostly a factor of the graphic design), but also has the ability to provide multiple columns in addition to rows. Horizontal scrolling is there when needed, another improvement.
To extend the summary page requires a plugin system of some sort that everyone can use. Plasma provides just such a component model that fits that perfectly. So an existing widget that is related to email, contacts, events, etc. can now be used in Kontact without any additional work being required by the Kontact team. The email summary widget seen in Ryan's screencast, with all of its great features, is Lion Mail. This was developed for Plasma Desktop in mind originally by sebas, but can now be used in Kontact, saving the Kontact team a ton of work.
What about a weather widget? It was going to have to be re-written, too, to use the new weather data fetching in KDE Platform 4 (which happens to be driven by a Plasma DataEngine now). Well, with the dashboard it doesn't need to be re-written at all: the existing weather widgets can be used there.
Conversely, components written for the Kontact dashboard can also be used in Plasma Desktop, Netbook, other apps using Plasma Dashboard, etc. So the nifty "upcoming events" Plasmoid, written for Kontact is now also available wherever you want.
This is a remarkable, if seemingly subtle, change in how we are writing applications. It's a floating mix of components that we can re-arrange, mash-up and re-use .. at runtime.
We see this not only in Plasma derived work, but also in Akonadi itself as well as KDE Telepathy which renders the functions of Kopete into a similar raft of run-time components.
Not only does this save all of us developers time, it increases consistency between applications, raises the number of features that are easily available to integrate seamlessly into your application (or mash-up) and reduces the runtime overhead of doing so.
Componentizing the Chrome
Another sort of components (don't you love it when we use the same words for different things?) is the user interface chrome itself: the buttons, the knobs, the dials, the menus, the sliders, the web canvas, the print dialog ..
The status quo has been that everyone writes a set of such components for each project type: one for this phone, one for that phone, one for desktop apps, one for PIM apps, one for T.V.s, etc. These components have traditionally been a horrible mix of logic ("when the user presses on this area and then releases on that area, then ...") and display ("paint this gradient here when it is in a pressed state ...").
The display of these elements has been further compounded by the need and desire to make things look and work differently in different contexts. So we have the Oxygen style along with dozens of other Qt styles, each of which is a behemoth of complex C++ that can style all kinds of things in all kinds of situations. There are very real limits to this approach, mostly due to the complexity it introduces and the limitations one runs into quickly due to this.
We also have a different presentation style on a small screen than we do a large screen. Dialogs may look completely different, for instance.
What would be great, however, is if we could get the C++ guy out of the room as much as possible, break up the logic and the display into different pieces so that changing one doesn't impact the other (and removes so much need for subclassing!), make it easy to define new components that overlay just those components from the defaults (so I don't have to write a whole new style just to get a different kind of toggle button semantics, e.g. checkboxes in a mouse driven UI and a slider toggle on a finger driven UI).
If that was possible, app developers could write their UI quicker and easier than they do now (thanks to logic/display separation) and platform developers could mold those application UIs much more cleanly when run on their platform.
Now imagine if this was all done using a proper scene graph allowing for proper hardware acceleration (the sort you usually only get with games these days), built upon a declarative model for user interface (lowering costs and shortening devel times), allowed designers to directly create the elements which developers could then directly use (and vice versa) and easily allowed one to step away from compiled code where desired and use things like QML and JavaScript .. though not be forced to do so, either.
This is the future that QtComponents is attempting to bring us. There is a development hot-house happening next week in Oslo (that I hope to attend for a couple of days as I just happen to be nearby that week, as it turns out) that will be critical to the future shaping of this potentially ground breaking approach.
It should, done right, result in it being possible to write UIs which are as or more powerful than the desktop interfaces we have now that look better, work faster, cost less to make and without being bound to a web browser or the technologies they provide (or don't, as the case may be). All with write-once-run-anywhere-there-is-Qt, even without a native compile if done right.
The Device Spectrum
Something that has struck me about what the Linux kernel did that was groundbreaking for the time was to view all computing devices as a spectrum upon which the kernel, albeit in different configurations, should run well on. A wrist watch, a smartphone, a desktop, a super computer .. they are all just collections of CPUs and storage (volatile and non-volatile) coupled with form factor specific stuff, like graphical displays and networking, with processes running on them, right? Hey, it's all the same! Sort of. So why not one (sort of) kernel that runs on all of them? So came the Linux kernel which now is both running rampant in mobile and owns the super computing world, two opposite sides of the spectrum.
Why not our graphical applications?
With decomposable applications and componentized interface elements we begin to approach the age of the device spectrum with our graphical applications. Right now Marco and I are helping a company in Asia working on a tablet device running MeeGo with Plasma providing the UI. They are able to simply re-use work done for the desktop and the tablet we've already done, re-arrange it, put it on MeeGo and profit. (Well, ok, that last point is yet to be proven: the product is still in R&D. :)
We can now take pieces of Kontact, be it at the level of Akonadi data delivery or in Kontact widgets written with Plasma, and use them on a phone, in a Plasma Desktop panel or in Kontact where we'd traditionally expect them to be stuck. Today, we can even pull that widget live from Kontact's dashboard and show it on my smartphone with Plasma. Tomorrow, with QtComponents, we'll go even further with what we can do with the presentation on these devices.
In Summary: It's Doing Less For More Reward, Not Just Doing It Different
I really don't care if someone writes their app using HTML5 or Javascript or C++ or Brainfuck. That's highly uninteresting to me. What's interesting is this:
- In how many environments and form factors can I run it?
- Does it look good and work well wherever I run it?
- How much does it cost to write it?
- Does it provide me with all the facilities I want during usage?
(Before you lob security and privacy as additions to the above, realize that those are actually facets of the fourth point.)
It becomes apparent that HTML5 (to continue to pick on it :) is one attempt to fill the above four points with varying degrees of success. HTML5 itself isn't very interesting at all, viewed that way. It is of high interest to groups like Google who have run themselves down the narrow alley of "web browser", but not because HTML5 is, per se, that great but because it addresses more of the above in their delivery channel (a web browser) than HTML4 does. While it certainly doesn't hit 100% on all the above points, it moves the metrics closer in that direction.
Still, HTML5 doesn't do a whole hell of a lot for my delivery channels, and it won't for many others as well. QtComponents, QML, Plasma ... these things do a lot for my delivery channels and does so remarkably better than HTML5 on every metric save one: ease of deployment. This is solely because the web browser is ubiquitous these days, even if HTML5 isn't just yet. When "Qt Everywhere" is achieved (or close enough to it, and terrific progress is being made on that goal), even this will no longer be the case. On all the other metrics, we're already at or headed shortly to a much better solution that is more than just "hey, what language can we write applications in for easier deployment?" Of course, that better solution also works seamlessly with HTML5 content thanks to QtWebKit.
This set of technologies will provide (some pieces aren't done yet, e.g. QtComponents) convincing answers to the device spectrum challenges, the component re-use issues and cost factors while opening doors to deployment. Best of all: without sacrificing existing or impending capability. (Aka "we already have OpenGL, what's so exciting about that?")
This is a set of changes that is being seen reverberating across our UI stack even now. Plasma is built around these ideas today, and whether it's a tablet or a smartphone shell or Kontact, KDevelop and Skrooge using it for a summary dashboard or the good ol' laptop with Plasma Desktop on it, we're getting to see the early days of this shift in how applications are being made and delivered right here in KDE.
28 comments:
Calling Google a walled gardens is not fair given that they go the extra miles to make all of their app easy to export and import data: http://www.dataliberation.org/
Facebook would be more appropriate given that they sue anyone building export tools of their data.
I think that HTML5 is the only way forward for the Free Desktop. No matter how awesome GTK/Gnome and Qt/KDE are and will get, it is clear now that they will never catch up with Windows (on usage). The only way forward is to start building HTML5 offline and online apps, HTML5 is the only universal free, open and portable API to build apps on. This is why we should embrace it IMO.
Really interesting comparition, but one advantage I see if HTML5 over Qt is that HTML5 is an open standar and Qt (and its destiny) is owned by Nokia.
@patcito: "Calling Google a walled gardens is not fair given that they go the extra miles to make all of their app easy to export and import data"
can i take my services elsewhere, as i can with my cell phone? (e.g. keep my phone, have someone else provide the same service with clean hand over of things like my cell #.) can i get access to the tools to host my own "google docs"? can i have google use a data escrow service of my designation? challenge their closure of access to my own data with a mutually recognized third party?
no, even google is a walled garden. not as annoying or evil as facebook, perhaps, but still a walled garden exactly in the terms i wrote about.
"No matter how awesome GTK/Gnome and Qt/KDE are and will get, it is clear now that they will never catch up with Windows (on usage)."
just like it was clear that Toyota would never catch up with GM in usage despite 20 years in the North American market. it took them 30 years to start making a real dent, and GM didn't even have the same market benefits Microsoft does.
"The only way forward is to start building HTML5 offline and online apps, HTML5 is the only universal free, open and portable API to build apps on."
no, it's the only one that comes with ubiquitous deployment. which i covered in this entry, btw :)
"This is why we should embrace it IMO."
if we embrace it at the expense of things like QML, Plasma, etc. we will end up with a vastly inferior future for computing. again, for the reasons i outlined in this entry. good enough is not good enough.
these technologies we are working on not only work with HTML5 (which certainly sounds like embracing to me), they are going to be deployed on 10s of millions (if not 100s of millions) of phones as well as 10s of millions of dekstops / laptops (which is our current market share right now).
the whole "anything that isn't HTML5 is niche" thing ignores what is here now and what it is coming. it is marketing spin put out there by the HTML5 invested, primarily companies like Google who are betting on being able to convince people that it's the "inevitable now". if they succeed in that, using a computer in 10 years will be highly mundane as it will be what we did five years ago on the desktop, only this time finally working in Chrome v78 or whatever it's up to. boring and highly short of what we're capable of bringing.
@Ramsees: "one advantage I see if HTML5 over Qt is that HTML5 is an open standar and Qt (and its destiny) is owned by Nokia. "
everything is controlled, even HTML5. unless you are suggesting that i can somehow walk in an modify it.
Nokia owns the copyrights currently in Qt, but they are not the sole actor in working on its present or future.
this is also, btw, one of the exact same arguments people used to use between Qt and Gtk. seems it wasn't so big of an issue once it all played out, was it?
i look at HTML5 and Qt, and people raise the same spectre, and i have the same response ... only this time there is open governance, an open git repository, an open bug tracker, an open task tracer, multiple "tier one" partners working on Qt (e.g. iNdt, Intel ..)
Nokia may own Qt (and i expect that to evolve over time) but they don't exercise the kind of control over it that makes that dangerous.
@aaron you can export your google docs and edit them in other compatible software, you can export your gmail and use your mails in your own web server. So yes you can take your services elsewhere, Google is not a walled garden in that sense.
> just like it was clear that Toyota would never catch up with GM in usage despite 20 years in the North American market. it took them 30 years to start making a real dent, and GM didn't even have the same market benefits Microsoft does.
Well, if you expect to win in 30 years, sorry but I will not take that bet. Microsoft will never accept Qt as a standard and neither will Apple. I try not to make 30 years predictions, but what I'm seeing right now is that HTML5 seems to be the best standard we have and it's capable of doing almost everything my kde desktop does (especially when the hardware API are implemented, which is soon on chrome and webkit).
And you're wrong, good enough *is* good enough, this is how Windows became dominant, by being inferior yet cheaper and more accessible, just like HTML5. And by the time Qt gets everywhere (whatever that means), HTML5 will already have filled all the missing features. Real people don't care about tech details, they don't care if Qt can do a few more cool stuff than HTML5 as long as HTML5 allow them to accomplish what they need.
> these things do a lot for my delivery channels and does so remarkably better than HTML5 on every metric save one: ease of deployment. This is solely because the web browser is ubiquitous these days, even if HTML5 isn't just yet.
The thing is that Microsoft and Apple will never ship Qt but will ship HTML5 through their browsers. And HTML5 apps are way easier to install, just point your browser to it. Nothing can be that right now and Qt certainly can't. This is huge for free software because it makes it extremely easy to distribute free software apps. More than any Qt or GTK app ever will be. The last 10 years have shown us that people just won't install kde or gnome apps on their desktops but they will install and use new web apps both on mac and windows.
Let's see in 20 years who was right and if Qt or HTML5 will be everywhere ;)
@patcito - "Let's see in 20 years who was right and if Qt or HTML5 will be everywhere ;)"
Although your point seems convincing, I can guarantee HTML5 will have long since vanished 20 years from now. Aaron is absolutely spot on for the near term. Applications must continue to evolve in complexity and usefulness to the user. At this point in time Javascript / html5 simply aren't the right technologies to really take over the rich application market. In the near term, Qt provides a platform that exposes the power of a device to an application and HTML5 and javascript aren't competing at that level.
However, both development paradigms are slowly coming together and soon a real revolution in application development will happen. Right now I will stick with Qt for my professional applications, but that is because I am programming demanding ui's and web solutions even with background compiled javscript and faster browsers can't cut it. In the future you both of you will be happily surprised.
@Jon HTML has been around for 20 years already and it's getting more ubiquitous and richer every year. I think the web is not going away from HTML and as such I'm not seeing HTML vanishing any time soon.
We'll see what happen I guess, but my bet sure is in HTML5 and following versions, not Qt or any other tech.
@pacito: "Well, if you expect to win in 30 years, sorry but I will not take that bet. Microsoft will never accept Qt as a standard and neither will Apple."
The future could be surprising, just remember where Webkit comes from, and how everybody was shocked at the time, sure it would never work out.
HTML5 seems to be the best standard we have and it's capable of doing almost everything my kde desktop does
and yet, i have an application that looks and behaves like a document, that lives in a browser, that can do just right now things that desktop apps do since almost 30 years (think about drag and drop, think about how indeterminate is the result of pressing the back button)
sure, all things that will probably get fixed in the future, but shows up not only signs of an immature technology, it shows signs of solving a problem with the wrong tool, i.e. putting the chrome in a document, because this is what html, evn 5 is, a (even rather good) document format.
And you're wrong, good enough *is* good enough, this is how Windows became dominant, by being inferior yet cheaper and more accessible, just like HTML5.
so, if it's good enough how many iphone users just use the twitter website instead of a more immediate, device optimized and refined client built for that platform?
And by the time Qt gets everywhere (whatever that means), HTML5 will already have filled all the missing features. Real people don't care about tech details, they don't care if Qt can do a few more cool stuff than HTML5 as long as HTML5 allow them to accomplish what they need.
> these things do a lot for my delivery channels and does so remarkably better than HTML5 on every metric save one: ease of deployment. This is solely because the web browser is ubiquitous these days, even if HTML5 isn't just yet.
Nothing can be that right now and Qt certainly can't. This is huge for free software because it makes it extremely easy to distribute free software apps.
This actually akes even more difficult for people distinguish from free to non free software. looking at people that were previously free software advocates use happily services and web applications that are as far from free software as they can (and i'm guilty of that too of course :p) kinda scares me
Let's see in 20 years who was right and if Qt or HTML5 will be everywhere ;)
maybe html5 will disappear, maybe Qt will disappear, maybe they will survive both,
but yes, not always the best technology wins and when this happens, it hapens to all disadvantage for users. As free software developers, we can't do anything but work for the solution that has the potential to be better in the long run for everybody, for users, for developers and the whole ecosystem around it, not being distracted by the "easy path"
@Jon: "both development paradigms are slowly coming together and soon a real revolution in application development will happen"
exactly.
those who see the world in terms of either/or are doomed to fail to see this.
Well I was the one with the first comment on the new Kontact summary page.
Who is going to provide a consistent look? Who will work on that?
The thing I fear is that "(a) improved what is already there" will not happen, the main priority -- provide a lot of information in a easy graspable, consistent (with the rest of the program) way as fast as possible -- seems to degrade.
In any case I hope that the discussion will remain there and not be here, so I'll also post that post there.
@patcito: "Well, if you expect to win in 30 years, sorry but I will not take that bet. "
it's not a 30 year prediction. it's a prediction of where we are, 15 years in, compared to another industry that took 30 years to relinquish its top spots.
it's not precisely 1:1, and we are not at the beginning. we are much further in that that.
"good enough *is* good enough,"
not for me it isn't. i'm talking from the perspective of a technology creator. that aspect is not about adoption, but about what we can achieve.
"this is how Windows became dominant"
no, actually, it isn't. Windows became dominant due to an interesting mix of corporate politics.
that rather frighteningly mirror what's happening with Qt right now.
if you truly understand how Windows rose (through all stages, from the openly documented PC hardware arch, to IBM's silly contract with MS, to the transition from DOS to Windows 1.x then to 3.x) one can see the parallels.
"The thing is that Microsoft and Apple will never ship Qt but will ship HTML5 through their browsers."
you are too hung up on the definition of "platform" when it comes to "desktop". that ship has sailed, though not in the way you evidently think.
the desktop is going to become much more influenced by and dictated by mobile, but without going away in the least.
"Let's see in 20 years who was right and if Qt or HTML5 will be everywhere"
you completely miss the point. it's not one OR the other. it's which one can do the other and then more. HTML5 can do HTML5. Qt (with QML, plasma, etc) can do HTML5 and a whole lot more. HTML(some_version) will absolutely, definitely be there. it has lots to offer, especially in the right context. but so will Qt. and Qt will, imho, become part of the background (like apache is now) and be a primary mechanism to deliver HTMLx to the user ... and that HTMLx will be wrapped inside of even better things from Qt. and sometimes there won't even be HTMLx, just the Qt stuff.
i've seen what people are doing with both HTML_awesome and with cutting edge Qt, and i know which things can be replicated with each in a realistic fashion.
but yes, i don't expect to convince you. nor do i care to. my statement will stand, and if you have as long a memory as i do we will revisit this down the road.
humorous thing: even if i'm proved right, chances are you won't agree with my predictions then either. it's how people are. i've been doing this for a long while now. :)
@mat69: "Who is going to provide a consistent look? Who will work on that?"
the same people who have the done the work thus far. we work iteratively, but we don't leave things unfinished.
@aseigo, please, would you mind disucssing at the other blog? Otherwise it gets pointless pretty fast.
I did not understand fully the points but I just want to press my opinion that pushing apps to cloud is just silly and stupid.
All applications really should stay on the computer. It is about freedom, easyness and maintaing choises.
Cloud is currently just a hype what is used to sell a long existing services again as a new innovation. While they just are selling yesterdays bread as just baked one.
The webapps is as well little bit misunderstanded as everything would be app, while they just are web services.
And HTML, Javascript etc were never intented to replace the applications. They are slow, more difficult to actually maintain and protect.
Now the whole HTML5 talk is going to direction where we should start all use one and single coding language for every possible software.
> it's not a 30 year prediction. it's a prediction of where we are, 15 years in, compared to another industry that took 30 years to relinquish its top spots.
But 15 years is huge in our field. If you can't make it in 15 years you'll probably have a hard time ever making it. We've been in it for 15 years and we're still at less then 5%. It's time to realize we're not going to make it, at least not with Qt, the web on the other hand is looking good with html5 and all the great web apps.
> not for me it isn't.
But you're not the one that matters here, the consumer is, and for the consumer good enough is good enough.
> no, actually, it isn't. Windows became dominant due to an interesting mix of corporate politics.
Yes, there are many reasons why Windows became dominant (including luck), but being good enough and cheap was one of them.
> the desktop is going to become much more influenced by and dictated by mobile, but without going away in the least.
agreed.
> Qt (with QML, plasma, etc) can do HTML5 and a whole lot more.
But it doesn't matter, why would I code anything in Qt if nobody is going to use it? Same reason I don't do iPhone apps in ObjectiveC. I want my apps to run everywhere with an open free API. And Qt doesn't give me that. Sorry but I'll stick to HTML5.
> and Qt will, imho, become part of the background (like apache is now)
I'm skeptical about that. I mean Nokia just got crushed on the mobile side by both Apple and Google. I don't expect them to conquer the desktop and become an essential part of it if they were not even able to keep their place on the mobile side. But we'll see.
> humorous thing: even if i'm proved right, chances are you won't agree with my predictions then either. it's how people are. i've been doing this for a long while now. :)
I'd be glad to admit you were right if Qt takes over the world. Though I wouldn't bet a dime on it.
@patcito: "But 15 years is huge in our field."
yes. it took that long for the web to take off. it took somewhere around twice that for email. PC's? Excel over Lotus 1-2-3, even with sneakiness? mobile phones? etc.
new products happen often, but actual sea changes in the industry are not swift. people often confuse "rate of product introduction" or "rate of innovation" with "rate of industry change".
"If you can't make it in 15 years you'll probably have a hard time ever making it."
go tell that to the mobile phone industry. or to Linux, which took a decade to really make any sort of real dent in the server and even long for embedded.
and those were easy markets compared to the desktop.
"We've been in it for 15 years and we're still at less then 5%."
i thought it was less than 1%? ;P we're making progress. today N%, tomorrow N+x%. as long as it is growing, it's fine.
and mobile along with other form factors represent an opportunity to skyrocket those numbers.
"It's time to realize we're not going to make it, at least not with Qt,"
it makes zero sense to look around at the progress being made, year over year, which is picking up pace and then go "ok, you know what, let's just give up now." if things were stagnating, if we weren't making progress, sure. but that's not the case. we need to be less impatient and driven by marketing kool-aid.
running to perceived safe harbors that are actually just the hoped-for program of special interest groups (e.g. "cloud" companies) is to play someone else's fool. they aren't holding up HTML5 because it's good for us, they are doing so because it's good for them. and if it happens to be good for us, that's nice, but that isn't a given.
so we need to step back, assess and figure out if it really is the best thing for us. if it isn't, we have no requirement to make the future that Google wants just because they spin a fine tale.
"the web on the other hand is looking good with html5 and all the great web apps."
... that don't give us a free software platform anywhere but the server.
and honestly, html5 doesn't answer any of the interesting challenges we are facing in app development, not in the least. device spectrum, as one example? nothing other than ubiquity (which is valuable, but not really the challenge faced there).
"But you're not the one that matters here, the consumer is, and for the consumer good enough is good enough."
good enough is defined within the context of the options that are perceived to exist on the market. if we make better-than technology (not just products, but what underlies them) and provide awareness of those things, then the definition for the consumer of good enough shifts. which is why good enough, as a technology creator trying to expand reach, isn't good enough.
"why would I code anything in Qt if nobody is going to use it?"
that's both a leading and a misleading question. and if we went back 15 years we'd be saying the same thing about web browsers. oh wait, we were!
btw, i was a very early champion of web based commerce. people around me thought i was a dreamer. i was just early.
unfortunately, the people who were to flood into the market that arose had zero vision and utterly missed the possibilities of commerce on the web, which really should have been much more about automated and dynamic virtual supply chains than "i've set up a store with my own backend for $foo." the web is a gigantic archipelago, and even with "web 2.0" it has hardly shifted. now it's an archipelago with some shaky bridges built from the bigger islands to some of the smaller ones.
"Same reason I don't do iPhone apps in ObjectiveC. I want my apps to run everywhere with an open free API. And Qt doesn't give me that. Sorry but I'll stick to HTML5."
there is no HTML5 on the international space station. you don't care, though, do you? because, while being technically part of "everywhere" it really isn't somewhere you care about. it's not your target market. that's critical to understanding the "everywhere" argument more clearly.
HTML absolutely has the highest level of ubiquity.
it also has one of the crappiest set of capabilities. and as we race forward into an era of devices, mobility and organic interfaces, HTML will continue to play catch up until it is simply another language with all the ugliness and complexity of everything else.
WebGL is an interesting example. great, so now you can write OpenGl code using Javascript (which i've seen elsewhere years ago, btw). it still doesn't help much if there isn't good or any OpenGL available, no? just like any other toolkit. as it expands, it will inherit all the fun and horror of every other toolkit out there.
meanwhile the other toolkits are moving forward into new spaces. they aren't sitting still.
and for many people the footprint of Qt is big enough. it may not be for you, and HTML5 may do everything you want. which is awesome. and we can put your HTML5 things in our Qt based envs.
we can also put the Qt based things that HTML5 can't touch in our Qt based envs.
in a world where it's all HTML5, we live with its limitations. and they are too severe to realistically call it the desirable future.
unless you're Google et al, but then that's a business decision and nothing more.
> go tell that to the mobile phone industry. or to Linux, which took a decade to really make any sort of real dent in the server and even long for embedded.
I don't know, it took google a few years to get a huge market share, same for linux on the server or even the iphone. Linux on the desktop has been around for 15 years and it's still unused (I was being generous with the 5%). I still have to see anyone using a linux laptop in airports ;)
> ... that don't give us a free software platform anywhere but the server.
Really? HTML5 allows for offline apps to exist. Google chrome webstore already offers both connected apps and "stand alone" apps, those are HTML5 apps that only work offline and do not require a server at all. A detail that many devs opposed to HTML5 like to forget (for some reasons).
> device spectrum, as one example?
Well, it works on cellphones, tablets, laptops and desktops, not that bad. It's entirely possible that astronauts would be using tablets with html5 apps ;)
> that's both a leading and a misleading question. and if we went back 15 years we'd be saying the same thing about web browsers. oh wait, we were!
Somehow, I've always wished that would happen. Web apps are so much better. The concept of forward/backward and hyper-links just make them way better than any "native" apps IMO.
> there is no HTML5 on the international space station.
For now, again, remember HTML5 allows for offline stand alone apps.
> it also has one of the crappiest set of capabilities.
And yet, gmail is so much better than kmail, evolution, outlook or osx' mail. It never freezes like kmail, search is super fast, labels are better than imap folders etc. See, HTML is good enough and allows to write better apps than with Qt, even if Qt is superior (for now). HTML is good enough to write better apps than with Qt.
> in a world where it's all HTML5, we live with its limitations. and they are too severe to realistically call it the desirable future.
But I like its limitations, it forces us to focus and not build bloated apps like it happens sometimes with Qt or other native toolkits that just offers a blank canvas with no limitations at all, that invites bloats (hint: many kde apps ;) ).
Also, HTML5 is improving everyday. It won't be long before it has all the features of Qt. And as I said, it's already good enough to write better apps.
By the way, isn't there a port of Qt on chrome's native client? :D
propably one day my CAD program runs in the browser with html5 and javscript. and the whole desktop gets reinvented in the browser and if I want to surf the web I just launch a browser in it which is completely done in javascript (for security reasons... as I don't want my whole desktop getting hijacked). It just started we're making real use from all the CPU power we have today... good we have html5 and javascript to waste all these CPU cycles again.
I don't mind using "webapps"... It's not one technique vs the other. html5 _adds_ a new stack of possibiliies to the existing ones, but it was not invented to replace the basic infastructure (and will never be).. just as a new on-board computer does not make any sense without a (good old) car.
Another 2 cent: Atm a lot of talk is about "downsizing". Netbooks, tablets, phones... it all points in the same direction. That's called a trend.
Next step is in the other direction. Speak: bigger PCs with more memory, freakin fast CPUs and huge displays (starting to get more and more affordable) probably with some new sorts of input methods, but our KDE desktop has all the abilities to really shine on these tomorrow computers. It'll come with stunning effects and will provide a great "desktop" experience. The foundations are already laid. And everybody will drool over it... ;-)
@Patcito
"I don't know, it took google a few years to get a huge market share, same for linux on the server or even the iphone. Linux on the desktop has been around for 15 years and it's still unused (I was being generous with the 5%). I still have to see anyone using a linux laptop in airports ;)"
If you'll raise your head above the States then you should realize Linux' marketshare is higher then OSX. There are no real reasons to choose Apple. It's much smarter decision to buy laptop with Linux preinstalled and you get all of this what Apple offers plus many, many more. People are starting to realize this. Similar situation is on the embedded market where Android is killing iphones. Btw. Linux is conquering desktops since the first Ubuntu release imho, so not since 15 years, but since few. Apple is trying to conquer desktops since beginning and they're nearly nowhere. Linux is just too great to be stopped. :)
@patcito: "And yet, gmail is so much better than kmail, evolution, outlook or osx' mail."
In which browser? I mean, which browser allows gmail access to its crypto API and thus enables the user to createo or verify signatures, decrypt or encrypt mails?
Since when is this possible?
> but our KDE desktop has all the abilities to really shine on these tomorrow computers. It'll come with stunning effects and will provide a great "desktop" experience.
I have a reasonable laptop with 2gb of ram and an Intel gpu and dual core cpu and I still have to, even with 4.5.1, turn off desktop effects otherwise it just blows. I use KDE for kmail, konsole, kate and akregator and I'd be quite happy if/when they run on top of a plain Qt/webkit desktop that allows me to mix and match browser based HTML5/JS and QML applets. Whatever let's me glue it all together with Javascript wins and html5 + nodejs is probably going to be that primary glue. Declarative UI / QML / HTML5 / DOM (browser) and now NodeJS (server side and console JS) all rely on Javascript. It's the only language that runs in all 4 contexts (browser, gui, server side, console) on all platforms as of about 2011 onwards. Websockets, webworkers and local storage glued together with javascript (ie; HTML5) === FTW.
@markc: "I use KDE for kmail, konsole, kate and akregator and I'd be quite happy if/when they run on
"top of a plain Qt/webkit desktop that allows me to mix and match browser based HTML5/JS and QML applets."
that's called "Plasma". only we aren't language nazis and don't force people to write everything in QML (though that becomes an option in the 4.6 release) or HTML5.
"Whatever let's me glue it all together with Javascript wins"
why do you care, in the least, what language they are written in?
saying "this language provides features i want" is a great reason to choose that language to write your app. but as a user, that's not what matters. what matters is that list of items in the blog entry. that's all. who cares what it is written in as long as it matches that.
"It's the only language that runs in all 4 contexts (browser, gui, server side, console) on all platforms as of about 2011 onwards."
i don't care what the app on my phone was written in and i don't need it running on the server. the "glue" that holds them together isn't magical Javascript being remotely executed with results sent back to the device (well, technically that's kind of what we do with remote widgets in plasma), it's protocols and networking. old technology.
"Websockets, webworkers and local storage glued together with javascript"
you do realize that these are all wrappers that take things we have N different ways for programmers to do right now and shove them into an HTML / JS context, right?
it isn't the language, and it certainly is _not_ the HTML5 features (they are still playing catch up to last century's capabilities) or HTML5's flexibility (language choice of 1).
it's the capabilities. and there are much better ways of achieving those capabilities. HTML5 is a step for HTML to get closer to those capabilities. it isn't the best way, nor will it be the obvious choice because it becomes the only realistically available one.
how many times has this industry been through that dream before? and still everytime someone reinvents the old, only this time MORE COOL everyone proclaims it will be the end-all-be-all.
these things displace, not replace. and that isn't a phenom of computers. it's one of tools, particularly ones around information.
> why do you care, in the least, what language they are written in?
I'd be repeating myself if I said Javascript is the ONLY language that runs in all computing domains on all platforms more or less from 2011 on. As a developer I don't want to waste my time beating on dead horses. As an end user I want to rely on whatever provides a universal long term presence and whatever architectures revolve around a Javascript foundation gives me that confidence like nothing else does. It absolutely matters.
I don't really see what's the hoopla is all about. Why everyone is so convinced HTML5+JS is the future of cloud computing, let alone the future of IT?
Take C++ and Qt. You can write application for Chrome using C++ and Qt today: http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/
Yes, Chrome is not the most popular browser, it has only three or four times as many users as there are Linux users. Will it be possible to use Qt to write programs for other browsers? Noone can predict the future but I don't see why it'll be a problem: technology is open, it's matter of poring.
I'm not sure how big "cloud computing" will be, but I can safely say: if it'll not go beyond HTML5+JS it'll never replace the desktop. Google (one of the biggest proponents of cloud computing) knows that - that's why you can write apps for Chrome using Qt today.
Perhaps it's good idea to think about "KDE for the Web", but to just drop everything and switch to HTML5+JS? This is insanity.
I have a question about Plasma widgets:
http://techbase.kde.org/Development/Tutorials/Plasma/Web/GettingStarted
Is it possible to create a web widget which just runs a website?
So the widget would only contain code to display the remote URL, like the Mac OS X Dashboard example here:
http://davebalmer.wordpress.com/2010/10/06/jo-cross-platform-demo-screencast-up-on-youtube/
http://youtu.be/wOjfKA23Of8#t=10m15s
@ReneL: "Is it possible to create a web widget which just runs a website?"
yes. in the metadata.desktop just put:
X-Plasma-MainScript=http://mywebsite.com
Post a Comment