3 ms·
One of the worst mistakes that the original web made was getting rid of the editing component in the early stages, probably once corporate entities and their cu
by mhd 8y ago
One of the worst mistakes that the original web made was getting rid of the editing component in the early stages, probably once corporate entities and their cut-up picture sites got big (yet note that the reference web implementation "Amaya" was also an editor).
And in a similar note, a distributed web needs ubiquitous editing and publishing. Right now I think that both are better served by something really lightweight. A distributed web publisher should be able to run on an ESP32. The editing and display component should run on old laptops or mobile phones. That probably means good riddance to JS everywhere...
Distributed WAP?
- nostrademons 8y agoThe editing component died out well before that. The original WWW browser was bi-directional: it was as easy to publish or edit sites as it was to view them (much like Wikis are today, but with a WYSIWYG editor). Even up through about 1998 Netscape shipped with Composer, which made it relatively easy to generate & publish HTML without knowing much about technology. I think the problem was just development effort and the pace of development in the early web (and particularly during the browser wars). Shipping an editor with the browser meant that every new feature available to websites needed both an easy implementation (in the browser) and a difficult implementation (in the editor). The editor implementation would often require a lot of uncertain design work as people hashed out what the editor UI should even look like. It forbade the browser vendors from shelling this hard task out to external programs. If you wanted to embed a photograph on a webpage, Photoshop had already spent decades solving that problem; was the browser vendor supposed to duplicate all that work? If you wanted to embed a Java applet, Sun and Borland and IBM had invested thousands of man-years on development tools; would you ship an IDE in the browser? Some content types are just now getting decent editing software, 20 years later. When you have 150M users browsing and maybe 1.5M users creating content, the economics are pretty clear. There's no sense putting 80% of your development effort into tools that 1% of the population uses. Interestingly, even after user-generated content became a huge thing and easy WYSIWYG editors became just a JS embed away, the 1:10:100:1000 ratio still roughly holds: for every person creating content daily, 10 people create content *occasionally, 100 register for the site, and 1000 people might view it as lurkers. That indicates that the problem might not be in the tools, and that creating content is just more difficult than consuming it.
- lazyjones 8y ago> The editor implementation would often require a lot of uncertain design work as people hashed out what the editor UI should even look like. Isn't this just a dodgy way to circumscribe the complete failure of the W3C to keep their specifications sane enough for them to provide a reference implementation, even for a simple browser? That's how we arrived at the mess we have today, where you need a 9 figure budget just to maintain a modern browser implementation.
- mftrhu 8y ago> something really lightweight Gopher is still a thing which would very much be editable and displayable on old laptops or mobile phones (even feature phones which only have J2ME [1]). Some people have been working on a vaguely similar lightweight protocol and markup language [2], which should be simple enough to render in a sane manner even on very constrained systems. IMO, it'd be more interesting than something based on WAP/WML. [1] http://felix.plesoianu.ro/mobile/pocket-gopher/index.html http://felix.plesoianu.ro/mobile/pocket-gopher/index.html [2] https://contnet.org/ https://contnet.org/