Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hard Truths About HTML5

Soulskill posted more than 3 years ago | from the does-not-julienne-fries dept.

Programming 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.'"

Sorry! There are no comments related to the filter you selected.

HTML5 (0)

Anonymous Coward | more than 3 years ago | (#37104702)

The funny thing is that this comes from a site with separate pages for a print article version, while CSS has supported separate print .css file for a long time.

Also, the article points out how easy it is to debug and manipulate HTML5 code within the browser, or modify local storage. That's the thing. You're never supposed to trust the client. That's just stupid.

But what is point on is this
 

These stories aren't common, but they're appearing more and more often for many reasons. Are you sure that the cute Web startup promising free everything with their HTML5 app is going to be there in a few years or even a few months? You'd better be.

With Google closing down over half of its project just some time after they were launched, it would be just stupid to use web apps instead of desktop apps. That's why businesses don't want to move to Google spreadsheets or text processing, but keep using Microsoft Office.

On no. 1 & 3: Never trust the client (4, Insightful)

mikael_j (106439) | more than 3 years ago | (#37104706)

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:On no. 1 & 3: Never trust the client (3, Insightful)

Anonymous Coward | more than 3 years ago | (#37104992)

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:On no. 1 & 3: Never trust the client (1)

dokc (1562391) | more than 3 years ago | (#37105344)

His post is purely solution driven. You have a software problem - there is a solution. It has nothing to do with morality.

Re:On no. 1 & 3: Never trust the client (1)

Anonymous Coward | more than 3 years ago | (#37105018)

The 'point' they make in no. 1 is totally backwards also. The ability to see what code your computer is running is by far a lesser security problem.
Without the ability to audit or filter code before you execute it on the client side would be a true nightmare.

Re:On no. 1 & 3: Never trust the client (1)

XDirtypunkX (1290358) | more than 3 years ago | (#37105046)

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, it is just considerably harder to do.

Re:On no. 1 & 3: Never trust the client (1)

mikael_j (106439) | more than 3 years ago | (#37105078)

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 JavaScript to verify logins on the client (I have no idea who thought that was a good idea but it seemed to spread like wildfire).

Re:On no. 1 & 3: Never trust the client (1)

Dog-Cow (21281) | more than 3 years ago | (#37105546)

A problem somewhere... like maybe he's using a VPN. That's the problem here... nothing is reliable.

Re:On no. 1 & 3: Never trust the client (1)

BenoitRen (998927) | more than 3 years ago | (#37105554)

That doesn't stop the client very easily spoofing their own location coordinates

Why is this a problem in the first place?

Re:On no. 1 & 3: Never trust the client (0)

Anonymous Coward | more than 3 years ago | (#37105862)

Exactly what I thought. You should never be able to assume geolocation data from a browser is accurate. This is a good thing.

Re:On no. 1 & 3: Never trust the client (1)

ciderbrew (1860166) | more than 3 years ago | (#37105966)

It would be a DRM issue for streaming content. If you can't trust the location how do you know what to block.
OR ... HA HA.

Re:On no. 1 & 3: Never trust the client (0)

Anonymous Coward | more than 3 years ago | (#37105096)

Seriously, how is this hard?

I know, only an idiot would want to sacrifice performance and niche capabilities that will never be in the format of HTML-N for Facebook + nicer graphics.

Re:On no. 1 & 3: Never trust the client (1)

gerumato (2435578) | more than 3 years ago | (#37105236)

It's hard to pay the rent, and a flaming book about a new technology seems to be the solution to Peter's financial problems.

Re:On no. 1 & 3: Never trust the client (3, Informative)

moberry (756963) | more than 3 years ago | (#37105458)

I try to work my web-apps in the MVC style -- or at least the "VC" style. The browser is the view, the only thing it gets sent is data to display. It is fairly simple to through a debugger up and see exactly how the server API works, but it's also fairly simple to ensure your API is only servicing valid requests and all data is being validdated/escaped/etc.

Re:On no. 1 & 3: Never trust the client (1)

mcvos (645701) | more than 3 years ago | (#37105662)

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.

HAHA !! WEB APPS ARE FOR LOOZERS !! (-1)

Anonymous Coward | more than 3 years ago | (#37104730)

Are you a loozer ??

Re:HAHA !! WEB APPS ARE FOR LOOZERS !! (1)

Joce640k (829181) | more than 3 years ago | (#37104766)

I'm going to wait for HTML 6.

HTML numbering scheme (3, Informative)

dokc (1562391) | more than 3 years ago | (#37104822)

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 (4, Funny)

Canazza (1428553) | more than 3 years ago | (#37104876)

They're not dropping numbers.

Mozilla just stole them.

Re:HAHA !! WEB APPS ARE FOR LOOZERS !! (0)

Anonymous Coward | more than 3 years ago | (#37104830)

<smug>I'm already using IE6 !</smug>

Re:HAHA !! WEB APPS ARE FOR LOOZERS !! (1)

jd2112 (1535857) | more than 3 years ago | (#37105392)

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.

so what - it doesn't do innovation for you? (0, Informative)

Anonymous Coward | more than 3 years ago | (#37104770)

Sounds like its just not being utilized properly... I'm a software engineer and I make (web-based) frameworks/tools/languages do things they were never supposed to... Its called innovation...

Can you make a javascript alert box from PHP?

echo "document.write("alert('hey');\");"; //Something like that would do it.

Re:so what - it doesn't do innovation for you? (2)

master5o1 (1068594) | more than 3 years ago | (#37104920)

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.

Re:so what - it doesn't do innovation for you? (0)

Lillebo (1561251) | more than 3 years ago | (#37104946)

Its called innovation...

Can you make a javascript alert box from PHP?

Behold the wizardry. Modded troll.

"Software engineers" don't do web programming (1, Troll)

Viol8 (599362) | more than 3 years ago | (#37105056)

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 (5, Funny)

maxwell demon (590494) | more than 3 years ago | (#37105186)

Just wait until we get the ultimate XML programming language.

<statement>
  <assignment>
    <source>
      <sum>
        <term>
          <variable id="x" />
        </term>
        <term>
          <constant type="int" value="1" />
        </term>
      </sum>
    </source>
    <destination>
      <variable id="x" />
    </destination>
  </assignment>
</statement><!-- x=x+1 -->

Re:"Software engineers" don't do web programming (1)

pfafrich (647460) | more than 3 years ago | (#37105270)

I think you have just invented MathML [w3.org] .

Re:"Software engineers" don't do web programming (4, Interesting)

Eivind (15695) | more than 3 years ago | (#37105296)

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.

Re:"Software engineers" don't do web programming (1)

Miamicanes (730264) | more than 3 years ago | (#37105450)

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:"Software engineers" don't do web programming (1)

Raumkraut (518382) | more than 3 years ago | (#37105340)

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:"Software engineers" don't do web programming (0)

Anonymous Coward | more than 3 years ago | (#37105566)

So, programmers didn't 'code' Slashdot that you are using?

Re:so what - it doesn't do innovation for you? (0)

Anonymous Coward | more than 3 years ago | (#37105174)

Sounds like its just not being utilized properly... I'm a software engineer and I make (web-based) frameworks/tools/languages do things they were never supposed to... Its called innovation...

Can you make a javascript alert box from PHP?

echo "document.write("alert('hey');\");"; //Something like that would do it.

I almost lost my Honey Bunches of Oats when I read your post. You used the word engineer and then posted a alert box "hack" as an example? Sir , you are no more an engineer than you are a rocket ship pilot. That's a simple hack. Innovation? NOT. Now, go and build some more MS Frontpage sites.

Subversive Lies (1)

Grindalf (1089511) | more than 3 years ago | (#37104782)

It works fine on explorer 9, not as good as .net and flash though, and much better than those other browsers Remember to make the pages go on older browsers that's all. Use a switch statement and set a variable ...

Nothing (3, Insightful)

Whuffo (1043790) | more than 3 years ago | (#37104796)

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

Re:Nothing (0)

Anonymous Coward | more than 3 years ago | (#37104872)

>and I'll feel free to use various add-ons to alter the web pages I visit to improve my security and privacy
I guess you won't be doing it using Firefox [graham's number] then.

Can I have an "Ahmen!" or at least a "well duh!"? (5, Insightful)

erroneus (253617) | more than 3 years ago | (#37104808)

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.

Re:Can I have an "Ahmen!" or at least a "well duh! (-1)

Anonymous Coward | more than 3 years ago | (#37105842)

WTF is "ahmen"? I think you mean "amen".

Learn to spell, retard.

Naivety (4, Insightful)

localman (111171) | more than 3 years ago | (#37104836)

"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.

Quite (0)

Viol8 (599362) | more than 3 years ago | (#37105094)

"And anyone who thought it was ... simply doesn't learn from history."

Unfortunately that sums up a lot of new "coders" from sausage machine colleges/universities where the only think they learnt was java and basic OO. They know little to nothing about older technologies and languages and how they work or what their advantages might be. I'm not blaming them (well ok , a bit , you'd think they'd be curious about what went before in their chosen profession) , its generally the fault of the courses they've been on.

Re:Quite (1)

Anonymous Coward | more than 3 years ago | (#37105286)

You missed the "Get off my lawn statement".

How does that even matter? Seriously. I learnt to program in Visual Basic, ffs, in fucking Visual Basic! And I knew perfectly at that time that it wasn't meant to solve everything (later I would realize it wasn't meant to solve anything). A course is not intended to teach you every possible language, tool or solution, it's you who should investigate what is the better approach to a project, and what are the advantages and disadvantages of choosing one instead of the other. There isn't a silver bullet and never will be.

If there is something to blame is the managers who hear buzzwords and suddenly feel that unavoidable feeling of reimplementing everything from scratch.

Re:Quite (0)

Anonymous Coward | more than 3 years ago | (#37105342)

You have to remember most of these education courses are hopelessly out of date because the landscape changes so fast, think about it, you have to collate all that information on a particular subject, design the course syllabus, design and print the literature, organize some sort of tuition structure, get everybody in the same room, all that takes too long
by the time they have learned anything its all out of date

Re:Quite (1)

maxwell demon (590494) | more than 3 years ago | (#37105586)

The fundamentals never get out of date. A new language may come with a new syntax and with new libraries, but only very rarely it comes with a new programming paradigm.

Re:Quite (1)

CadentOrange (2429626) | more than 3 years ago | (#37105384)

I'm not blaming them (well ok , a bit , you'd think they'd be curious about what went before in their chosen profession) , its generally the fault of the courses they've been on.

If they're not interested in pushing the boundaries of their knowledge and abilities, they're going to get left behind by their peers who do. The only problem I have is that these are the type of developers who seem to get fast tracked into management ...

Peter Wayner's writing style... (0)

Anonymous Coward | more than 3 years ago | (#37104860)

...makes my eyes bleed.

Holding off using it for other reasons (4, Interesting)

Xest (935314) | more than 3 years ago | (#37104866)

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:Holding off using it for other reasons (2, Insightful)

sydneyfong (410107) | more than 3 years ago | (#37104990)

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:Holding off using it for other reasons (1)

mikael_j (106439) | more than 3 years ago | (#37105020)

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:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105102)

Or use <strong>, which is the semantic way and can be styled with CSS as well

Re:Holding off using it for other reasons (1)

BenoitRen (998927) | more than 3 years ago | (#37105520)

Maybe it's just me but I'd rather do <span class="bold">.

Class names should never reference style, though. True, you're still mixing content and style when using the b element, but at least there the intent is clear semantically as "something that was possibly arbitrarily made bold, often by contributors".

Re:Holding off using it for other reasons (5, Insightful)

Xest (935314) | more than 3 years ago | (#37105132)

"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 have yet to make that realization."

Completely wrong. 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".

I don't mind people arguing that sometimes speed of development trumps all and it's hard to adhere to standards - that's fine, but it really just reiterates my point- that the people running the standards show now are people who practice terrible, terrible software development. Even if you can't adhere to good practices, you should at least let the spec focus on good practice, and if you can't adhere to it fine- you have your reasons, but you're effectively saying exactly what I said before- that the spec should just lower it's standards, so that even shit software can be standard. That is, HTML5 makes terribly developed software, standard. That's not a good thing.

If you're not being given enough time to develop quality software take it up with your boss, don't push for standards to be lowered so that even your crap software can be classed as standard, else it makes standards meaningless.

Re:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105248)

Mod parent up. This is so true it makes me cry.

Re:Holding off using it for other reasons (4, Insightful)

brunes69 (86786) | more than 3 years ago | (#37105170)

"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 (1)

Chris Mattern (191822) | more than 3 years ago | (#37105378)

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.

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 convenience of the web developer, not the engine developer.

Re:Holding off using it for other reasons (1)

BenoitRen (998927) | more than 3 years ago | (#37105860)

It's perfectly possible to work with an XML engine and have it serve HTML data to the client. They're not mutually exclusive.

Re:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105370)

Amen.

Re:Holding off using it for other reasons (1)

adamrut (799143) | more than 3 years ago | (#37105406)

XSLT, trivial? Have you ever tried doing anything useful with it?

I agree, XSLT didn't turn out to be as good as what it promised, although I find XSL-FO alright for generating PDFs. These days I find JSON a lot more useful than XML.

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.

I quite like the progress of HTML5/CSS3 so far too, hopefully the browsers will keep up and include more of the specs.

Re:Holding off using it for other reasons (1)

ozbon (99708) | more than 3 years ago | (#37105500)

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:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105542)

XML/XHTML was written for the parsers. HTML5 was written for web developers.

Speaking as a web developer, I like markup to be consistent. Rather than go back to some tags needing closing and others not, the direction I'd like to take is that all tags need closing and all tags can be closed using the empty syntax - even div.

Re:Holding off using it for other reasons (1)

mcvos (645701) | more than 3 years ago | (#37105704)

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:Holding off using it for other reasons (1)

mwvdlee (775178) | more than 3 years ago | (#37104998)

XML syntax seems discouraged

Can you give an example of non-XML-compliant HTML5?

Re:Holding off using it for other reasons (1)

snoyberg (787126) | more than 3 years ago | (#37105250)

<html>
<head>
<title>Not XML</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<img src="not-xml.png">
</body>
</html>

Re:Holding off using it for other reasons (1)

mcvos (645701) | more than 3 years ago | (#37105814)

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:Holding off using it for other reasons (1)

Bogtha (906264) | more than 3 years ago | (#37105002)

XML syntax seems discouraged which means you'll run into more people using the SGML syntax

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:Holding off using it for other reasons (1)

kiddygrinder (605598) | more than 3 years ago | (#37105032)

the lack of xml compatibility is a bit of a pain but it makes almost no difference, everyone has been dealing with that for years. saying that it's like the old ie/netscape days is pants on head retarded. good luck with the self flagellation, but html5 is a massive step up even with it's flaws; oh and by the way, html 5 isn't even a standard yet, so don't bother even wondering about (x)html 6

Re:Holding off using it for other reasons (1)

Xest (935314) | more than 3 years ago | (#37105230)

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 that are prevalent in just about every language, it's trivial to take markup and automatically manipulate it in whatever way is needed. You may still be thinking so what? well, in this mobile era, where screens are changing form and size all the time, where we may well soon even see wristwatch computing become a much more interesting reality, then the ability to trivially and efficiently transform content on the fly to suit the display device, or program that's manipulating the content is kind of important.

Computers just aren't good at ambiguity, and whilst you can often work around ambiguity, it's inevitable there will be issues, cases where the developer didn't think this or that might happen. Sometimes ambiguity is important and even useful, but web content is not one of those cases. HTML5 vastly increases ambiguity, whereas XML removes it, and this is one reason why HTML5 is bad, and is a backwards step for the web. We can work around HTML5's issues, and if HTML5 grows and grows and grows, we'll have to, and we probably will. But why are we even having to when the solution already exists? - just write better markup in the first place with XML syntax.

Re:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105552)

A generation of software developers lasts about 10 years. The first six or so years are them making mistakes. The next four years are them trying desperately to correct the mistakes they made. By the time 10 years rolls around, these developers have either moved on to management, or have moved on to some other field.

Now, due to the business cycle, we don't always have a continual influx of developers throughout that decade. There'll be a large burst of new developers at the beginning when there's a bubble forming and bursting, and the rate will rapidly taper off until the next boom 10 years later. That's why we see strong generational patterns.

Let's look at the past few cycles. In 1995, the web was really starting to take off. Until about 2001 or 2002, we saw a lot of bad technology be developed. HTML, PHP and JavaScript are the classic mistakes from this era. Then around 2000 to 2002, the smarter developers started realizing how bad these approaches were, and that's why we saw far more sensible alternatives like XHTML, Java, and the total avoidance of client-side scripting. But by 2005 and 2006, most of these smart developers had moved on. A new crop of ignorant fools took over. That's why we've seen the rise of HTML5, Ruby on Rails, JavaScript. They're basically making the same mistakes as the previous generation made. Unfortunately, there are so many of them that any sensible voices in the crowd are totally drowned out.

In a year or two, we'll again be at the point where the smarter developers of this new generation are finally realizing that HTML5 is a bad idea, and a failed standard. They'll realize that JavaScript "applications" aren't maintainable. They'll realize that Ruby on Rails is slow, bloated, and useless for anything serious (this is already happening, by the way, which is why Rails isn't as hyped as it was a few years ago). It's doubtful that they'll make any serious impact before the next generation of idiots comes along.

Re:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105800)

You don't consider the total failure that is XHTML 2 a mistake?

Specs have to be written on the grounds that someone might actually use them. XHTML 2 was written for a group of ivory tower nerds wanting something that was theoretically perfect and not worried about minor details like the fact that nobody wanted it. The world moved on without them as a result.

HTML 5 is much less of a mistake then XHTML turned out to be.

Re:Holding off using it for other reasons (1)

Anonymous Coward | more than 3 years ago | (#37105066)

I agree with your points.

Coward post, but I just spent the past nine months building a WPF application. I find Wpf to be very nice, and I have to think if the HTML standard was recreated today, it would look much more like WPF. Does anyone else agree? I believe most of HTML seems old, redundant, and exist for lagecy support.

Re:Holding off using it for other reasons (3, Insightful)

Xest (935314) | more than 3 years ago | (#37105268)

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.

Re:Holding off using it for other reasons (1)

StripedCow (776465) | more than 3 years ago | (#37105252)

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:Holding off using it for other reasons (0)

Xest (935314) | more than 3 years ago | (#37105352)

"And it's time web-developers got back into control actually."

IMO this is a key part of the problem. WHATWG hijacked the web standards process, and primarily folks behind Safari and Firefox.

The problem is whilst Firefox was much better than IE at standards compliance it was still far from perfect, and Safari for Windows is probably the worst browser I've ever had the misfortunate to touch.

If these people can't even get their own field right, why are we trusting them with getting the web standards themselves right? We've seen in the last year how silly Firefox development has become with it's fucked up versioning system, completely useless features, increasing memory leaks, increased bloat. That's not the sort of folk I want developing web standards.

An argument I've seen for HTML5 is that the layman can't cope with XML syntax, now, apart from the fact that I think that's frankly bollocks, it's not hard, there's also an element of so what? How many laymen actually write markup nowadays? Everyone publishes through web applications like Twitter, Facebook, Wordpress, and so forth, so wouldn't it make more sense to make things easier for the professional web developers who build these systems, than the theoretical average joe who will never actually touch markup in the end in practice nowadays anyway?

I completely agree- web standards need to be built for the people who actually use them day in day out - the web applications developers, not for some mythical average joe, and not for the browser vendors who STILL manage to fuck up their implementation even when they're the ones outright dictating them now.

Re:Holding off using it for other reasons (2)

BenoitRen (998927) | more than 3 years ago | (#37105686)

WHATWG hijacked the web standards process, and primarily folks behind Safari and Firefox.

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 of the delusion you preach.

No, it's not to make old pages automagically standards compliant, it's to give the web developer the tools that he has been missing for years, like more elements to mark up diverse content and allow for different kinds of validating input (like dates). For example, there's no semantic meaning to be gained from <div class="article">. Introducing the article element does add semantic meaning.

Re:Holding off using it for other reasons (1)

Xest (935314) | more than 3 years ago | (#37105954)

"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."

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 than a couple of browser manufacturers going their own way and riding a way of populism and ignorance to push their spec? I'm not sure how the current situation is better where sure comments are allowed, but they're ignored by grand dicator Hixie et al. I suggest you check the W3C's member list and see how many varied the input into XHTML2 actually was. No, what WHATWG mean when they say people were left out is "We threw our teddy out the pram, because the other firms wouldn't let us have our own way". THAT is preciely what it was all about, now they have their own way, and they're proving what a shit job they can do. It seems there was good reason no one was listening to them before.

The spec was taking time because it takes time to make sure things are done properly, and to make sure raised issues are examined, and, if need be, correct. WHATWG still don't get this to this day, which is why they've declared HTML5 a living spec, ready for use, rather than just waiting for W3C to ratify it when it's been confirmed acceptable.

But even then, since when was everyone a standards expert? standards aren't designed so that everyone can insert whatever the fuck idea they want, they're designed to support interoperability above all else. HTML5 is an epic fail at this, particularly with it's backwards move away from XML, and it's "live" spec ideology. It was far far better having thousands of experts from hundreds of varied companies running the process, than a select bunch of dictators pretending to listen, but not actually caring. Further, at least the W3C had proper accountability processes, again WHATWG is more like a monarchy with grand dicator hixie at the top, and his court closing rank around him when any criticism arises of his plans.

"it's to give the web developer the tools that he has been missing for years"

Right, so why does introducing new and important features require taking a backwards step, like pushing SGML-esque markup up the long proven beneficial XML markup? That isn't about giving developers tools they need, that's about a select group who never quite got why XML etc. were important pushing their view on the rest of the world.

"For example, there's no semantic meaning to be gained from <div class="article">. Introducing the article element does add semantic meaning."

No but there is semantic meaning to be gained by adding something akin to CSS where you can either do it inline with semantic= or with a sheet declaring semantics which are applied to the relevant classes. In contrast, there's only partial semantic meaning to be gained from:

<article>
</article>
<div id="comments">
        <div class="comment">
        </div>
</div>

It's a half arsed solution, it only helps an arbitrary set of components of a page, it's not a full solution. It's 100% useless for applying semantics to many elements of modern pages because the list of sections that got their own tags is based on an arbitrary and already long outdated study of prominent tags. In this context it's easy to question whether it was ever about semantics at all, or simply about being able to write yet more sloppy markup- skip the classes, just chuck some arbitrary one word tags in, but only in some places, because the list is necessarily finite, and rapidly out of date. Again, this sort of proposed solution I mention has all the benefits of CSS too- spread separation of concerns amongst a development team better, allow external attachment of semantics to no longer maintained sites, cope with multiculturalism/internationalisation better, and so on.

Separating concerns in this way has so many advantages, it's amazing anyone deems the likes of <article> as a real attempt at introducing reasonable support for semantics. Of course, don't even get me started on how badly HTML5 fails accessibility, no ability to link subtitle sheets for the video tag for example?

But here's the thing- WHATWG was made aware of ALL of these issues, from a number of sources, on a number of occasions. If it's so open and democratic, why did it pay absolutely no attention whatsoever? Because it's simply inept? or because it's not the open democratic group that you seem to believe it is. One thing for sure- it's not because the ideas are bad or unworkable, they're far superior to what HTML5 proposes, so take your pick on one of the previous two excuses, it's certainly one of them.

Re:Holding off using it for other reasons (0)

Anonymous Coward | more than 3 years ago | (#37105944)

Man, where is -1 (Wrong) when I need it. WHATWG was a direct response to XHTML 2 being totally disconnected from reality and W3C saying "pfft, we don't care about HTML anymore, here's our new whiz-bang thing that doesn't do anything that anyone cares about but meets our standards for sufficient XMLness."

The more things change... (1)

Anonymous Coward | more than 3 years ago | (#37104880)

especially those who are looking to leverage HTML5 in hopes of unseating native apps.

Why do we keep coming full circle? WHY?

This is exactly where we were in 1998 with Java's "run everywhere, in a browser applet replacing desktop apps on the web, blah blah blah"; yeah, that went somewhere (right into a subsidiary of Oracle). The more things change, the more they stay the same, huh?

Attempting to replace native applications is ridiculous simply due to the impedance mismatch between the web environment and an application. The web exists to run in a sandbox, it was built mainly for multimedia interchange not as a software execution environment, the complaints about local storage and what not reflect that exact problem: you're in a minimalist sandbox, you have limited power and expressiveness by definition – that's kind of the point. The moment a browser allows something that fully behaves like a native application it will be a reinvention of Java and will have all the same problems that had. In some ways, it may even be worse what with the 'broken by design' WebGL specification that allows random websites to try and buffer overrun your system at kernel level. [For those playing along at home, Firefox: "about:config", set "webgl.disabled" to true]

There is no HTML5 (0)

Anonymous Coward | more than 3 years ago | (#37104906)

No standard called HTML5 exists, and that should be the end of it.

So the same old same old (0)

Anonymous Coward | more than 3 years ago | (#37104912)

things that make web development a total and utter nightmare are still evident. Fat client apps aren't going anywhere I think.

No shit (0)

Anonymous Coward | more than 3 years ago | (#37104970)

Peter Wayner just learned about HTTP, HTML and Javascript, then started crying. Sure there's enough to cry about but please don't write about it if you don't have anything to add. Also, merging with Git is *very* fast as it was optimised for the job from the ground up.

Also, the article has almost nothing to do with HTML5.

What a load of crap. (0)

Anonymous Coward | more than 3 years ago | (#37105014)

Seriously, this made it here?

Every complaint on there is absolutely crybaby-tier "i dun understan' this" levels of whining.

WE KNOW HTML5 ISN'T GOING TO BE THE END OF NATIVE APPS.
We know it isn't going to solve problems that EVERY ASPECT of it has suffered in native apps since they have existed.
Seriously, sync issues are still a problem in native apps now, they can be fixed pretty easily.
Canvas, not knowing power behind the processor to ensure decent speeds. Oh, funny how you just solved the problem in the very same complaint, the same way it has been done since forever since depending on a number(s) is stupid and always has been.
He took 2 weeks to get audio working? You kidding me? No, really, TWO whole weeks? I probably don't even need to go on, but I will.
Security is a nightmare? HMM, JUST LIKE IT IS ALREADY WITH NATIVE APPS? Next.
Local storage limited? 1) The API for all of this is still being made. Hell, the File interface is barely functional. 2) All of the content of that paragraph has nothing to do with "limited storage"
Local data can be manipulated? See Security is a nightmare.
Cloud owes you nothing. Why do people keep linking HTML5 and the cloud? Quit it already. "Cloud storage" has been around since before HTML5 even existed as an idea. Since before HTML4 even existed as an idea in fact.
Point 6 is a personal thing. Ignored because said person probably deserves the awkwardness.
Webworkers, likewise, are still being created.
The whole of point 9, again, non-issue. HTML5 isn't even nearly complete.

Complete and utter nonsense and whining.
Seriously, it is like "are we done yet are we done yet are we done yet" coming from him.
HTML5 IS NOT COMPLETED YET.
If you want to get involved in its evolution, go to the development pages and voice your opinion.
Oh, wait, never mind. Just another negativity-piece to get hits.

MS is the obstacle. (1)

Anonymous Coward | more than 3 years ago | (#37105024)

If HTML can be used to replace local applications, MS has the most to lose because people would not be locked to Windows anymore. So MS has been working with HTML5 community mainly to slow down things.

opensource is a problem? (-1)

Anonymous Coward | more than 3 years ago | (#37105040)

the first problem is, with opensource (which does not mean free software!) everyone can tweak the code. oh, who would have thought of that!

Native Apps gone? Not in the next 10yrs at least (3, Interesting)

geekpowa (916089) | more than 3 years ago | (#37105194)

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.

Re:Native Apps gone? Not in the next 10yrs at leas (1)

CadentOrange (2429626) | more than 3 years ago | (#37105410)

[snip] Imagine trying to write something like Gimp, or Open Office [snip]

For the majority of users out there, Picnik and Google Docs work just fine. I personally prefer Google Docs over MS Office or Open Office, and if it weren't for the fact that I am a serious amateur photographer I'd be perfectly happy with Picnik. As it is, I need Lightroom. I think the trend will be that native apps will be relegated to niche applications that cater to power users. The average user will be easily served by web apps.

The hardest truth about HTML5 is: (0)

Anonymous Coward | more than 3 years ago | (#37105196)

The spec is still a draft [w3.org] .
So if you start building websites with an unfinished spec, dont be surprised when/if it may break between browsers.

I may be just old, but I remember how I behaved when the draft of HTML4 was released.
Nothing much has changed with newbie-hyper-keen information leeches trying to bleed themselves on the edge of browser tech.

now get off my lawn.

HTML is NOT for applications (1)

TheDarkMaster (1292526) | more than 3 years ago | (#37105222)

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.

Re:HTML is NOT for applications (1)

H0p313ss (811249) | more than 3 years ago | (#37105442)

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:HTML is NOT for applications (1)

TheDarkMaster (1292526) | more than 3 years ago | (#37105962)

I know. I've been saying this for years but only one or two listens. I admit that even works to some types of applications such as HTML form-based applications (inventory control, requisitions, things like that), but are much more difficult, slow, ugly (you need many hacks to "emulate" native interface behaviour) and prone to problems than an equivalent running natively. And to do something like an instant messenger so it's almost impossible to run correctly or efficiently.

Video (1)

jones_supa (887896) | more than 3 years ago | (#37105262)

Remember when a year or two ago HTML5 video was proposed to replace Flash Player? Back then there was a lot of talk about it, but I guess it has never happened. Just pondering.

Re:Video (0)

Anonymous Coward | more than 3 years ago | (#37105734)

www.youtube.com/html5/
www.vimeo.com

Try both without Flash. They both work. It happened, you just didn't notice.

The concept of browser is wrong. (4, Interesting)

master_p (608214) | more than 3 years ago | (#37105264)

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 least they could understand the data's structure, making semantic analysis easier.

- a unified and global security model. I am not an expert on security, so I will not make a proposal for this, but it is clear to me that unless the security model is unified, there are going to be security holes.

The security model will sit on top of the host's security model, and it should allow the user to execute downloaded code in a different more secured security context.

The current technology does not have the concept of a security model. Each browser has its own mechanisms to implement security. A page that is secure in one browser might be a back door in another browser.

- a local persistent database, preferably a no-sql variant. This database could be used by the applications as the preferred method of storage, and it could be also exposed, via the mechanisms described above, to the network.

The current technology provides a very limited way for clients to store data, in the form of cookies, which have quite a lot of restrictions.

Now, this is not something completely necessary for the problem at hand, but it will make data management much easier both at the local and the network level (both LAN and WAN).

Developers will no longer have to think where to save the data, and in what format. The database will take care of that, freeing the developers from this boring task.

An additional advantage of this would be that the data would be decoupled from the application, and therefore external tools that manipulate the data could be easily written.

A further advantage would be that the database can exist in the other point of the network, thus allowing the persistence of data in remote servers, should one wish to do so.

The Server Controls the App (1)

tvlinux (867035) | more than 3 years ago | (#37105288)

The Server controls the web app.
The only data in the client is temporary local data and display data. All data is stored on the server.
When a user logins in a session is created. At this point resynchronization happens. All the data stored in the client is downloaded to the server. the server then deals with what needs to be updated.
Yes, expect people to try to crash the server and corrupt data. Design the server framework to deal with it. Then the server application does data validation and checking. then finally use the data to update the server storage.
The standard frameworks now do not deal with "Data Only" processing. By using a server framework the uses small callbacks for RPC with session security tokens creates a secure enviroment.
The biggest problem are RPC calls that are automated to harvest data. This can be mitigated by throttling in the server framework.

Are you kidding me? (1)

devent (1627873) | more than 3 years ago | (#37105300)

"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 post in this poor "Web 2.0" forum of slashdot.

Please start to develop sites with some kind of content, that is for what the Web is designed for. Maybe then I will visit your site. But don't confuse a web site with a native application. Even in 2011 we are nowhere that I can be online 24/7 with a good connection from everywhere. I take my laptop and my local installed apps with my local available data anytime.

Analyze the reasons! (3, Insightful)

drolli (522659) | more than 3 years ago | (#37105332)

>> 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:Analyze the reasons! (0)

Anonymous Coward | more than 3 years ago | (#37105464)

mod up

Re:Analyze the reasons! (1)

drobety (2429764) | more than 3 years ago | (#37105576)

Thanks for deconstructing the silliness, it reads well, as opposed to the original article, which I had stopped reading at "HTML5 isn't the solution for every problem": I was unaware that HTML5 was held as solving "every problem." It struck me as a strawman, and right at the start of the article, so I figured the rest wasn't worth reading.

Re:Analyze the reasons! (0)

Anonymous Coward | more than 3 years ago | (#37105652)

Thank you drolli - that's pretty much everything i wanted to say as well. Most of the article was BS.

Nice new things (1)

Anonymous Coward | more than 3 years ago | (#37105424)

I have to be honest, all this talk about XML vs HTML5 and good programmers vs bad programmers is completely uninteresting for me. What I see when I look at HTML5 (both in terms of spec and hype) is css-gradients, sockets and a canvas.

Everything else is just talk that can be summed up in the following: Coding web-applications IS NOT like coding desktop-applications.

Solution ... Explorer (1)

fartrader (323244) | more than 3 years ago | (#37105434)

It'll all be fine when MS releases their explorer-specific extensions for data storage and security.

Seriously? (0)

Anonymous Coward | more than 3 years ago | (#37105698)

Scripting dangers and the dangers of trusting the client (or data that comes in from the web in general) is nothing new with HTML5... It have always existed, there are solutions, it all depends on the value of the data and the value of owning these data, what is appropriate.

Localstorage is limited... Sure, it have always been and will always be! You give the client some data to hold. These data should be convenient for the user... Stuff like config, shortcuts etc. If it is deleted nothing is really lost, just like the config and bookmark files for native applications.

Sync'ing issues... How is this connected to html5? It is one of the main problems of all web connected apps with offline functionality. How, when and what to synchronize. Ofcause it would be nice if someone came up with a nice generic and foolproof way of doing this, but I am not holding my breath.

Format, implementation differences etc. These are problems, they are not new to HTML5, they are not even new to web applications...

The fact stands that web applications are getting better, with HTML5 they are easier than ever to implement and better for the end user to use. It is another step on the way away from native apps.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?