Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why HTML is a strategic dead end for business transactions and e-commerce (1999)

jimgray.azurewebsites.net

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#31

Post by sph »

wruza wrote: post #16
sph wrote: post #9

Earlier quoted context omitted.

There is a lot of glue code written because we are only transporting data through HTTP, that is the problem. A concept that has been buzzing around my head a lot lately is, what if we could model objects/actors? So that I do not only go to google.com to display some HTML, but we have a standardised RPC language I can tell it to "search this query" and it returns a structured object? The same RPC I can use to talk to…

Are you trusted? The reason g-search and others don’t have an API is not a technical one. They won’t let you neither JSON nor HTML without captcha module injected into your browser because this is the way they earn money.

So? That can still be modelled in a RPC manner.

Instead of sending a "query " command, I have to do:

    -> get-captcha
     solve-captcha  
     query
Very simplified. If HTTP is the transport, the current Authentication header is very good at encapsulating these details without having to repeat them every command.

Point is, HTTP is still too low level and we're paying people $150k a year to write glue code and reimplement API clients until they quit and do the same thing at another company.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#32

Post by jayd16 »

m_mueller wrote: post #6

I can agree with this statement: "HTML provides a pretty face, but a lousy system-to-system transaction environment." Imagine if we had something like JSON, but with a more standardized schema to e.g. describe something simple like a table of data. There is so much glue code being written that does nothing else than reformatting data to something an organization can actually use. Think what it would mean if every tab…

What would you want that's significantly better than an n-dimensional json array? A sparse table format?

You'll still need to handle the core cell-type parsing. You'll still need to deal with what level of normalization the table used ie are cells primitives or objects or different objects with conflicting structures.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#34

Post by m_mueller »

jayd16 wrote: post #32
m_mueller wrote: post #6

I can agree with this statement: "HTML provides a pretty face, but a lousy system-to-system transaction environment." Imagine if we had something like JSON, but with a more standardized schema to e.g. describe something simple like a table of data. There is so much glue code being written that does nothing else than reformatting data to something an organization can actually use. Think what it would mean if every tab…

What would you want that's significantly better than an n-dimensional json array? A sparse table format? You'll still need to handle the core cell-type parsing. You'll still need to deal with what level of normalization the table used ie are cells primitives or objects or different objects with conflicting structures.

an n-dimensional json array still doesn't come with strong type information (other than str/null/decimal/int) for the fields and it doesn't give you a guaranteed shape either. also, there is no standard how to declare the field header labels. also, it's not binary, thus very inefficient for numerical data. there are various data formats that help in those regards, but none of it is standardized, hence all our fingers being sticky from the glue.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#35

Post by paganel »

gauddasa wrote: post #27

This article would have turned true in its prediction about the fate of HTML, and the idolized XML with JS would have met the same doom, except for one piece of technology that saved them all: AJAX.

> except for one piece of technology that saved them all: AJAX.

We have to thank the MS Office guys for that. Also interesting how RPCs have become cool again, even though under different names, one would have thought that the whole REST thing would have had the better of them.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#36

Post by forgotmypw17 »

happosai wrote: post #25
sph wrote: post #10

Earlier quoted context omitted.

My prediction: HTML will die way before HTTP. We will replace that language eventually, HTTP is here to stay.

HTTP is kinda dead already, with browsers insisting on HTTPS.

HTTP is still the best anywhere I want simplicity and resilience.

HTTPS has way too many failure modes for me to use it anywhere where accessibility and dependability are the priority.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#37

Post by zulu-inuoe »

WesSouza wrote: post #20

One would never use HTML to transfer data between two systems*, this author really missed the Forest for the trees. *unless of course one system is scraping the other and has no control of what it outputs.

You have to put it in context, though. This was back in 1999. Plenty of people even today push for semantic HTML. HTML is said to represent a document, and documents have structure. So I'm sure it wasn't all that uncommon to take it to mean that this structure was machine readable.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#38

Post by hodgesrm »

terom wrote: post #13

Disregarding the emphasis on XML -> replaced with JSON, isn't this actually mostly spot-on re the popularity of Single-Page Apps (SPA)? There is very little if any HTML in the form of the text-based markup involved in a modern SPA - the actual display logic is all DOM manipulation in JavaScript, operating on separate APIs providing just the raw data in JSON form. > Truly powerful applications can be built using combi…

> The main thrust in this article is that scraping HTML display markup is a terrible form of data interchange between systems.

Agree. Many of the comments seem to come from reading "Why HTML Is a Strategic Dead End" leaving off "for Business Transactions and E-Commerce." Screen scraping 3270 protocol blocks was a thing for integrating IBM applications (and not a good thing IMO).

I don't think Wayne was really focused on behavior outside of using HTML for integration purposes. This is partly from reading the article. It's also from knowing Wayne Duquaine, the author. We met in the mid-1990s at Sybase, where he made all the IBM system integrations work. Wayne viewed most problems through a mainframe lens. His note seems pretty typical of his point of view.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#39

Post by foobarian »

coldcode wrote: post #26
cesaref wrote: post #22

All this talk of XML has given me some bad XSLT flashbacks, not to mention XSL:FO.

Having done some XSLT coding I agree; it's a language that was both unreadable and unwritable.

I liked to call it steganographic programming. It was near impossible to spot the business logic among all the markup and content.

Re: Why HTML is a strategic dead end for business transactions and e-commerce (1999)

#40

Post by Sacho »

lucideer wrote: post #24
terom wrote: post #13

Disregarding the emphasis on XML -> replaced with JSON, isn't this actually mostly spot-on re the popularity of Single-Page Apps (SPA)? There is very little if any HTML in the form of the text-based markup involved in a modern SPA - the actual display logic is all DOM manipulation in JavaScript, operating on separate APIs providing just the raw data in JSON form. > Truly powerful applications can be built using combi…

> isn't this actually mostly spot-on Only if you accept the initial premise, which is nonsense. The article is based on the idea of HTML as an interchange format, something that's only the case in dysfunctional situations (scraping data illegally, or a horrific breakdown in communication/collaboration between two business entities). Sure, there was a for a time a big focus on XHTML as a "hybrid" format - interweaving…

This article was written during a time where the idea of a semantic web was still bright and strong. Scrapable HTML websites would have been at the forefront of interchange ideas then.
Post reply on HN