Slashdot Mirror
Hard Truths About HTML5
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.'"
Seriously, how is this hard? Don't trust the client, store things like geolocation data and other such things server-side.
Sure, not everything can be stored server-side but something like coordinates can easily be stored server-side (preferably linked to your current session in case you are logged in from more than one location so posts from your cellphone don't show up as posts from your home and vice-versa).
Greylisting is to SMTP as NAT is to IPv4
Yes, I read TFA. It wasn't very illuminating; the author essentially says that since the client side can alter the transactions, HTML5 has security problems.
That's kind of stupid; whose security are we talking about here, anyway? Clearly not the end user - and I'll feel free to use various add-ons to alter the web pages I visit to improve my security and privacy
Despite the power and awesomeness that is the growing new web environment, the browser is the client and the application runs on the server.
Rich, exciting, thrilling and awesome experiences on the client side be damned, the server, the data and the application should never trust the client. I always thought this was a fundamental reality of the web that everyone knew. But recently, with all this version number craziness we have been seeing of Firefox lately, I have come to realize that there are a lot of lessons that have to be re-learned "the hard way" along the way.
Hard Lesson #1 (for Firefox), don't screw with your users or you won't have them long.
Hard Lesson #2, it's a "browser" and a "standards compliant browser" at that. This will mean it is very replaceable or interchangeable. Don't overestimate your worth to the user. Whatever it takes to see the truth, "the browser is not the thing" ; it's how you get to the thing.
Throughout computer history, we have seen patterns emerge. The computer is too over-loaded, so move computing outward to the desktop. The desktop is too overloaded, so move computing back to the server. The desktop and the server are too overloaded and the IT departments are too burdened and expensive, so move computing "to the cloud!" (aka, someone else's servers) All these changes over time indicate a behavior of aversion -- seeking to avoid a problem. That's all well and good, but it doesn't seem to address the problem on the merits of the situation and is certainly not accepting of reality. That reality is that the data and the services are "the things." There are costs associated with those things and they must be managed. But "the things" are the things and they must be valued and handled appropriately and all the things surrounding "the things" need to be held in perspective.
I'm going to wait for HTML 6.
You didn't hear? Numbering is "out".
It will be just HTML in the future and the version numbers will be hidden from average users.
In love, war and slashdot discussions, everything is allowed.
"HTML5 isn't the solution for every problem."
And anyone who thought it was has not been programming for very long, or simply doesn't learn from history.
On the plus side, HTML5 should make some aspects of life a bit easier, and hopefully introduce only a small number of new challenges.
Cheers.
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.
Just wait until we get the ultimate XML programming language.
The Tao of math: The numbers you can count are not the real numbers.
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.
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
that looks almost like coldfusion.
<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.
>> HTML5 hard truth No. 1: Security is a nightmare The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of Web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.
Relying on the client not being able to understand the executed code is not even security by obscurity but even worse. Relying on client-side checks for consistent data (or even authorization - yes i have seen that) was stupid since the beginning of the web (and before).
Layer your spheres of access correctly, and there will be no bigger problem
> HTML5 hard truth No. 2: Local data storage is limited
Local storage is *always* limited. Relying on having near infinite local storage is something which also pisses me off for Desktop apps.
> HTML5 data storage capabilities are certainly an important addition, but you still can't move stored data to another machine, make copies, back it up, or open it with a different app. It's all buried deep where the browser hides it.
You is the user or the service provider? And *nobody* hinders you to implement also local backup mechanisms and free export of the data for the user. If you dont have the creativity or the knowledge to do so, then dont the fuck try to write a serious application. And if you back up you machine, your browser data is backed up with it.
> Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They're not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.
Wow. As if the average Desktop application would have completely open, understandable and easy to read data formats.....
>HTML5 hard truth No. 3: Local data can be manipulated
Uhm. did we talk about the server-side consistency check. And if its (according to the Truth Nr. 4) so much easier in the case of a pure desktop application to edit the data would that be not better in the sense of Truth Nr. 5?
> HTML5 hard truth No. 4: Offline apps are a nightmare to sync
Yes, always. Hasnt a single thing to do with HTML5
> HTML5 hard truth No. 5: The cloud owes you nothing It's not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, which leverages the cloud to fix all of the headaches for installing software and backing up data.
The cloud is *not* an essential part of "the vision" of HTML5. It is a promising approach to deliver services cheap, HTML5 or not.
HTML5 hard truth No. 6: Forced upgrades aren't for everyone
Forced upgrades? We never had these before....
What is this. Sony forces updates to the PS. MS forces the installation of the WGA. Whe web-mail providers i use update senselessly all the time, since 10 years.
HTML5 hard truth No. 7: Web Workers offer no prioritization
A well written program relies on message passing and not polling. As a programmer i seldom had to prioritze threads withing an application.
HTML5 hard truth No. 8: Format incompatibilities abound
Yes, thats sad. The standard is still in the flow.
HTML5 hard truth No. 9: Implementations are browser-dependent
html has been browser-dependent since a long time, and so was java (not badly). Native applications are OS-dependent.
So what. An IT professional who thought that HTML5 would be the magic wand to overcome incompatibilities between environments with testing would have been stupid.
HTML5 hard truth No. 10: Hardware idiosyncracies bring new challenges
Funny. What you want to say: make a 3d game and it wont run as well on a handheld device without acceleration? Yes, that has been pretty much my experience the last 20 years.
HTML5 hard truth No. 11: Politics as usual
Honestly? An HTML5 only problem? Well....