With about nine months of work behind me on platforms designed from the ground up to support rich, interactive UIs (Android & iOS), the mess of JS, HTML & CSS just seems so gratuitously painful in comparison.
From a philosophical standpoint I'm rooting for an open, interoperable web as much as anybody. As a programmer though it's hard to feel much enthusiasm for such a fragmented, baroque, and inadequate toolkit.
Writing your application in Javascript, using HTML and CSS as just the drawing layer (much like how iOS uses OpenGL behind all of its views), can make web development nearly as enjoyable as native platform development.
However, it also defeats the point of using HTML in the first place. When you abstract everything away to make the development environment sane, you abstract away the features that make HTML useful, like the ability for the markup to be interface agnostic.
I often feel the browser should become what Java was intended to be and let HTML and CSS be one application of that system. It is the direction we seem to be heading. Giving the applications a more direct path to the hardware is the natural evolution going forward. Why are we fighting the HTML/CSS layer? It is surprisingly accommodating, but adds a lot of needless overhead.
I think any cross-platform open standard is going to be at a serious disadvantage compared to a good native environment. There are just too many conflicting interests and cooks in the kitchen. This didn't matter much when the net consisted mostly of static content but as people come to expect richer and more immersive experiences the impedance mismatch is more evident.
I'm not so sure abut this, if you go back ten years most people had exposure to one platform and their web experience was limited to filling a few forms.
Now the experience is much broader, many users will have a smart phone, maybe a Mac at home and PC at work, then throw in the use of web applications like Google Docs and the whole interface landscape has become much more diverse.
Leaning towards the web as a user interface guide makes as much sense for most developers as anything else.
The web was originally conceived as documents, not interactive content. It's done fairly well, but we could sure use an addressable content and application space that is not always tied to the limits of HTML.
One thing the richer mobile toolkits leave out, that drove the web's success, is the "view source" feature, a tremendous way to on-board new developers.
This doesn't necessarily have to be at the UI level. If sites have a well defined API they can still be indexed but serviced for users by native apps. In fact, this is better than kludgy scraping.
For that you'd have to have a standard API with indicators of content importance. Even then it would be akin to keyword meta tags which are bad representations of site content in general.
I haven't found Android UI to be that much better than html and the rest, you still have to say where everything goes and then write the code to tell it what to do.
Browsers are at a disadvantage because they need to have a ton of security built in because people casually go to websites, whether or not they are malicious, but are more hesitant to download an app. Also if an app is malicious it can be removed from the store, taking down a website on the other hand is not an easy feat.
Android layout is so much saner than CSS layout though. The different Android layout models make it really easy to specify complex arrangements and the Android tools make wiring up behavior a lot easier. Compared to the mess that is cross-browser CSS it's a breeze.
Maybe it's just me but I also find that Java's static type checking eliminates a lot of the dumb mistakes I tend to make in JS/Ruby/Python.
Things are definitely getting better in HTML5 land but it's still a crap sandwich compared to a good native platform. I hope in five years I won't have to say that anymore.
HTML, CSS and the DOM can for sure be improved, but personally I miss their flexibility when I need to develop with most native frameworks. I never tried native Android or iOS yet, but if they force you to create all the UI elements procedurally instead of descriptively, like most native frameworks I know, I guess I wouldn't like them very much too.
We create a lot of mobile apps; we offer our client the choice, always, and they always pick cross platform. From a client point of view, they don't see this as a subpar experience; they have their app delivered rapidly, it looks great (as the designer just delivered PSDs or PNGs which look EXACTLY like the client wants), we cut it pixel perfect to something crossplatform (depends if it's a game or normal app or combination what tech we use for that) and in the end the client receives what they saw in those first screens they had made on their mobile. Generally looking better than 99% of the native apps out there; the top 100 of iOS apps sure look good (well... not even all of them...), but below that it rapidly degrades. So unless you are doing something cutting edge, I cannot agree with your statement here.
Having said that, we do native apps as well; on iOS the experience is better, but you'll be paying a bit more to get it to that point. While on Android, it is just very very hard to get something as nice looking as we can do it in HTML5. It can be done, but personally I don't think it's worth it. For our development process we use 'business value' as a key indicator of deliverability and the difference between the PhoneGap apps and and native apps on Android do not deliver enough (actually any) business value to warrant the higher price tag.
JavaScript is hardly to blame for that. You could create your HTML & CSS in any language you like, yet I don't think any solutions that are really pleasant to use exist.
With Windows 8, Microsoft is ushering in native JavaScript apps. It's probably in their best interest to keep developers firmly in the JavaScript camp—the more JavaScript developers their are, the more developers there are for whom native Windows 8 development will be second nature.
Unless Microsoft adopts Dart, I see them fighting hard to improve the JavaScript development experience.
I feel very uneasy about this. JavaScript is great because it is so simple. All the things mentioned sound as if they add unnecessary complexity.
Why not just leave JavaScript alone, and push for a more universal way for browsers to run code? Then different languages could be used, and those who want it could program with more advanced languages (or whatever they deem to be advanced).
No, more like creating a VM. JavaScript is essentially the VM now, but I suppose something more universal could be created (more suitable for accommodating all sorts of languages).
Google has two efforts in this direction, the Dart VM and PNaCl. On many levels both are about as ideal as you could possibly imagine. However there is virtually no chance either is going to be adopted by other browsers. Neither are standard and both would require adopting huge new toolchains and codebases.
And you don't have stop there. Want advanced pattern matching? Want logic programming? Want delimited continuations?
You don't need to wait for Apple, for Google, for Mozilla, for Oracle. Language development is too important to not happen where development happens best - in the field and in open source software projects.
Not sure what's optimistic about it. Those features are there. You don't need to wait for them because they were easy to implement from w/in the language itself. Same way you traditionally build libraries.
All those companies are moving their languages and libraries at an incredibly slow pace and will continue to do so (since their languages don't really give them any alternatives). Nothing pessimistic about that. They are large companies with little room for flexibility.
I'm looking forward to discussing this, but in the meantime, can anyone parse "Similarly, I think we can find a way to repair “this” binding foot-guns with softly-bound “this”." for me? I don't understand what "binding foot-guns" are.
1) "this" binding is dangerous - you can easily shoot yourself in the foot with it (it is a "foot-gun").
2) "this" binding can probably be repaired with softly-bound "this".
There's no such thing as "binding foot-guns", the phrase breaks down between "binding" and "foot-". But "'this' binding" and "foot-gun" are both somewhat obscure phrases so this probably was not as clear as it could have been.
foot-guns are guns used to shoot yourself in the foot. Binding is a complex thing to get right, and it sounds like putting the "this" reference into Javascript correctly so it doesn't cause problems (and cause you to metaphorically shoot yourself in the foot) is requiring effort.
From a philosophical standpoint I'm rooting for an open, interoperable web as much as anybody. As a programmer though it's hard to feel much enthusiasm for such a fragmented, baroque, and inadequate toolkit.