To read all comments associated with this story, please click here.
The DOM issues are mostly browser specific problems.
You still have to battle beast of Redmond on a daily basis if you have to serve the public at large though.
Nice giant swaths of missing features...
http://www.findmebyip.com/litmus/
Especially the extremely useful CSS3 stuff.
But worse is its random bugs with canvas... yuck..
And with the latest version of IE for XP being IE8... Talk about random bugs... IE8 is the new IE6.
Thank god we don't have to deal with IE6 or IE7 as much anymore... IE7 was God's punishment for me complaining about IE6 for so long :-D
Somewhat related: if you want to make the world a better place for all us web-developers, spread the word that people stuck on IE7 or IE6 can install Chrome Frame without admin rights on their machines!
YAY: http://www.google.com/chromeframe
It won't break anything because it's only triggered if the website they visit specifically tells it to be enabled.
Maybe HTML5 will bring about world peace in another 5 years 
The problem with HTML V5 is...well...its a pig, it really is. Everyone is pushing it as a flash replacement but frankly I can open SD flash on even the 1.8GHz Sempron I keep at the shop for a nettop and the video is smooth, even without any GPU acceleration, whereas with HTML V5 I've found anything short of a dual core to be a slideshow unless you have a dedicated H.264 decoder onboard.
I have a feeling we are gonna look back in 3 years and go "Remember Flash? I really miss that" because unless they figure out a way to fix it HTML V5 not only supports just a subset of the use cases Flash did but it does so while sucking CPU cycles like a drunk sucks down a free mini-bar, its just plain awful.
The problem with web apps is that (originally) HTML was mostly designed/intended for static documents. For remote applications there were other protocols (e.g. X).
Since then, many different people with many different goals have hacked up work-arounds/extensions to solve problems caused by "not intended for remote applications to begin with" (and problems in other areas, and problems caused by other people's hacks/work-arounds). Because the result is a steaming pile of puke, other people try to create frameworks, etc to hide the underlying puke-fest (but the existence of many different frameworks just adds to the unnecessary complexity/confusion for web app developers, like a thick layer of turd icing on top of a multi-layered puke cake).
The basic idea is that the server tells the client what to display, what user input is allowed and what user input the server wants to know about; and the client displays what it's told to display and gathers the input from the user. It wouldn't be hard to create a clean/elegant way of doing this.
Sadly, the only organisation that would be capable of getting a clean/elegant alternative accepted/supported by the industry is the same organisation that is responsible for a lot of the ungodly mess we have now (W3C).
- Brendan
This happens to most software eventually, It out grows it s intended use.
TBH, if you keep JS, CSS and HTML actually separated and adhere to that you can write some pretty good maintainable webpages. Unfortunately most web developers think well made means "It works okay in my version of Firefox/Chrome".
Edited 2012-10-02 04:55 UTC
That is why after a decade in the trenches trying to bend the browsers to do stuff they were never intended to do, I have switched my mind and now state if you want an application, make it native.
As it should be in first place, browsers are for documents.
Cool startups like to say how the web is the future, but they never have to discuss layout issues or look-and-feel, of browser behaviour vs OS defined guidelines, to get the customer to pay the project.
Or browser performance vs native performance for that matter.
In the end, applications should be done native. Easiness of installation can be achieved with things like ClickOnce, Java Web Start, or simple package repository.





Member since:
2010-05-14
I've heard somewhere that the problem with making web apps isn't with JavaScript but with the DOM. Does this new super-set of JavaScript do anything about the DOM or is it just more stuff dealing with the language?
If not I think someone should get cracking on a DOM replacement instead of all these new languages. Also if this is really EcmaScript 6.0 or something why not call it that instead?