Documents ≠ Programs
mckinley.cc
mckinley.cc
Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
For comparison, consider that apple just proposed adding a html tag to display 3D models, just like an image.
The problem is that even basic interaction with a 3d model requires complex controls. There is no single standard for materials and lighting. The going methods are optimized for photorealism.
So adding a model tag just means baking in a set of assumptions, and doing so before you have a good idea of the kinds of things people will want to do with it and can't.
This is the real story of the web: poorly conceived standards and APIs, frozen before the medium had time to find its feet. It's a horse designed by committee in a world of cars.
You could turn the question around: why should webpages be dynamic at all? Just make a dumb client that requests rendered SVGs from a server after a client tells you its screen size.
Oh but that can't work because it's not really a document, but a dynamically laid out program after all.
If you want to displace the single page apps of the world, design a "document" format actually capturing all the nuances people want from them... Or get off the pot.
Also this series of pages was extremely popular on HN, and can't be done without programs embedded in documents:
In this case it's done quite "literally" !
https://ciechanow.ski/js/gears.js
Although on closer reading the OP does make a distinction between documents embedding programs, and programs that build up documents (like medium.com), which I agree is an anti-pattern.
I don’t think it’s possible to anticipate exactly how everyone will want to use everything, but maybe we could reach a world where it’s easier to iterate on this.
For example, what if there was a way for the community to implement new HTML tags for their preferred browser? This could be implemented as an extension, though perhaps not under the dominant WebExtension paradigm. This would allow much faster iteration on the semantics of HTML within the secure sandbox provided by the browser. The IPFS extensions are a nice example of doing this at the protocol level.
Similarly, what if you could version HTML tags? That would be a bit of a nightmare, but would also allow authors to communicate more information to the browser about what functionality is expected from the tag.
Of course, this would lead to a strange ecosystem with many dependency management headaches for users. You’d have to worry about what new features were needed by the page you’re trying to view, which extensions you have installed, do they implement the tags you need, and do they do it well?
This would lead to “super extensions” that address many tags and become de facto requirements for everyone. Then those become security targets. Of course, they would have their own coordination process, parallel to W3C. This would become a business target just like W3C is, with google trying to manipulate it to liquidate user freedom to support advertising.
It’s hard to get big groups of people to work together effectively.
It’s hard to get big groups of people to work together effectively.
One of the valid ways to deal with it is to let them work separately.
"apt install myapp" works 95-99% of the time. The remaining time, you drop yourself into DLL hell of some flavor or other (package was poorly maintained, or your clone of the package repo indices is out of date, or you installed a local copy built-from-scratch of one of the binaries and it's now fighting with the distro binary, &c &c). And then remote tech support is impossible because for someone to provide support, they either need intimate knowledge of your configuration or you need to be running a stock configuration (and with very few, usually vendor-controlled exceptions, "stock configuration of a Linux distro" is a non-concept).
There was, ages ago, a paper describing what the design of a componentized browser rendering engine would look like (where pages could basically declare "I require engine components X, Y, Z" and the browser would have a library of them that could be spun up on a page-by-page basis). I wish I could grab a link to it; I think it may have been a Mozilla experiment? If I recall correctly, the complexity meant it never gained traction.
It was novel at the time, and we have something like that today in the form of the web browser... Though most data one fetches isn't intended for in-place editing, the convenient thing about web pages is that their hierarchical, dynamic, and self-modifying nature allow for a lot of the concepts explored in OpenDoc and OLE to be implemented within them.
> You could turn the question around: why should webpages be dynamic at all? Just make a dumb client that requests rendered SVGs from a server after a client tells you its screen size.
> Oh but that can't work because it's not really a document, but a dynamically laid out program after all.
What prevents one from sending a screen size and getting a server-side rendered SVG back with that exact screen size? It was a thing in Telnet days, and it's what Stadia/Mighty browser are doing. Not that I'm saying it's a good idea, but it is feasible.
But it would be better if the application functionality of Google Maps was part of the document viewer (or selectable from within the document viewer), not of the document, because that gives you the flexibility to use your map viewer of choice, instead of being bound to Google Maps. That’s the point of separating document from viewer (and/or editor). Turning everything into an app reduces choices and interoperability.
> Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
I would argue that websites would be better off embedding an image of the location that links to a dedicated map viewing service like OpenStreetMap.
I might be in the minority here, but I always hate trying to use interactive maps in tiny boxes on people's websites.
It seems to me that the internet application model is far more attractive than the locally installed application model on any OS. As proven by, well, the past few decades.
I started out with BBS and when I started to play with the web, I thought mosaic and webcrawler were mind-blowing. I remember faxing in my info to buy domains and I know I had a geocities site, though ill never remember the name I used.
I'd done over a decade of server side rendering and knew, just absolutely knew, that client-sode rendering would be a massive improvement for all parties. And it can be when done well (I admit it isn't always). We're still many years behind where we should be in what our browsers should allow for client development.
What we're capable of now with what can still be considered an enormous collection of "documents" is just incredible. I'll take this over those days. What I personally miss most is the ability to read the uncompiled code. That's where we lost the most, as that's where I learned almost everything.
And after 20 years of professional development on multiple platforms and languages, I still largely prefer web development. I'm far from alone. I think that says a lot more about classical "application" development than it does about the web.
I'm curious why. For me, I've always been interested in keeping intellectually stimulated when I'm at work. I don't want impossible challenges but I want something that, while I'm working, time disappears so it doesn't feel like work.
Now, I did my fair share of server side rendering applications in the 2000s and enjoyed it at first. It was quite enjoyable to be able to pass my ideas and application around to others without the barriers of cross platform compatibility or security models that make running unknown or less known native binaries a no-no. This melted away with web applications (mostly, bar some pretty notable browser vulnerabilities during that era).
What happened really was Chrome's sandboxing and security overall that comforted many that running arbitrary JS code from an external source was "OK" because your browser was mostly protecting you from doing nasty things to your local system and data. This exploded into expanding JS, ES, and the entire development ecosystem.
To me, this is really what made things intriguing and I suspect why many love web development, they can easily share their creations now to about anyone without many barriers, just type in this address on your phone or laptop and tada.
Unfortunately, the development ecosystem is a mess. I don't think this says anything negative about classic application development, I love classic application development because it's usually well structured and I don't have to waste cognitive load dealing with silly technical issues I don't care about--I can focus on the application and what I want to create more. I don't want to know why this silly UI element isn't behaving the way it should and deal with a workaround, I just want a UI element that does this so I can move along and do the interesting work. What traditional application development really lacked was ease of portability for others to use securely.
The OS has now become the browser to many and this is their playground. Unfortunately I don't enjoy it because I'm used to mature frameworks where I don't worry so much about the application development as much, I worry about the application and translation of ideas into something people can use. Web development is getting there but it's just not there yet and if you've been spoiled with stable development environments it's hard to go back to the wild west of dealing with what you considered to be mostly solved problems decades ago.
I prefer programming in many other environments. I also greatly prefer not having to distribute anything to other computers.
The article is complaining not about the use of the Web to write/host apps, but about the unnecessary use of app-writing functionality (aka JS) to "enhance" documents or to reimplement browser document-reading functionality.
If you're writing an app, write an app.
If you're writing a news article, write a news article.
But browsers have not been improving their ability to serve documents.
Besides maybe initial load times (and fewer ads, whizzes, and pops), I get no significant benefit to reading an article with no JavaScript.
I don't get a searchable cache of my document history.
I don't get to swipe it over to some other device to continue reading without relying upon some other service.
I don't get some guarantee that the document will render on any device and that I can send the document to someone else without a url.
I can't highlight or add notes to a document or make corrections and view my (or others') versions of it.
Sure, they're documents, and so I should be able to treat them as such. But I can't. They're not portable. Browsers aren't really great for document management or manipulation. Static sites are just as tied to the browser and host as any app.
While I largely agree that dumb documents aren't that useful, I'd say a large part of our actual web interaction is still just dumb documents with some form of response (like what I'm doing here, or site comments, as others do). That's not to diminish actual applications which are made much easier by the web's distribution model, like Google Maps or Google Docs.
The web is absolutely document-first. Our applications are _still_ just documents, which is pretty incredible.
I just don't think it's very good at being document-first. A sufficiently advanced document-first platform would have a lot more functionality in regards to reading, modifying, maintaining, and sharing documents. As far as any consumer is concerned, a basic note-taking app provides more functional use than a web browser.
That may be the reason it's become better known as a kludged together application platform derived from layers upon layers of workarounds - around a substandard document viewer with amazing plugin support.
If I'm making any point at all, it's that I don't accept the premise of the original post. The web isn't as good at serving documents as we tend to say it is, but it's become quite the application platform, because everyone seems to want it to be one. So who cares if people make crappy pages using JS when it isn't ideal?
I've always framed it in terms of "where are the files?" Maximum control for the cool-making companies means "hide them from the users."
I'm really really really happy to see projects like obsidian.md that see the value in not doing that.
I'm also a fan of obsidian.md.
More seriously, I think I'm coming around to -- I don't care where or how the applications are made per se. I used to hate the web-stuff->desktop applications idea (electron et al) because it seemed dumb and slow, but both Discord and Obsidian disprove that pretty well I think.
It really is about "where is your stuff." It's fine to optionally store whatever in whoever's cloud. But increasingly, I believe that anyone developing any sort of application in which the user's stuff and how it moves around is not 100% transparent is quite literally evil and I wish them utter failure.
Instead it's complaining about bad JavaScript usage and needless "apps" for "personal websites", which by the definition of the author are just documents to be shared. I love badmouthing SPAs and needless JS like anyone else, but what if I want a bit of interactivity such as comments? Am I not allowed to do that on my personal website by the author's definition?
I think most importantly it misses the point that the web never was about defining documents. HTML was about linking pages and resources together. And even early on, CGI was a thing, and interactivity quickly became the "killer app", starting with search.
I mean, Mosaic added forms in 1993. [1]
OP addresses this point well in my opinion:
> If your page includes a few non-essential scripts to do different things on the page, that isn't a problem. The document itself is still readable in a wide variety of programs and formats, regardless of support for those scripts.
If your post is still readable without JS, no one complains if the comments don't work. And no one complains, if you implement comments using JS.
The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
My core issue was around this and I should have sticked to it :
> The original purpose of the Web was to be a set of protocols and formats used for the purpose of publishing documents.
I still think this is a bad argument, I disagree that HTML was conceived as a way to make "documents", but it shouldn't matter, things evolve on their own and people may use your creation in ways you disagree with.
> The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
I 100% agree with you, but the distinction is the "core content" part.
Part of the page is that core content, and what we actually want to see/read indeed (and why various web browser brought a "reader mode" that extracts that part). But the page itself is not a document that only contains this core content, and hasn't been for a couple of decades.
Most blogs/publication, even personal ones have been backed by a publishing system with the core content in a database. At this point these are applications, and many of these system can still output "pages" that 100% fit the description of being easily readable without JS, while still adding a lot of utility. Hence my disagreement around the "Documents ≠ Programs".
That's the distinction I was trying to make.
> It can be very useful to run certain programs in the browser. In a lot of cases, however, the same technologies are used for documents.
And yes, often the HTML is generated from a database. That's fine. "Document" does not equal "file on disk". The HTTP/HTML model just talks about the entities that actually hit the wire. If what you're delivering to the browser isn't a document, but rather a program running in the browser to build a document, you should be taking a deep breath and checking whether you actually need to do that.
Yes, and most of the idiotic complexity on the web today is the result of people insisting that instead of clearly defined execution and communication models all we needed was a document with some "extra features". Admit it. Alan Kay was right. All the web developers were wrong.
I like simple HTML. I even design most of my web stuff so that it works without scripts. However, the idea that documents are always simple and programs are always complex is wrong on the most fundamental level.
A lot of what we see today is simply chasing towards new trends that have been set by few of the giants of industry, dragging the rest of the market behind them and affecting hireability of those who know or don't know how to utilize these technologies. Not every site needs React, Angular, Vue, however at the same time there's also something to be said about how those don't make you run into some of the problems with stale state or every integration having its own mechanisms to tackle those problems, that jQuery had in the instances where you actually wanted dynamic sites.
Regardless, i still think that far too many websites are dragged along and coaxed into using those technologies, which, when combined with ads, analytics and numerous other scripts as well as various design elements can lead to those sites being far too heavy for my liking. For some examples, look at the "Website Obesity Crisis" talk: https://idlewords.com/talks/website_obesity.htm
There is a good reason to do that. HTML has no templating abilities built-in, which has a lot of downstream effects. Most sites benefit from a templating system, because most of their pages are very similar. I.e. each blog post has the same nav bar, each item in an ecommerce store has the same format.
You can pre-render those pages, but that becomes more and more difficult the more pages you have. Incremental builds exist, but tend to get buggy. As soon as you have a site that becomes too large to rebuild for each change you get, things become problematic.
Javascript fixes this because it allows you to treat your content like a template that accepts data. Updates are near-instant because it's often just modifying a database row.
I'm certainly not saying the current environment is perfect, but HTML-as-documents is fading because it's a restricted subset of the things you can do with HTML + Javascript. It's the same reason I don't see a lot of people logging directly into the terminal in Linux. Sure, it can do a lot of what I want it to do, but I can get a terminal in the GUI even if it's slow. The GUI can also do a lot of things the terminal can't, so I log into the GUI by default.
Static sites are better for those who don't want to enable JavaScript or who would like to save a copy of the page to read later. I'm sure there are accessibility benefits with less complicated websites, too.
Maybe I'm just strange, though. I log in directly to a TTY.
I can recommend as test for you, to turn off JavaScript (about:config -> javascript) and check out how web works for you. You will notice that Amazon works well and quick, it is a website. You will lose some comfort features on Stackoverflow, but still a website. Single-Page-Applications will not work - but at least you won't download unknown JavaScript from CDNs and your webbrowser will not execute it and spin up your fan. Interesting enough it are news website which tend to break, their advertisment-networks and paywalls need JavaScript.
Of course there are good single-page-applications and there is stuff, which is better handled solely online. The old 3270-Emulations are an example for this. In most cases your professional users will appreciate desktop-applications, which store data locally, work fast and reliable stand-alone and uses server for syncing but not for execution. Updates could be part of the synchronization or you use modern stuff like FlatPak. Yep - you will have to pay application developers for this which will cost you money. But money? If done right you won't need to close your supermarkets next time you have an server outage, your clients switch to standalone mode and sync later the bills to the servers. That can safe a lot of money. And your admins can fix the server in meanwhile.
As a consequence the web will be maybe a lot of faster and safer, too.
The first, in the linked post, states
> It’s massively over-engineered! But that’s the point: learn, have fun and enjoy slowly hacking away after the kids go to bed.
So even if we conclude that the cost-benefit of the application-like functionality of this person's site slants toward cost (this isn't actually argued, of course), the creator of this site agrees -- it's just that the fun and learning make it worth it.
About the second example, the author states "Why was it designed this way? I couldn't tell you. It reminds me of a quote: 'An idiot admires complexity, a genius admires simplicity.'"
Well, one reason why it might have been done suboptimally is that the creator is a college student (https://slc.is/#About). Nobody learn in public where this guy might find it, I guess, or you're an 'idiot'.
If you're making this argument without reckoning with the pros and cons of the application paradigm in professionally engineered websites, you're not serious about the argument and you're just being a jerk.
There's nothing wrong with learning, of course. My point was that if you choose to introduce this unnecessary complexity you will likely end up with an unreliable website that alienates some visitors.
Most personal websites are made for the creator themselves more than they are for others, mine included. With computers, you should do what makes you smile. On the other hand, publishing something on the internet opens yourself up to criticism by others. There's definitely a lot of problems with my website, I invite you to write about it.
A blog should be readable everywhere, even in lynx. Interactive, discoverable documents and multimedia content should include a text fallback if possible. And real apps like a photo editor -- well they need to be executed.
I'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)
Honestly I never understood this trend. From a developer side, the engineering easily costs two times compared to a traditional site.
There are so many "plain text" websites that simply do not load without JavaScript. Is this a consequence of using a framework like React? I feel like the world needs a "component-based" framework, but one that can gracefully degrade if JS isn't available.
It depends on how much JS is used and what it actually does. Sending and receiving data in a JSON format as opposed to receiving HTML? Could be marginally faster and would also allow integrating the API for fetching data with other front ends or other consumers easily.
What causes the actual slowdown most of the time is framework code which cannot have the unused bits removed efficiently because of how dynamic most of the languages that we use are, even if there are tree shaking advancements that you hear about every now and then.
That said, it's not entirely hopeless - you certainly can use something like react-snap to pre-render your site and then hydrate it with dynamic content and JS if supported by the user: https://web.dev/prerender-with-react-snap/
Of course, degradation won't necessarily be graceful - everything that depends on JS simply won't work, as opposed to have some theorethical server-side fallback component, as nice as that would be. I've also heard of server side rendered React, however, even though i haven't personally used it: https://www.digitalocean.com/community/tutorials/react-serve...
To be honest, trying to achieve such wide support for technologies and graceful fallback logic is a can of worms in of itself, so many simply choose to require JS functionality for their app and don't attempt to support other configurations, which is a shame.
Also, if your website just happens to have that one bit of information I care about, and I don't view other pages, rendering with Javascript is a complete waste.
At first.
But if you setup a lot of cool plugins with the newest bundler, add modern libraries and make good use of web workers and graphql, in a few months you can get your costs up to 5 or 6 times!
Wait, it makes it easier?
> But if you setup a lot [of libraries] ... in a few months you can get your costs up to 5 or 6 times!
Ah, lol!
But in all, SPA for SPAs makes sense, but for documents it's counterintuitive. I mean I can see a case where it might be worth it, but looking at Wikipedia maybe it's not justifiable for the increased maintenance.
Of course while the usual cause of rendering slowness in applications is emphasised (which is what I hear as a reason in favour of SPAs), but it tells me that your CSS isn't really optimized for your case.
If your backend only takes in requests and spits out data, you can build the backend without spending any thoughts on user experience, layout, templates etc. All you do is design a database structure and API endpoints.
Because you can then derived a good architecture from that, but never the other way around.
But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers.
As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...
Say the backend developer coded a bunch of Django views where they output json data. They say "Job done. There are API endpoints for everything now.".
Now how does the frontend developer bring their templates into play so the json gets rendered "on the server side"?
In a setup where the frontend is doing the rendering, you can give the frontend developer access to a directory with static assets that get output to the browser verbatim.
How do you give them the ability to "have a Django template filter" without them having the ability to mess with the rest of the backend? Or do you set up a second server that talks to the APIs of the first server?
But I don't think Django templates are safe in a way that they protect the backend from a clueless or malicious frontend developer. Even if they were, you would have to take great care that you do not expose dangerous functionality. So "give them access to the Django template itself" is not enough. You would have to have a whole security concept around it.
And that is not enough. How does the fronted dev create routes? How do they create views, which are the glue between the DB and the templates?
Node.js is a runtime, not a framework. It does not have routes, views or templates at all. So that comparison makes no sense.
No matter which backend framework you choose - you will have a lot more work to bring the frontend dev into the game if you do backend rendering.
Please be aware that I am not against backend rendering. I indeed think that backend rendering is the better approach! I just explain here why there is some appeal to developers to write the backend as an API and do the rendering on the frontend.
The idea is that you prepare the needed data in the "view," and then the template should be relatively dumb. If the template is causing any database/backend requests while rendering, that's generally a sign that you haven't put enough information into your view layer.
https://docs.djangoproject.com/en/3.2/ref/class-based-views/...
This pattern seems to have declined in popularity, but it can really win in speed and simplicity over a frontend/API split.
Many small blogs are hosted in servers with pre-configured static document sharing that won't let any server-side dynamic code run beyond "Fetch the static document at path X and echo it." In that context, you either need to run a framework that will assemble your dynamic page client-side, or you need to run a script that will pre-chew your blog from some more convenient format into a rich static HTML document and post it to the server.
A remarkable number of bloggers would consider that second option a bridge too far.
* Nothing to hack except the webserver
* Fewer moving parts to break
* Fast loading
* Cachable
* No Flash of unstyled content or other client rendering anomalies which people code around
* SEO crawling without JavaScript
Edit:
Javascript free static sites.
The difference between interactive documents and applications is that users will reuse applications so they need to be snappy to leverage muscle memory. There should be no delay going to another screen, even if there's a delay in updating the data in it (due to latency) and that's where, IMO, there's a huge opportunity for improvement.
I'm ok if you want to add a bit of interactivity, but you don't need to go full SPA for that and break caching, navigation or scrolling in the process. Vanilla JS is enough, or petite-vue if you wanna get fancy.
Honestly for most sites, I just hit reader mode preemptively, especially on mobile.
Another thing I disagree with:
> On-the-fly "building" of documents is, quite literally, fixing something that is not broken.
With modern tools like Markdown converters, we can make authoring of documents far easier than hand-coding HTML, so while building documents on-the-fly is less efficient, the efficiency actually shifts to the authoring side of things, and the cost to do conversion is trivial (in fact you could do JIT conversion and cache the result on the server so that subsequent request only delivered the cached cached version).
From pov of the user on the other side the document is the result of a program, but you still open and interact with it from an application, thus we are back to the spectrum. Except with webstack we have better options to deliver a more content-optimized interface, leaving out some hoops, allowing to enhance the experience faster.
OP linked two websites as bad examples... and they both totally work, so what?
"You can even run into serious security flaws" prove it, hack it.
"you get compatibility issues" worked for me
"Web was to be a set of protocols and formats used for the purpose of publishing documents" i only use my computer to crack nazi codes.
This took me around 20 seconds to find, but I think I'll stop there :)
It's also similarly broken on my web browser. Maybe I have to pick up IE5.5 ? I ponder if that was the point .