e.g. I needed to pass the parameters derived from a dynamically created user interface, plus some other structures such as an array of objects to the server.
I went with a form as then I don't need custom marshalling code on the browser end, but then I needed to manually encode/decode the array. It didn't take too many LOC to do it in the end, but it took a long time to find out what those LOCs were (albeit most of the time trying to work out how to access the app server jaxb context and how to use it to decode some json embedded in a form field).
But what surprises me about 'javascript' is just how un-script like it is. i.e. it only provides fairly low level of functionality and one has to code a lot of stuff directly. And that's before you get to some of the nasty per-browser differences. So because of both you end up with a pile of half-arsed helper api's which should really be part of the browser - and would be if the vendors could stop stabbing themselves in the back at every turn.
e.g. although you can submit a form, if you want to submit it silently you need to manually create the HTTP data packet yourself ... which is something you don't even get close to having to worry about at the server end anymore and haven't had to for years.
And the other problem is that clearly most people who author javascript just aren't coders, or aren't very good ones. So many of the solutions one finds on the net are full of bad advice, misinformation, or are just pretty much crap examples as a direct result of the blind leading the blind. So perhaps my previous issue is just a matter of finding the wrong blog post or stack overflow question ... but who can tell? (On stack overflow, it seems to be starting to suffer from the wiki-disease a bit, anal 'save the children' do-gooder watch-dogs who want to get thingy about asking precisely the right type of question in precisely the right location: I hope this attitude gets killed quickly as such crap can rapidly deteriorate).
The language itself is ok enough I guess - although anyone wedded to IDE auto-completion (like my work-mate) is lost due to it's dynamic nature, but the browser supplied run-time platform is a total joke. This is pretty much what I suspected and wrote about previously but to have it confirmed is no point of joy.
I'm still left convinced that Apple's embrace of 'HTML5 will save the world' for example is just a cynical part of their marketing campaign against Adobe, and additionally an avenue for people to buy their hardware, realise it just isn't up to the job, and force them to write custom applications then tied exclusively to their proprietary platform. The greedy pig-fuckers.
2 comments:
I think on the contrary that Apple does not want to push HTML5. It would make developers go out of their walled garden. From what I see the real defender of HTML5 is Google and they are pushing it hard (check http://www.html5rocks.com/en/ ). Because Internet is their platform. They are also developing Dart as a JavaScript alternative. Whic is much saner language.
I admit i don't follow apple too closely, but i was under the impression it was being pushed as an alternative to flash. Anyway, the conclusion is the same regardless.
Obviously mozilla's future is the most dependent on HTML5 and the browser being an application deployment platform.
Google like to solve every problem in their own way: I think a direct result of being over-manned by PhDs who are know they are "smarter" than everyone else. They may well be, but every solution to real problems is a compromise and going alone just doesn't work well long-term. For example what happens when the next intake of graduates adds more smart-arses who know they've got the perfect solution "this time"?
Javascript the language isn't really the problem (unlike say, php which is a shit language), it's more the broken and limited platform that a browser provides (I did even more hacking subsequently and it only re-enforced this view). Google going out on their own is just more of the same. It is also not the right language for every problem: e.g. one doesn't write a 50KLOC desktop application in perl because it isn't the right language to do it in.
And dart is still just going to be another C-like language: apart from a bit of different syntax there's relatively little to distinguish almost every one of them.
Post a Comment