The web as a platform: a contract, not a device

A page is written once and read on a laptop, a phone, a television, a screen reader and a browser that did not exist when the page was published. Most platforms hand the designer a known screen and a known input device. The web hands over a document and a set of rules about what may be done with it. Those rules, and not the machines, are what an author designs against. This unit sets out that contract. The nine that follow test one clause of it each.

The web is a platform whose contract, not its devices, is the design. A document is identified by an address and delivered as a representation. The author does not control the user agent that renders it, so the author delegates the final rendering to software in someone else's hands. That delegation forces resilience into the document. It does not come from any feature list. Progressive enhancement is therefore a requirement the platform imposes, not a style a designer chooses. The contract has been stretched before, when it was asked to carry applications, and whether it can carry them is the live disagreement in this literature. The strongest counter to this unit's thesis is that the contract is a constraint rather than the design: Taivalsaari, Mikkonen, Ingalls and Palacz (2008) hold that the document inheritance is a lasting handicap.

A platform defined by what it delegates

The founding document makes the constraint explicit. Berners-Lee's 1989 proposal to CERN describes a distributed information system. Documents are linked and served to clients the server does not know, and the problem the proposal sets out to solve is information management across heterogeneous systems. It is a design intention rather than a study. It fixes the platform's original commitment: the server publishes and never meets the reader.

Fielding's dissertation (2000) derives the architectural constraints such a system requires. Fielding and Taylor (2002) reconstruct the rationale for a journal audience. They argue that three properties produced the design: the scalability of component interactions, the generality of interfaces, and the independent evolution of components. Their move is to separate the architectural style from its HTTP implementation, which makes the platform's tolerance of unknown clients visible. The Architecture of the World Wide Web (W3C, 2004) states the same commitments as normative guidance. It sets out how resources are identified, represented and interacted with, and it asserts the independence of the components that do the work.

Together these sources describe a contract with three clauses. A resource is named by an address, not by a screen. A representation is one of several the server might send. Any component, browser or author, is replaceable without changing the others. Those clauses are a permission and a price at once, because nothing promises that the author's intent survives intact.

Work the clauses through one address. A reader types the address of a weather forecast. The server names a resource rather than a page, and it returns whichever representation the request asked for: a document to a browser and a data file to a script. The browser the server has never met lays out the first. The script draws a chart from the second. The address, the data and the server stay the same, and the server was written for neither client. That is the delegation in operation, and it is why the author cannot inspect the result.

The contract is older than its devices, and the application strain came later

Device names change faster than the contract. Panchekha and Harrelson (2024) narrate the web's history from its origins through browser evolution, and they focus on the goals of the people who built it. Their account shows the architecture was argued before there were devices to argue about. Anthes (2012) reports a later shift, when the HTML5 specifications made the document platform programmable, driven by mobile devices and social networks. Taivalsaari and Mikkonen (2011) trace the same arc from document sharing to a general purpose application and content platform, and they ask what that history implies for the future.

The strain shows when the platform is asked to do more than documents. Taivalsaari, Mikkonen, Ingalls and Palacz (2008) argue that the browser has become a widely used target for applications, and that features inherited from its document past make it an awkward one. They analyse what it does well and where expectations carried over from desktop software break. Their assessment is engineering judgement rather than a user study.

Why delegation forces resilience

If an author cannot know the client, the author cannot test against the client either. Gustafson (2008) states the pattern in its clearest practitioner form: content, then style, then behaviour, in layers that each fail without taking the others down. A document read by a browser with no stylesheet and no script is still a document. Keith (2017) generalises the pattern into a history of web design that treats resilience as the platform's defining strength. Progressive enhancement is therefore not a matter of taste. It follows from delegating rendering to unknown software.

Marcotte's demonstration (2010) is the pattern worked on a real page. His two-column magazine layout sat on a fluid grid, and he showed it failing at the edges of the range. Below a viewport of 800 by 600 pixels the illustration behind the logo was cropped, the navigation text wrapped, and the images grew too small to read. On a widescreen the same images swelled and crowded the text. The repair was three rules in the stylesheet rather than a new layout. Below 600 pixels the major blocks dropped their floats and stacked in document order. Below 400 pixels the figures fell from three across to two. No device was named and no client was detected, so the document carried rules for widths its author had never seen.

Can the contract carry application expectations?

The hardest case is an application, not a document. Charland and Leroux (2011) compare web and native mobile development. They concede the web's advantages in development and deployment cost, and they question whether it can match a native experience. They argue as practitioners weighing trade-offs, not as experimenters, so the paper states the strongest version of the doubt: reach may be bought at the cost of experience. Against that, Biørn-Hansen, Majchrzak and Grønli (2017) assess Progressive Web Apps as a way to unify mobile development through web technologies with app-like features. Majchrzak, Biørn-Hansen and Grønli (2018) ask whether Progressive Web Apps are the definite approach to cross-platform development. Both are assessments of a technology rather than controlled outcome studies. Both show the contract being extended towards application expectations: installing, working offline, and behaving like an installed application. That is the strongest test of the unit's thesis.

Contested question: does the contract carry the application, or does reach yield to experience?

The literature disagrees, and both sides sit in this unit's own list. On one side, Taivalsaari and colleagues (2008) and Charland and Leroux (2011) hold that the document heritage is a lasting handicap. The browser is a good delivery mechanism and an awkward application platform, and a designer who needs a dependable, closely coupled experience should expect to pay for reach. On the other, Taivalsaari and Mikkonen (2011) argue that the platform has repeatedly absorbed new demands. Biørn-Hansen and colleagues (2017) and Majchrzak and colleagues (2018) hold that Progressive Web Apps close much of the remaining gap without giving up the web's distribution.

The two positions make different predictions, and they need different evidence. If the pessimists are right, the same application built both ways should show consistent penalties in the web version. Those penalties would appear in task performance, in responsiveness under adverse conditions, and in the maintenance effort needed to reach parity. If the optimists are right, those penalties should shrink as the contract is extended, while the deployment advantage holds. What would settle the question is a controlled comparison of one application on both targets, measured on task outcomes and on the cost of keeping it working. It is not a capability list, which is largely what both Progressive Web App assessments supply. That comparison is largely missing, and its absence is the honest state of the question.

While the question is open, a designer should treat the contract as a floor rather than a guarantee. Build the document so it works with no script and no stylesheet, then add behaviour in layers. Test the application path on the slowest client the audience uses, and say in the interface what a reader may lose.

Where the argument is heading

The literature points to continued stretching of the contract rather than its replacement. Panchekha and Harrelson (2024) read the history as a sequence of goals carried forward. The Progressive Web App work of Biørn-Hansen and colleagues (2017) and Majchrzak and colleagues (2018) is the current running test of it. Measurement will settle whether that extension reaches the reliability of a native platform.

The sources this unit rests on

• Berners-Lee, T. (1989). Information Management: A Proposal. CERN, March 1989. https://www.w3.org/History/1989/proposal.html It sets out a distributed information system in which linked documents are served to clients the server does not know, treating information management across heterogeneous systems as the problem. It is the design intention itself, not a study.
• Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine. https://ics.uci.edu/~fielding/pubs/dissertation/top.htm It derives a set of architectural constraints for network-based software and names the resulting style Representational State Transfer, where the vocabulary of the platform's contract is usually traced. It is a design argument rather than a measurement.
• Fielding, R. T. and Taylor, R. N. (2002). Principled design of the modern Web architecture. ACM Transactions on Internet Technology, 2(2), 115-150. doi:10.1145/514183.514185 The authors reconstruct the web's design rationale from the constraints a distributed hypermedia application must satisfy, arguing that scalability of component interactions, generality of interfaces and independent evolution of components produced it. Separating the style from its HTTP implementation is what makes the platform's tolerance of unknown clients visible.
• W3C (2004). Architecture of the World Wide Web, Volume One. W3C Recommendation, 15 December 2004. Geneva and Cambridge: World Wide Web Consortium. https://www.w3.org/TR/webarch/ It states the principles by which the web is identified, represented and interacted with, including the rules on URIs and the independence of components. It is normative guidance with no user evidence, the standards body's own statement of the contract.
• Panchekha, P. and Harrelson, C. (2024). History of the Web. In Web Browser Engineering. Oxford University Press. doi:10.1093/9780198913887.003.0003 The chapter narrates the web's history from its origins through browser evolution, focusing on the key events and on the goals of the people who built it. It is a teaching text, written to explain rather than to argue, and it grounds the unit's framing in a current source.
• Anthes, G. (2012). HTML5 leads a web revolution. Communications of the ACM, 55(7), 16-17. doi:10.1145/2209249.2209256 Anthes reports the HTML5 specifications as a platform shift driven by mobile devices and social networks, describing what the new capabilities let developers build. It is a contemporary account of the platform becoming programmable rather than a test of an outcome.
• Taivalsaari, A., Mikkonen, T., Ingalls, D. and Palacz, K. (2008). Web Browser as an Application Platform. In 2008 34th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). doi:10.1109/seaa.2008.17 The authors argue that the browser has become a widely used target for applications and that features inherited from the document era make it an awkward one, analysing where desktop expectations break. It is engineering judgement rather than a user study, and it carries the unit's tension between reach and reliability.
• Taivalsaari, A. and Mikkonen, T. (2011). The Web as an Application Platform: The Saga Continues. In 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA). doi:10.1109/seaa.2011.35 The follow-up traces the web from a document-sharing system to a general purpose application and content platform and asks what that history implies for the future. It is an argument about trajectory, and it shows the contract being stretched before it held.
• Charland, A. and Leroux, B. (2011). Mobile application development: web vs. native. Communications of the ACM, 54(5), 49-53. doi:10.1145/1941487.1941504 Charland and Leroux compare web and native mobile development, noting that web applications are cheaper to develop and deploy while questioning whether they match the native experience. It is a practitioner weighing of trade-offs rather than a controlled study, and the unit's strongest counter-argument.
• Biørn-Hansen, A., Majchrzak, T. A. and Grønli, T. (2017). Progressive Web Apps: The Possible Web-native Unifier for Mobile Development. In Proceedings of the 13th International Conference on Web Information Systems and Technologies (WEBIST). doi:10.5220/0006353703440351 The authors assess Progressive Web Apps as a way to unify mobile development through web technologies with app-like features, arguing that the approach can reduce multi-platform effort. It is a technology assessment rather than a user study, so it shows the contract being extended without measuring whether it holds.
• Majchrzak, T. A., Biørn-Hansen, A. and Grønli, T. (2018). Progressive Web Apps: the Definite Approach to Cross-Platform Development? In Proceedings of the Annual Hawaii International Conference on System Sciences (HICSS). doi:10.24251/hicss.2018.718 This study assesses whether Progressive Web Apps deliver on their cross-platform promise, comparing development and delivery expectations against the platform realities. It is an early evaluation, and it keeps the unit from treating a specification as a demonstrated outcome.
• Marcotte, E. (2010). Responsive Web Design. A List Apart, 25 May 2010. https://alistapart.com/article/responsive-web-design/ It sets out fluid grids, flexible images and media queries as one approach, arguing that layout should follow the medium rather than a device. It is a widely adopted practitioner argument with no controlled evaluation, and the article that put responsive layout into practice.
• Keith, J. (2017). Resilient Web Design. Online book. https://resilientwebdesign.com/ The book argues through historical cases that web design should be built to survive failure and change, with the document as the durable layer. It is a practitioner synthesis written to persuade rather than to measure, and the strongest statement of the unit's thesis.
• Gustafson, A. (2008). Understanding Progressive Enhancement. A List Apart, 7 October 2008. https://alistapart.com/article/understandingprogressiveenhancement/ It states the layered order of document, style and behaviour and the rule that each layer should fail without taking the others down. It is the clearest practitioner statement of the pattern the unit tests, though it reports no evaluation.