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).
Re: (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: (Score:2)
Re: (Score:2)
Re: (Score:2)
If you don't trust the client a desktop application with hardware dongle and insane obfuscation and encryption wouldn't be enough for you.
If the client invest enough energy all your protection will be for nothing.
Re: (Score:3)
There was no solution posted though. If you don't trust the client it doesn't matter if you store the data client side or server side.
That's a remarkably naive thing to say.
In any data-driven app, you never, ever trust the client. You do, however, trust the rules you've put into place to ensure data integrity and the logic you use to enforce them. (Well, 'trust' in the sense that you've tested the hell out of your software.) That way, even if you do have a malicious client, they can't do more harm than you're willing to allow.
Re: (Score:2)
That doesn't stop the client very easily spoofing their own location coordinates, before it is ever stored on the server, which is the problem the article is highlighting. The geo-locations API in HTML5 is called by clientside code, it then exists in an intermediate form before being passed to the server to store. With easily available debugging tools, you can stop the code and change that intermediate data before it gets sent off to the server. Of course, most of this is possible with native applications,
Re: (Score:2)
True, I'm just saying that if geolocation is truly important to you then maybe you should at least attempt to verify it server-side (by looking up the IP address of the user, if it shows the user in Germany while the client is reporting that it's in Egypt then maybe there's a problem somewhere).
My point was that as long as you don't blindly trust the client you won't have these problems. Of course, it used to be worse, I remember the good old days of the late 90s when it wasn't uncommon for websites to use
Re: (Score:2)
That breaks a very common case where you have geolocation data - mobile data. Specifically, data roaming. Data roaming works because the roaming carrier forwards packets your phone sense out to your carrier, who then
Re: (Score:2)
OR
Re:On no. 1 & 3: Never trust the client (Score:4, Informative)
Work offline (Score:2)
The browser is the view, the only thing it gets sent is data to display.
Then how well does your application work offline? With HTML5 localStorage, limited though it may be, users are going to expect to be able to use your web application even with zero bars. Not everybody can afford $60 per month for the privilege to connect to the Internet during the daily commute on public transit or while in a shopping mall that provides Wi-Fi access only to employees and not to shoppers.
Re: (Score:3)
Then theres a good chance that an HTML app isn't the right way to go.
Stop trying to pretend HTML and JS are a proper way to make an offline app.
They AREN'T.
Just because you CAN do it, doesn't mean you fucking SHOULD do it.
HTML5 local storage should be used where it can for speed improvements and saving bandwidth, not to shoehorn HTML into something it shouldn't be. I'm sorry all you know how to do is throw around javascript and html, but that doesn't make you a developer and that doesn't mean you should tr
Re: (Score:2)
Re: (Score:2)
There are other ways [nokia.com] than rewriting the same thing several times. You don't even have to use C [pyside.org] or C++ [common-lisp.net]. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly [washington.edu] rejected all innovation [lambda-the-ultimate.org] in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the e
No Qt for iOS, Android, and Windows Phone 7 (Score:2)
Re: (Score:3)
I think he was saying that an "offline web app" is basically an oxymoron.
If you want to use HTML to make an application that's designed to work offline, fine. It's the wrong tool for the job, but these days you can make it work. But if you're building a standalone app, that means you're going to have to make a lot of assumptions about the validity of client-supplied data if you're syncing with a remote server when online connectivity is available. Or go all-out, and do stuff ONLY client-side; and the only t
Re: (Score:2)
The other points aren't all that great either. Most of them are either irrelevant or apply equally to native apps as they do to web apps. If anything, this article seems to point towards relying more on the server and less on the client.
Re: (Score:2)
Don't trust the client, store things like geolocation data and other such things server-side.
Uhm, where do you think you got those coordinates from in the first place?
TFA isn't talking about sending geoip data back to browsers to store it in a cookie, it's about getting GPS data from visitors, who will want to lie about it, e.g. to get free beers for logging in at a specific spot several days in a row.
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.
Perhaps a little better context for the features (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Personally in this instance I blame Steve Jobs. He made all sorts of wild claims about HTML 5 in order to justify the fact that he won't let iOS run anything which remotely appears to threaten the app store as the only source of applications(including certain elements of HTML 4 forget 5). People started to believe that there was a lot more to HTML 5 than there really is. Let me let you in on a little secret folks, very little from HTML 5 or even CSS 3 will make any actual difference to how web applications
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.
Re: (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 f
Re: (Score:2)
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?
Maybe it's just me but I'd rather do <span class="bold">. Using <b>, <center> and so on may work fine but overall using CSS to style your page is the way to go anyway.
Basically, you'll still end up with css for b, center and all those other elements because you don't want the default look of them.
Re: (Score:2)
Yes, and you end up with less HTML being sent to the client as well.
They are functionally the same, only your way is more bloated and uglier since you're still going to have the exact same CSS behind it, your way is rather stupid.
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: (Score:3)
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 problem with your argument is that there really are many instances where that 5 hours tomorrow never come. Adopting "XHTML6" in your interpretation would mean that nobody could save those 5 minutes, even if I'm just writing a hello world page.
By adopting universal standards that are so strict and unforgiving to "sloppy" code, you're raising the overhead of development without necessarily gaining back the benefits. In fact, nobody's stopping you from using your own XHTML6 -- if the XML tools are really s
Re: (Score:2)
HTML4 (the only actual standard version AFAIK) has zero advantage over HTML3.2 (the name for what MS and Netscape implemented on their own).
Huh?
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: (Score:2)
The web engine gets high re-use; people don't write their own, they use one that's already available. Web developer's sites are written custom, and are written constantly. Therefore the standard should be built for the conven
Re: (Score:2)
XSLT, trivial? Have you ever tried doing anything useful with it?
XSLT can be useful? Surely that's a Slashdot Story all in itself?
Re: (Score:2)
XSLT, trivial? Have you ever tried doing anything useful with it?
I have. As long as you use it for its intended purpose, and don't try to calculate a square root with it (as a co-worker once did as an exercise), it's pretty easy. Trivial even, if you do it right.
Re: (Score:2)
XSLT, trivial? Have you ever tried doing anything useful with it?
For simple cases, you can always use CSS to style your XML, which can work rather better than using CSS to make tweaks to an unknown set of default styles that may vary from browser to browser. However, in cases where you need to transform the order/nesting of elements in the source document to display it, CSS is stuffed anyway - most non-trivial CSS-based layouts require the HTML to be formatted just so with all the elements in the right order and correctly nested.
With the increasing use of Content Manag
Re:Holding off using it for other reasons (Score:5, Informative)
I'm a web developer who was also a member of the W3C's HTML Working Group [w3.org] (the group where the HTML5 spec was hammered out) during the development of HTML5, and I can tell you that if you believe that HTML5 was written for web developers, you are wrong. HTML5 was written by and for browser vendors -- Google, Apple, Mozilla, Opera, and (somewhat) Microsoft. The opinions of other Web stakeholders were of minimal concern. Concerns about the spec raised in the WG by anyone who wasn't a browser implementer were routinely shouted down with threats to withdraw from the W3C process completely by those who were. Some who advanced concerns, like accessibility professionals, were actually derided in quite personal terms by representatives of the browser vendors, both in official WG communications and in their own private back channels (like IRC), which invariably leaked. (Here's a good writeup [cnet.com] of some of the friction that existed in the WG between browser vendors and everybody else.)
There are a lot of things in HTML5 that I'm looking forward to being able to use, but if you're a web developer you shouldn't kid yourself into thinking that HTML5 was written for you. It wasn't. Almost every decision made in the development of HTML5 was made to make Google's life easier, not yours.
Re: (Score:2)
They do have a "web developer" edition with only the stuff important to web developers.
Re: (Score:2)
It sounds to me you've just run into the dipshits that write articles about XML and basically make it as difficult as humanly possible so they sound smart. If your a C++ programmer try this. Write a DTD (make up your own XML). Then use the dtd to xsd script from here [w3.org] to create an xsd. Then use this [codesynthesis.com] to create C++ templates from the xsd.
If your working on a really big complex project that needs to have the ability to manipulate the output using C++, or even javascript in a browser, you will see how much o
Re: (Score:2)
I see it differently. Your example shows how complex XML can be.
Forcing it down the throats of everyone (as my original parent seems to advocate) seems a bit drastic. Particularly as a lot of people writing (X)HTML don't work on "big complex projects".
Re: (Score:2)
No one forced you to do that, you could always serve HTML4. Just because some nutters online thought it would nice to go ultra-semantic didn't mean you had to join in the fun.
Hah. Everyone seems to think I'm against XML.
I'm not against XML. I'm against the GGP's attitude of "forcing everybody to abandon HTML and use XHTML/XML".
If your stance is that I shouldn't have fed the troll, then sorry, I was bored.
Re: (Score:2)
XML syntax seems discouraged
Can you give an example of non-XML-compliant HTML5?
Re: (Score:2)
<html>
<head>
<title>Not XML</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<img src="not-xml.png">
</body>
</html>
Re: (Score:2)
Does at at least accept the XML-valid structure too? Or is HTML5 just intended to give web developers more tedious work?
Almost every single tool in the world spits out valid XML nowadays. Browsers expecting non-XML is going to be really frustrating.
Re: (Score:2)
Yes, it does. In fact, you can develop polyglot documents that can be interpreted as both HTML5 and XHTML5.
Re: (Score:2)
It's not even SGML syntax any more, it's pseudo-SGML that is reverse-engineered from browser implementations. Some SGML features have been dropped, some alterations have been made to compensate for common syntax errors, and error handling has been defined.
Re: (Score:2)
Re: (Score:2)
There isn't a lack of XML compatibility, HTML5 still has it's XHTML5 mode, which still fully supports XML markup. The problem is that the HTML route not only exists, but seems encouraged, which means that rather than a push towards the much better XML syntax that we've had over the last 10 years, we're now in danger of seeing a backwards trend to the much worse syntax such that we run the risk of being back where we were 10 years ago.
You may think it's no big deal but it really is. Thanks to XML's tools tha
Re: (Score:2)
If the spec is a jungle for web-developers it must be hell for browser-vendors. Honestly, I don't have much faith in this whole process: the spec is so difficult that no vendor will ever get it right anymore.
I'm just waiting for the day when google's NaCl is more mature and we can just send native instructions to an accelerated virtual-machine-like browser. I'm feeling it's about time for that old "keep it simple" mantra. And it's time web-developers got back into control actually.
Re: (Score:2)
You're guilty of revisionism there. The truth is that the XHTML 2.0 spec writers hijacked the web standards process, locking out everyone from commenting and contributing to the process. The spec was becoming a nightmare with things like making every element a possible anchor.
That is the whole reason the WHATWG was formed. To open up the web standards process again and make a spec that reflects today's reality instead
Re: (Score:2)
What utter tosh. The HTML specification process was managed by the W3C whose members comprise just about every single industry sector under the sun and number in the hundreds. Are you seriously saying this is a less balanced process
Re: (Score:2)
Agreed that XHTML2 was stupid, but if I was there in 2004 I would have suggested a new version of XHTML that is backward compatible with XHTML1 and HTML4 using Appendix C (which XHTML2 wasn't).
Re: (Score:2)
It's only syntax, it shouldn't be a big deal. There's plenty of XML-based tools that are useful, and HTML5 goes to some lengths to define the text/html (i.e. non-XML) syntax so you can still use those tools and just translate the syntax at the edges.
The text/html and XML syntaxes are based on exactly the same underlying c
Re: (Score:2)
A large part of the reason HTML 5 was written at all was to standardize large parts of the behaviour in web browsers that the web relies upon --- until a few years ago, huge parts of the budgets for browsers were spent on reverse-engineering other browsers (latterly IE6, before than NN4, etc.), which resulted in a hugely anti-competitive environment. When work on HTML5 started, it was incredibly hard to write a browser that worked with the vast amount of already deployed content, and what specs there were w
Re: (Score:2)
Features browsers
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.
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.
HTML is NOT for applications (Score:2)
Re: (Score:2)
The hard truth is that for more than fill with patches,for more you put ugly hacks, HTML is not meant to do the work of native applications.
The problem is that you're about a decade too late with that argument. We've spent so much time and effort smashing this square peg into the round hole of HTML that the expectations are now incredibly high.
You can build real apps with HTML, just like you can build bridges with Popsicle sticks, all you need is buckets of glue.
Re: (Score:2)
Re: (Score:2)
Using WebSockets, you can implement pretty much as efficient an instant messenger as is possible in this firewalled age.
It's true that in the past, making a web page look like a native app has involved ugly hacks. HTML5 and related technologies remove the obstacles that make those hacks necessary.
Re: (Score:2)
You might be looking at this too narrowly. HTML is just one client platform among many. You use it when it makes sense; in particular, when you don't want the bother of installing a native app in the first place. Like all other client platforms, HTML has limitations, and only fools with lots of time and money to throw away fail to respect them. In its sweet spot, HTML offers some truly unparalleled features that no other stack can touch (such as hypertext linking, for example.)
Re: (Score:2)
Video (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Some very good analysis and thinking. I second the post about Google's Native-Client technology. The API is here [google.com].
Re: (Score:2)
This article about HTML5 proves that no matter what functionality is hardcoded into the specifications, developers might need more or different functionality.
That's because HTML is at too high a level of abstraction to ever sufficiently cover everything an application may need to do, or lend itself to any manageable definition of compliance. The standard needs to be on a lower level and defined by a relatively static object model with versioning defined by a set of unit tests.
.NET's IL could have served this purpose if MS hadn't screwed up Silverlight so bad.
Re: (Score:2)
You missed one major point, specifically why the browser as a universal replacement for local apps will fail, and why more generally the idea of "everything in the cloud" will fail, despite it being quite a major fad among the management types currently.
Interactivity and control.
Until technology takes a giant leap and remote or network data access becomes exactly as fast as local bus data access, locally stored data will always be faster to access than remote data, so any program that requires access t
Re: (Score:2)
The whole concept of browser is wrong. Browsers are a good solution for serving static documents
A Slashdot page is not a static document (anymore), and a browser is a good tool to serve it.
Are you kidding me? (Score:2)
"formidable competitors for native apps" Are you kidding me?
How is that even with a DSL line I have to wait at least 500ms for a reaction of the so called "app" to be a "formidable competitors" for my native application? I'm sorry to burst your bubble, but even if you get JavaScript 500% more faster then it's now, it's nowhere a native application, with local stored data is.
Even slashdot.org is a very poor replacement for my email client. I take my email-lists with my local email-client anytime before I pos
Re: (Score:2)
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....
It's just the UI (Score:2)
Having written a (still running) patient flow management system in html3 + hidden frame + javascript - sadly no ajax it is my belief that with proper care a web interface can be used in place of certain local apps. For processes that do not involve complex graphical/video wizardry (i.e. most business apps??) HTML[5] seems adequate enough. This includes many day to day internal business applications where the benefits of management, maintenance & security outweigh most of the drawbacks: bandwidth, hw com
These are NOT the hard truth. (Score:2)
There are not the real problem with implementing applications with HTML5+Javascript (Except maybe 4).
Most of the things this dude list are normal challenges of any program in any platform. So some photos uploaded with a plugin got deleted by facebook? thats the problem of any website hosting content, can be deleted by the owner of the website, how it was uploaded is not important (could as well be uploaded by a nice interface? thats better).
The REAL problem of HTML5+Javascript is Javascript. Writting sm
General Truths to all framework upgrades (Score:2)
1. There will be legacy users
2. We are upgrading to introduce new features, not a version #
3. There will be yet uncovered security bugs, this is acceptable because other systems such as the f'in router will compensate
4. Unless it is the cloud itself, the upgrade has absolutely nothing to do with the cloud, it's code, not applications (ex. the application that makes the cloud possible).
5.You must have the upgraded framework to use the upgraded apps/pages/code
6.Not every feature may work as expected, thus hot
We've been duped! (Score:3)
The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem.
I want a solution for EVERY PROBLEM!
CSS/Javascript sucks even for routine pages (Score:3)
Remember how CSS was supposed to make web pages more compact, and simplify layout by avoiding old-style table based layout? Look at how that worked out.
Here's a single article from the Wall Street Journal. [wsj.com] It's 3299 lines of HTML. That doesn't include anything pulled in from style sheets.
As an exercise, I went through and took out all the junk. The actual story, plus all the formatting needed to display the full page in in its original fonts, is 77 lines. So what's the rest? Some of it is links to other stories, but that's under 100 lines. Much of the code is ad-related, even though there are only a few ads. There's a lot of "social related" stuff, which, although it takes up little screen real estate, seems to require far too much on-page code. The "login" mechanism turns out to have all the code for not only "login", but registration of a new account, as part of the page itself. That's on every page served by the Wall Street Journal. There's a vast amount of hidden content, including a "video carousel". There's personalization stuff that would turn on if the user was logged in.
When the people who code crap like that start using HTML 5 with both local storage and connections to the "cloud", it can only get worse.
Re: (Score:2)
I'm going to wait for HTML 6.
HTML numbering scheme (Score:4, Informative)
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.
Re:HTML numbering scheme (Score:5, Funny)
They're not dropping numbers.
Mozilla just stole them.
Re: (Score:2)
I'm going to wait for HTML 6.
Perhaps by then the Internet will be running IPV6.
:-) I couldn't keep a straight face from the previous comment.
Re: (Score:3)
Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' on line 1
Perhaps it was Slashdot that removed your escape slash from the second double-quote mark.
"Software engineers" don't do web programming (Score:2, Troll)
They do real programming - writing device drivers, tuning graphical libraries , writing massively parallel simulation code. They DON'T piss about with HTML and javascript except in their free time for a hobby.
Yeah , mod me down all you moderating HTML "coders", I don't care, I have karma to burn.
Re:"Software engineers" don't do web programming (Score:5, Funny)
Just wait until we get the ultimate XML programming language.
Re: (Score:2)
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.
Re: (Score:2)
If you use <ecode> element, you won't need to manually escape each and every < and >
Re: (Score:2)
The day some nutcase PHB rams a horrible language like that down my throat is the day I officially begin development of a C++ to X-- compiler. ;-)
Re: (Score:2)
The sad part about this joke is that W3C is really forcing stuff like this down our throats. Instead, they should be focusing on providing us with the bare-metal methods to get things done. For example, were they to provide a standard for an accelerated virtual machine (without garbage collection), like NaCl, then a wealth of open-source projects could actually get things moving on the web. Imagine all the nice replacements for javascript and HTML that could come from that. That would be much more efficient
Re: (Score:2)
like NaCl, then a wealth of open-source projects could actually get things moving on the web. Imagine all the nice replacements for javascript and HTML that could come from that.
Browser makers can't keep javascript from getting out of its sandbox and doing things it shouldn't ... are you really so stupid as to think that NaCl will be better? You want to run native code 'in a sandbox' that couldn't keep non-native code from exploiting the system?
You have WAY more faith in Google's engineers than ANYONE ANYWHERE should. NaCl is a horrible idea to anyone with half a clue.
Re: (Score:2)
are you really so stupid as to think that NaCl will be better?
You should read up on their approach to security. They have multiple rings of defense. Very interesting actually.
Native code is much simpler than any scripting language can ever be, and therefore it is actually much simpler to keep things safe in a provable way.
Besides, did you ever hear about software running inside VirtualBox or VMWare infecting the host system?
Re: (Score:2)
Yay! An XML programming language. That way, my source code will now grow by about a factor of 10, become almost impossible to read or debug, and ??? profit!
Re: (Score:2)
Just because most people who mess around with web technologies are numpties, doesn't mean all of them are. Engineers of any school solve problems, and sometimes that problem space involves web technologies.
Re: (Score:2)
Re: (Score:3)
It isn't the only or even the major reason they don't want to move.
Really the biggest reason is sheer inertia. Knowing MS Office in HR is synonymous for knowing how to use word processing and spreadsheets. The thought that there might be an alternative never even occurs to those who would be responsible to make the decision to switch in most businesses.