Hacker News Reader

Comment by jacquesm | Hacker News Reader

The big divide is between apps and pages. Pages are just documents and should not contain any code. Apps are fine to contain code. The problem is that we now have pages that believe they are code and apps that have to be styled using the mechanisms for pages. This duality is here to stay for at least a while to come, and maybe for a long time.

But it would have been good security wise and privacy wise if this divide were made more explicit.

View on HN

> Pages are just documents and should not contain any code. Apps are fine to contain code. The problem is that we now have pages that believe they are code and apps that have to be styled using the mechanisms for pages.

Javascript was intended to script HTML pages long before the concept of a "web app" was a thing. A divide between static documents and "apps" never even existed in theory, and with very few bleeding-edge exceptions, apps are also documents.

Javascript was made to 'fix' faults in html forms processing such as input validation, and to allow underwater resource loading.

Among other things including DOM scripting, yes... but there was never any historical intent to consider HTML pages which used javascript at all as being something fundamentally separate to pages which didn't, or something other than documents.

I know that. But if they had made that distinction the web would be a lot safer, privacy friendly and more user friendly.

But the distinction wouldn't have even made sense at the time, and for most of the web, it still doesn't make sense. It may only make sense in the future, when WASM matures more, though.

All of the privacy violations and dark patterns that javascript gets employed for are the result of choices made by developers and corporations... they're not fundamental and innate features of javascript or of having scripting in the web to begin with, so they're not problems that would be solved by quarantining the language to some kind of "app" space.

Would it, though?

It's not like all of the problems on the web are caused by technology. Adding a <script> tag to your HTML doesn't automatically make your page weigh 10MB and snoop on its users. All those problems are caused by business decisions. When you decide to add an analytics script, or put an ad on the page, or hire a designer to make it look appealing to customers - that's where things go wrong.

In other words: even if we had a page/app split on the web from the beginning, businesses would still fuck it all up, and we'd have the same problems with bloat, ads, dark patterns and surveillance capitalism as we have today.

The reason the distinction isn't present in the web standards is that the web never intended for apps to be in scope at all. Being able to make something like Google Maps available on the web is pretty much a hack.

Intent for the ability to run code on the web goes back at least as far as discussions around HTML3, and you can find discussion about it on mailing lists from 1995[0]. Before javascript took over, the intent behind the <SCRIPT> tag was to support multiple scripting languages[1], and of course <APPLET> isn't exactly new. It isn't true that the web was "never intended for apps to be in scope at all," rather it is true that HTML didn't support anything of the sort from its initial version. Of course, HTML initially didn't support much of anything.

The reason the distinction isn't present in web standards is that likely no one foresaw the massive complexity of modern js applications using HTML as a GUI analogue - it was assumed that code on the web would be like shell scripts or utility scripts, and javascript was just intended for light housekeeping, nothing that would necessitate forking the entire web to create an "app" space.

However I have yet to find much evidence of hostility towards the concept of running code on the web from the people who actually came up with it - the "javascript delenda est[2]" attitude seems to be a modern ideology. Rather, the discussions I've read were about how to make it possible, what languages to use, etc. Not how to prevent it.

[0]https://lists.w3.org/Archives/Public/www-talk/OverviewOld.ht...

[1]https://eager.io/blog/a-brief-history-of-weird-scripting-lan...

[2]https://news.ycombinator.com/item?id=11447851

What I have been wishing for a while is having well-defined purely document-oriented subset of HTML5 standardized. In practice it probably would mean different levels or profiles defined. It could help with many usecases beyond just web, email coming to mind as an example

This might be a brilliant idea, on par with asm.js.

Mozilla can implement it like they they did with asm.js, after all it is a subset, not a superset.

It will then work in all browsers but (I guess) can be made to work much faster if the browser knows it can ignore the piles of old hacks that full html has to consider.

Edit: and like asm.js it might lead to something even better going forward.

Brilliant. How can me make this happen?

The real challenge here is that document and application tend to get mixed up on the web.

Looking at even a good old-fashioned blog, there are really three nested things on your screen: the blog post document, the blog post-viewing application, and the browser.

Why a blog post-viewing application? In theory you could skip it and just have a plain reader view, but in practice you do want to have navigation and comments, and that's what the application part is for.

Many modern systems surface that split in the form of an API: the API is what gives you access to the underlying document.

The challenge would be making that solid accessible to the user. For example, could a browser natively have two address bars? One for the document, and one for the application that is used to access the document?

I have had thoughts around that same idea as well. Could be a start to just define a subset of existing good semantic HTML elements to use for a blog, a news site etc. My dream is to be able to browse a subset of the web, that only uses this kind of document format. Something like docuweb.example.com or whatever :)

Some documents are meaningfully improved with code: data visualizations when done well, particularly.

That's true, there are places where code improves the page. But these are the exceptions that confirm the rule, your average news site, blog, scientific paper typically is improved without JS, not diminished.

And the exception use case could be handled the same way that Flash was during its decline -- a box showing that there is some special content on the page, but it doesn't run until you explicitly click on it.

Then it's there when you need it, but the friction discourages it from being used frivolously and gives you the opportunity to decline when the context makes it obvious it's not being used for anything good.

>But these are the exceptions that confirm the rule

I don't think this expression makes any sense. https://en.wikipedia.org/wiki/Exception_that_proves_the_rule...

Yes, true. It is important to understand, that computers brought us further than paper. We now can have "Interactive Documents". And we should respect that, understanding, that this often dissolves the border between document and application. I see no problem with that. In the end, it all comes out to: sometimes you need program logic (Javascript) in the document. If this is the case, then just use it. The problem, as so often, starts with business and marketing. For them it's neither a document nor an application, it is "presence". And this is how it tends to get nasty...

The divide was pretty explicit once, but people hated Java and Flash Applets so this is the "improvement" we get. I hope you're all happy.

Reply on news.ycombinator.com