Hard Truths About HTML5 265
snydeq writes "Peter Wayner discusses a number of hard truths Web developers must accept in making the most of HTML5 — especially those who are looking to leverage HTML5 in hopes of unseating native apps. 'The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem. Its additional features are compelling and will help make Web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchronization challenges, and politics should have us all scaling back our expectations for the spec.'"
Holding off using it for other reasons (Score:4, Interesting)
Frankly, the spec is a bit of a joke.
The semantic tags are out of date before the spec has even finalised, because it doesn't cover thing like comments tags which are prominent in todays sites, illustrating what a dumb decision it was to add a bunch of random semantic tags based on an arbitrary web survey carried out years ago. Semantics should be applied to classes just like styles are using a semantic definition language. This would of course have the advantage of allowing 3rd parties to produce semantic definition archives for no longer maintained sites etc. that browser could look up but well, there you go, that's what happens when people who apparently don't have even the slightest grasp of separation of concerns get their hands on something as fundamental as an HTML spec. It's like they didn't even realise why it's better to not have all your styles embedded in your document structure markup - i.e. your HTML and hence why CSS was developed the way it was.
Thus far it seems to have taken the web backwards in terms of compatibility, many of the new features work differently in different browsers, harking back to the days of HTML3/4 and Netscape/IE battles.
XML syntax seems discouraged which means you'll run into more people using the SGML syntax which seems to be pushed more than XML which makes the web more of a ballache to work with- no more of a push towards simple XSLT to trivially move data around and into and out of web displayable formats and instead a push away from that. I don't really care if it's served as XML or not, the point is that if it's not well formed XML it becomes a massive ballache to deal with, because XML tools and libraries are so prevalent.
The ethos surrounding HTML5 is that well, lots of old sites didn't follow newer standards, so lets make those web sites standard by taking everything they did shit, and making that standard. So great, yes, let's make shit, the standard. No, that's not how standards work- standards define a high quality that allows maximum compatibility which developers should strive to adhere to, if some don't then don't cater to them- just point out they're shit because they're not standards compliant.
Really, I don't think I'll touch it unless it gets to the point where you can't avoid it. I think I'll wait for a spec that's written by adults than a bunch of PHP kiddies who don't have the first clue about how to right good web software, and instead prefer to bung any old shit into the mix and call it a standard. Not to mention the drama about it being a living standard- good standards don't need to be living, good standards are generic and flexible enough to be future proof for a good number of years - you know, like, say, the XML spec.
It's not that I don't like some of the new features proposed in HTML5 like canvas etc., I think they're great ideas. It's just a shame the rest of it is just so painfully amateurish from a software development perspective. The net result is a spec that basically takes the web back to where it was 10 years ago- a messy inconsistent mess of arbitrary tags that needlessly duplicate functionality, causing annoying ambiguity with a dash of incompatibility chucked in to boot.
I'm hoping for a quick iteration to XHTML6, run by people who actually know what they're doing so we can just bypass the mess that is HTML5, but that's probably a bit much to hope for.
Native Apps gone? Not in the next 10yrs at least (Score:4, Interesting)
I've done extensive, years and years of programming in Native apps and I have done quite a few years in web apps too; using various stacks and languages.
The idea that the browser is going to replace a rich client any time soon is, in my view, a fools errand. I pity those who have thrown away perfectly good money over the past 10 years trying to make this happen. There are some success stories, like webmail and web-chat and various cloud services; but these things are comparatively simple animals in terms of their data/user complexity. Also there are alot failures which have cost alot of people money.
Browsers have slowly, very slowly eaten into rich client app space. But as soon as complexity of the application reaches a certain level, i.e. level of complexity you typically encounter in an accounting or stock control system, then cost to build the product becomes prohibitive and the UI suffers significant limitations.
Webapps are harder and more expensive and more time consuming to build, and the end result is typically a poorer UI experience. Imagine trying to write something like Gimp, or Open Office, or an accounting package as a web app as opposed to a rich client? Massively more complex. HTML/HTTP has come a long way, but it has to go alot further still if it is ever going to be beaten into a semblance of an architecture that is going to give the rich client application domain a run for its money.
I think it is inevitable a cloud architecture will emerge that kills the native rich app, but I am highly doubtful that HTML/HTTP will be powering that architecture.
The concept of browser is wrong. (Score:5, Interesting)
Before modding me to oblivion, please hear what I have to say.
The whole concept of browser is wrong. Browsers are a good solution for serving static documents; it is not a good solution for delivering cross platform dynamic applications.
This article about HTML5 proves that no matter what functionality is hardcoded into the specifications, developers might need more or different functionality.
What is required for serving today's distributed world is a mechanism (a service) that does the following:
- lazy downloading of software components (data and code). Code and data are downloaded only when requested. The mechanism makes sure the code/data are cached locally, so as that if the network fails, the application is still usable.
The current technology fails at this because the downloaded software components can only be one of these:
a) Javascript, which comes with a lot of disadvantages (browser needs to have a Javascript interpreter/compiler, Javascript itself has lots of disadvantages etc).
b) a binary file that requires the installation and maintenance of an add on (flash, Java, etc), which in turn does its own maintenance, adding services to the core O/S etc.
All the above could be avoided with a unified component management mechanism.
- automatic versioning of components. Code components should be automatically versioned by the compiler, so as that the linker at the client side can request an updated component only if the available version is newer than the locally cached version. Downgrading would be automatic if the newer component's symbols do not match the symbols required by another component. The mechanism should keep the old versions of components around in case some component cannot work with the newest versions.
The current technology fails at this, because although the browsers check the version numbers of the add ons against the browser, user interaction is required for the acceptance of a solution (i.e. the users have to accept the new versions by clicking OK, meaning that they know if the new version is appropriate for them).
- both native and bytecode components. The component service should be available for native as well as bytecode components. The service will run a virtual machine, the definition of which should be a native component downloaded lazily and cached as described above.
The current technology fails at this, because it doesn't even have the concept of a component, let alone the concept of native or bytecode component. Browsers only know of addons and extensions, and each browser comes with its own addon and extension model.
- a binary (i.e. non-text) metadata protocol. All information exchanged over the network, including software components and data components, should be written in a unified metadata protocol. The protocol itself will not specify semantics, it will only specify structure. Think about this protocol as a binary version of JSON or XML.
The current technology fails at this, because all the used formats are text-based.
I know many people will disagree with the binary protocol and prefer a text protocol. The text protocol doesn't really offer any advantages over such a simple binary protocol. The main advantage of the binary protocol is speed, because of the much less data required to cross the wires compared to text. The main advantage of the text protocol is that the text buffers can be inspected as they are, but if the binary protocol is simple enough (as is JSON, for example), then very little work would be required to make a tool that displays the contents of a binary buffer.
Think about it this way: the cost of writing a tool that displays the above-described binary protocol's contents is extremely minimal when compared to the savings from using the binary protocol.
A unified communication language between computers is extremely necessary as the first basic step for inter-operation between computers: computers may not understand the semantics of the data, but at leas
Re:"Software engineers" don't do web programming (Score:5, Interesting)
<cffunction name="add">
<cfargument name = "x" type = "integer">
<cfargument name= "y" type = "integer>
<cfset var result = x + y>
<cfreturn result
</cffunction>
I wish I was kidding. And yeah, I -do- know about cfscript.