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.'"
On no. 1 & 3: Never trust the client (Score:5, Insightful)
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).
Nothing (Score:4, Insightful)
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
Can I have an "Ahmen!" or at least a "well duh!"? (Score:5, Insightful)
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.
Naivety (Score:5, Insightful)
"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.
Re:Holding off using it for other reasons (Score:2, Insightful)
Another sad case of a XML brainwashed believer....
XSLT, trivial? Have you ever tried doing anything useful with it?
XML/XHTML was written for the parsers. HTML5 was written for web developers. You may say the standard is "shit", the practices are "amateurish" (when benchmarked against what they teach you in the textbooks), but all that counts is what people are able to do with the stuff.
Theoretical aesthetic purity is not an ends in itself. The "separation of concerns", "removal of arbitrary tags/duplicate functionality", "future proof" stuffs actually make the XML/XHTML spec more useless, harder to work with, and decreases productivity. You may marvel at its aesthetic beauty, but for people like us who actually need to do things on a schedule, those restrictions hinder our productivity when there's no way to opt out of it.
For example, if people use bold text all the time, then why shouldn't we be able to <b>bold-text</b>? Why should we have to <span style="text-weight: bold">, or worse, write up a crazy "semantic" document and then add the XLST? Isn't that overkill?
The HTML spec people took 10 years to realize the mistake of going the XML way. It seems that you still have yet to make that realization.
Re:On no. 1 & 3: Never trust the client (Score:3, Insightful)
Seriously, how is this hard? Don't trust the client, store things like geolocation data and other such things server-side.
You say that as if it's not creepy.
Re:Holding off using it for other reasons (Score:5, Insightful)
"Another sad case of a XML brainwashed believer...."
Believer? that implies I merely believe XML is useful. No, sorry, many of us in the real world actually find XML useful. We develop large systems where XML helps no end. I'm sorry that you've never worked on a project where XML has come in useful, but some of us are competent enought o actually use the right tool for the job.
"XSLT, trivial? Have you ever tried doing anything useful with it?"
Yes thanks. We had an old black box system that we needed to integrate with a new web based system, it produced web pages that were thankfully at least XHTML1 compliant. Because we couldn't yet get rid of this system we were fortunately able to XSLT transform the output into useful data, and feed back inputs to it to transparently integrate it with the new system. If it had only adhered to HTML5's bastardised SGML syntax then it would've been a nightmare to integrate with this legacy system.
"XML/XHTML was written for the parsers. HTML5 was written for web developers. You may say the standard is "shit", the practices are "amateurish" (when benchmarked against what they teach you in the textbooks), but all that counts is what people are able to do with the stuff."
Right, and this is the problem. Too many developers haven't come from a professional background. They write code that would make old school C++ developers, and high end Java developers alike cry themselves to sleep at night. They managed to get a basic site working in PHP once, and have moved on from their, they don't understand what MVC or OOP is and don't see why they should because they never needed it so just carry on as normal. The problem is, they're also the ones who are responsible for sites that are always falling over, getting hacked, miserably hopeless in terms of scalability. Stuff isn't put into textbooks for a laugh, or to give you something to study, it's put in there base on experience, it's put in there so that you don't repeat the mistakes made by others before you - and there's the problem, too many web developers do repeat those mistakes time and time again, which is why things like SQL injection and XSS attacks are some of the most common to this day, despite solutions to them being long available and known, well, if you read the textbooks that is.
"Theoretical aesthetic purity is not an ends in itself. The "separation of concerns", "removal of arbitrary tags/duplicate functionality", "future proof" stuffs actually make the XML/XHTML spec more useless, harder to work with, and decreases productivity. You may marvel at its aesthetic beauty, but for people like us who actually need to do things on a schedule, those restrictions hinder our productivity when there's no way to opt out of it."
You are a terribly developer. Sorry, it needs to be said. You've basically admitted you're writing terrible code just to get something working. Your code is the type of code responsible for nightmarish maintainability, horrendous bugs and security exploits. Please, get the fuck out of the software development industry now. We don't need more bad software. I understand that in some places the constraints are such that speed of development and hence reduced cost is put well over and above quality but that's not the same everywhere. Please don't assume your complete lack of focus on quality is universal.
"For example, if people use bold text all the time, then why shouldn't we be able to bold-text? Why should we have to , or worse, write up a crazy "semantic" document and then add the XLST? Isn't that overkill?"
It depends. Sure it might take you an extra 5 minutes today, but that's 5 hours saved tommorrow when you have to come back and fix things. Separating off semantics means that for larger software teams you can even have people dedicated to looking after just that, so the developers can focus on developing, without getting in each other's way.
"The HTML spec people took 10 years to realize the mistake of going the XML way. It seems that you still
Re:Holding off using it for other reasons (Score:5, Insightful)
"XML/XHTML was written for the parsers. HTML5 was written for web developers"
You seem to be completely glossing over / forgetting the fact that in order for the "web developer"'s site to be farmed out, it needs to be served up by an engine, written by a software developer - one who has a metric crapton of libraries and tools all geared toward working with XML.
This is of course also completely glossing over the fact that there is basically no one in the industry anymore who is simply a "web developer". Try getting a job in a real workplace with nothing in your skillset but HTML and script, and you will be laughed out of the building. All companies want real software developers nowadays - and those developers appreciate well-formed syntax sets.
Re:Holding off using it for other reasons (Score:4, Insightful)
I think there's a fair bit of mileage in what you've said.
Let's be honest the web wasn't designed for interactive applications and I think there's a fair question as to whether if that's what we want, then shouldn't we build a tool for just that rather than mangling HTML to try and do it, and do it badly?
It'll take a brave soul to define the next generation of web standards to replace HTML, something that's geared to proper interactive applications rather than mere content display as is the case with HTML. But I don't think you're far wrong in suggesting that that's the real, true solution to the problem. It'll be difficult if not only because it'd mean getting the browser manufacturers on board, and they couldn't even get the relatively trivial task of implementing proper XML display engines in place- something which you quite righly note, the likes of Microsoft with WPF, and many other such manufacturers have done with ease in their technologies.
Whether it's WPF or something else (probably something else, because I doubt people want a Microsoft technology becoming dominant on the web!), that sort of solution is certainly optimal.
Analyze the reasons! (Score:4, Insightful)
>> 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....
Re:Holding off using it for other reasons (Score:1, Insightful)
some of us are competent enought o actually use the right tool for the job.
XML is never the right tool for the job, it's a perfect example of trying to be all things to all people. It's not really human-readable and certainly not human-writable, but at the same time it has too much parsing overhead for a useful machine format. If you wanted the right tool for the job you'd use either a lightweight, actually-human-editable format like json or yaml, or an efficient binary format.
If it had only adhered to HTML5's bastardised SGML syntax then it would've been a nightmare to integrate with this legacy system.
HTML is a nightmare to parse - but browsers are always going to have to parse it (even if we switched to something else today there's too much legacy web for them not to support it), and as such there are plenty of libraries available to handle it. And once you've parsed it, manipulating a document in a real programming language is far more efficient and effective than using XSLT. I was once a big fan of XSLT, but having worked on systems that use it, no.
this is the problem. Too many developers haven't come from a professional background
And yet somehow they've produced a far more successful platform than any "professional" effort. The web grew based on browsers and site writers implementing whatever they needed; if you look at its history, formal standardization of the web coincides with a huge stagnation in functionality.
HTML is and always has been a presentational format; it isn't and shouldn't be a semantic format. Browsers don't want or need semantic information, and couldn't trust it if it was there. Look at the img alt=... attribute; it's come to specify "mouseover text", regardless of its supposed semantic meaning, because that's the presentation browsers give it so that's how site authors have used it. So now you have some sites that use it with its original intended semantic meaning and some with another semantic meaning, and there's no way for a browser to distinguish between the two; the only meaningful semantics that html has are display semantics, because that's the only thing browsers provide and the only thing site authors test. You may have a need or desire for a semantic markup format, but the solution to that is to make one, not try and turn html into one.
The "HTML spec people" actually preferred the XML route, and genuinely still seem to to this day. The problem is the "HTML spec people" have now had the web standards agenda hijacked by a bunch of inept cowboys, who have now become the new "HTML spec people".
The original spec people spent about a decade coming up with nothing useful. In fact as far as I can see every major choice the spec people made was wrong - the stupid CSS box model, the treatment of iframes, object vs. embed... HTML4 (the only actual standard version AFAIK) has zero advantage over HTML3.2 (the name for what MS and Netscape implemented on their own). CSS is a classic case of design-by-committee; it's not expressive enough to replace programmatic generation of html, but it's still so complex that not only has the full standard never been implemented, I've heard serious doubts that it's even possible to implement.
The guys now in charge of the standards are the ones who wrote the software we all use daily to browse the web, rather than the ones who sat in endless discussions and produced nothing. I think you've got the wrong notion of who's inept.