9 ms·

Documents ≠ Programs

100 points by adriangrigore 5y ago

tyingq 5y ago
I see quite a few blogs and informational sites with this described setup where the base html has none of the content and everything is client-side rendered. I'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)
- ktpsns 5y ago
  It's called "single page application" and my guess is the most reason is "responsiveness" (which is however not true, you can lazy load anything with traditional HTML and a few lines of JS) and "smooth" transitions from one "virtual" page to the other. Honestly I never understood this trend. From a developer side, the engineering easily costs two times compared to a traditional site.
  - nerdponx 5y ago
    It's also usually a lot less responsive for something as simple as a blog. It makes sense for complicated text/media hybrid pages with animations, embedded images and video, etc. 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.
    - KronisLV 5y ago
      > It's also usually a lot less responsive for something as simple as a blog. 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/ 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-server-side-rendering 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.
      - timw4mail 5y ago
        I've come to think that such performance increases, if they exist, are not worth the amount of effort compared to a much simpler sever-side render. 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.
      - Karrot_Kream 5y ago
        Svelte [1] is a framework that's all about trying to make interactivity viz. JS a lighter process. It pre-compiles all the code so there's no shadow DOM or similar stuff going on. [1]: https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity
  - BiteCode_dev 5y ago
    > the engineering easily costs two times 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!
    - zinekeller 5y ago
      > At first. 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.
- ArtTimeInvestor 5y ago
  It has a certain appeal to developers because it makes separation of concerns easier. 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.
  - BiteCode_dev 5y ago
    Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed. 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...
  - tyingq 5y ago
    I suppose, but it wouldn't be that different to then render that on the server side instead of the browser.
    - ArtTimeInvestor 5y ago
      How so? 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"?
      - tyingq 5y ago
        If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?
- shadowgovt 5y ago
  Usually, I see it done when the blog owner doesn't have a robust server or the savvy to run some shell scripts. 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.
literallyaduck 5y ago
JavaScript free Static sites are great for many reasons: * 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.
- pwdisswordfish8 5y ago
  "Static sites" usually refer to a websites where the server is not servicing application requests because all resources are flat files precomputed ahead of time, not websites with no JS. Basically what you can get by opening files directly from disk. A site consisting of index.html and the gnarliest 10+ MB app.js bundle would still be considered a static site. Similarly, flash of unstyled content is a completely orthogonal issue. (In fact, FOUC is arguably most likely to be encountered on static sites, because the hosts they're on are usually chosen because they offer cheap/simple setup. So neither server performance nor the speed of rendering on the client for the HTML+CSS combo that the author goes with are necessarily given much attention.)
KronisLV 5y ago
Personally, i agree with many of the claimed benefits of server side rendering or focusing on static content. In my opinion, a web that would be closer to linked documents of the old days and would also use regular forms more liberally would probably be far more simpler and user friendly, than the bloated and highly interactive sites that we see nowadays. 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 https://idlewords.com/talks/website_obesity.htm
enobrev 5y ago
I don't think the comparison between documents and applications is anywhere near as interesting as _why_ we've collectively decided to tie ourselves into knots to create applications out of documents over the past few decades. 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.
- Frost1x 5y ago
  >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.
BiteCode_dev 5y ago
100% agree, and a LOT of websites out there are glorified documents. 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.
ho_schi 5y ago
JavaScript has it benefits, live updates and interaction! I'm programming myself with it because I have to do so. But the current usage of JavaScript is driven by cost savings and manipulating users and not actual technical needs. I blame especially Mozilla, that they didn't stop that early. The removal of the option to turn off JavaScript from the GUI was wrong. 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.
terracottage 5y ago
The separation between documents and programs assumes we know ahead of time all the things people might want to put inside a document. The evolution of the web shows this not to be true. 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.
- chubot 5y ago
  Yeah very good example -- a map is a program and is usefully embedded in documents. Also this series of pages was extremely popular on HN, and can't be done without programs embedded in documents: https://ciechanow.ski/gears/ https://ciechanow.ski/gears/ In this case it's done quite "literally" ! https://ciechanow.ski/js/gears.js 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.
- pbronez 5y ago
  I agree. The reason it seems like web standards are always “behind where we should be by now” is mostly a coordination problem, with some prognostication error. To work seamlessly, we have to agree on what the standard should be and implement it well, broadly, and consistently. That’s always going to be slow and patchy. 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.
scoopdewoop 5y ago
I am getting so burnt out on the condescending 'old guard'. I have no time for graybeard curmudgeons. 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.
- scbrg 5y ago
  Well, https://slc.is/ https://slc.is/ for instance, doesn't actually work. If I go there, and then click the back button, I get Error Page Not Found. An Error Page Not Found which isn't even a 404, because that would obviously have been to conformant. This took me around 20 seconds to find, but I think I'll stop there :)
- AshamedCaptain 5y ago
  I actually find the entire layout of that website eerily similar to FrontPage templates from the late 90s. It's also similarly broken on my web browser. Maybe I have to pick up IE5.5 ? I ponder if that was the point .
cwizou 5y ago
I thought this was gonna be about how we've been tying data or documents in native mobile apps to their program of origin, making the use of several apps on a same document very complicated (or importing data from other apps). iOS went all hog on this and it's been a pain for "pro" workflows. 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] [1] : https://www.w3.org/People/Raggett/book4/ch02.html https://www.w3.org/People/Raggett/book4/ch02.html
- emaro 5y ago
  > 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? 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).
  - cwizou 5y ago
    That's a very fair point, I guess I skipped over that part, my bad. 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.
emaro 5y ago
I agree with the author in general. I think the web would benefit from a better distinction of documents and the web. However it is not that easy, because there are valid in-betweens, like Jupyter notebooks. Therefore I'd prefer a real progressive web over a document web and a app web. Do the fancy features, but also make sure your site works in a very simple environment. 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.
javier10e6 5y ago
One well written document can spin out many programs. One well written program cannot spin out a well written document. Is up to savvy developers and ultimately a computer to give thumbs up to a program. A document on the other hand has a subjective bar for approval. When documents and programs clash (the program not doing exactly what the document asks), to people's chagrin, the program wins.
tiborsaas 5y ago
I like his app very much, nice and clean.
curryst 5y ago
> Furthermore, you're recreating functions of the browser almost immediately. There is no need to do that. The user is already running a program that can do everything your code does faster. All you have to do is put the content in the right format and it's all handled for you. 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.
- mckinley_ 5y ago
  I think you're dismissing static site generators too quickly. An efficient static site generator will work very well for a lot of websites, because most of them aren't made up of >1,000 pages. 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.
slightwinder 5y ago
Interface-wise, a document is a static application and an application is just a dynamic document. In the flat 2d-world of computers they both are opposite ends of a spectrum and it's somewhat natural to move on this spectrum from one side to the other depending on your requirements and circumstances. 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.
gambler 5y ago
"An idiot admires complexity, a genius admires simplicity." 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.
deleted 5y ago
[deleted]
bsedlm 5y ago
and nouns aren't verbs (actions) yet both are words?
- jonnycomputer 5y ago
  wait until I noun and verb you with my thesaurus attack.
juancampa 5y ago
Broadly speaking, there are 3 types of media web: documents, interactive documents, applications. The Web is great for the first two and not so great for the last one. 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.
kixiQu 5y ago
The author cites two examples of "unnecessary complexity on websites." 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 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.
- barryf 5y ago
  Thanks, kixiQu. I'm the author of the linked post and I enjoyed - and agreed! - with much of the thinking behind the original article. I'd use a static site generator in a normal use case, but I think it's fine to experiment on my own site.
- mckinley_ 5y ago
  I'll admit I was a bit too harsh about it. I saw an opportunity to use a Terry Davis quote and took it. 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.
mckinley_ 5y ago
Hey, I wrote this! I guess now's as good a time as any to make an account. I wasn't very happy with this one when I uploaded it, but I didn't want another file in the blog graveyard.
jl6 5y ago
Obligatory link to Gemini which needs to be posted in every HN thread where people complain about the complexity of the web: https://gemini.circumlunar.space/ https://gemini.circumlunar.space/
temporallobe 5y ago
This is vastly oversimplifying the concept of a “document”. Many times, documents have dynamic content, and therefore must be processed through some kind of controller back-end. 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).

100 points by adriangrigore 5y ago

I see quite a few blogs and informational sites with this described setup where the base html has none of the content and everything is client-side rendered. I'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)

ktpsns 5y ago
It's called "single page application" and my guess is the most reason is "responsiveness" (which is however not true, you can lazy load anything with traditional HTML and a few lines of JS) and "smooth" transitions from one "virtual" page to the other. Honestly I never understood this trend. From a developer side, the engineering easily costs two times compared to a traditional site.
- nerdponx 5y ago
  It's also usually a lot less responsive for something as simple as a blog. It makes sense for complicated text/media hybrid pages with animations, embedded images and video, etc. 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.
  - KronisLV 5y ago
    > It's also usually a lot less responsive for something as simple as a blog. 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/ 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-server-side-rendering 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.
    - timw4mail 5y ago
      I've come to think that such performance increases, if they exist, are not worth the amount of effort compared to a much simpler sever-side render. 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.
    - Karrot_Kream 5y ago
      Svelte [1] is a framework that's all about trying to make interactivity viz. JS a lighter process. It pre-compiles all the code so there's no shadow DOM or similar stuff going on. [1]: https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity
- BiteCode_dev 5y ago
  > the engineering easily costs two times 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!
  - zinekeller 5y ago
    > At first. 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.
ArtTimeInvestor 5y ago
It has a certain appeal to developers because it makes separation of concerns easier. 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.
- BiteCode_dev 5y ago
  Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed. 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...
- tyingq 5y ago
  I suppose, but it wouldn't be that different to then render that on the server side instead of the browser.
  - ArtTimeInvestor 5y ago
    How so? 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"?
    - tyingq 5y ago
      If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?
shadowgovt 5y ago
Usually, I see it done when the blog owner doesn't have a robust server or the savvy to run some shell scripts. 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.

literallyaduck 5y ago

JavaScript free Static sites are great for many reasons: * 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.

pwdisswordfish8 5y ago
"Static sites" usually refer to a websites where the server is not servicing application requests because all resources are flat files precomputed ahead of time, not websites with no JS. Basically what you can get by opening files directly from disk. A site consisting of index.html and the gnarliest 10+ MB app.js bundle would still be considered a static site. Similarly, flash of unstyled content is a completely orthogonal issue. (In fact, FOUC is arguably most likely to be encountered on static sites, because the hosts they're on are usually chosen because they offer cheap/simple setup. So neither server performance nor the speed of rendering on the client for the HTML+CSS combo that the author goes with are necessarily given much attention.)

KronisLV 5y ago

Personally, i agree with many of the claimed benefits of server side rendering or focusing on static content. In my opinion, a web that would be closer to linked documents of the old days and would also use regular forms more liberally would probably be far more simpler and user friendly, than the bloated and highly interactive sites that we see nowadays. 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 https://idlewords.com/talks/website_obesity.htm

enobrev 5y ago

I don't think the comparison between documents and applications is anywhere near as interesting as _why_ we've collectively decided to tie ourselves into knots to create applications out of documents over the past few decades. 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.

Frost1x 5y ago
>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.

BiteCode_dev 5y ago

100% agree, and a LOT of websites out there are glorified documents. 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.

ho_schi 5y ago

JavaScript has it benefits, live updates and interaction! I'm programming myself with it because I have to do so. But the current usage of JavaScript is driven by cost savings and manipulating users and not actual technical needs. I blame especially Mozilla, that they didn't stop that early. The removal of the option to turn off JavaScript from the GUI was wrong. 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.

terracottage 5y ago

The separation between documents and programs assumes we know ahead of time all the things people might want to put inside a document. The evolution of the web shows this not to be true. 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.

chubot 5y ago
Yeah very good example -- a map is a program and is usefully embedded in documents. Also this series of pages was extremely popular on HN, and can't be done without programs embedded in documents: https://ciechanow.ski/gears/ https://ciechanow.ski/gears/ In this case it's done quite "literally" ! https://ciechanow.ski/js/gears.js 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.
pbronez 5y ago
I agree. The reason it seems like web standards are always “behind where we should be by now” is mostly a coordination problem, with some prognostication error. To work seamlessly, we have to agree on what the standard should be and implement it well, broadly, and consistently. That’s always going to be slow and patchy. 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.

scoopdewoop 5y ago

I am getting so burnt out on the condescending 'old guard'. I have no time for graybeard curmudgeons. 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.

scbrg 5y ago
Well, https://slc.is/ https://slc.is/ for instance, doesn't actually work. If I go there, and then click the back button, I get Error Page Not Found. An Error Page Not Found which isn't even a 404, because that would obviously have been to conformant. This took me around 20 seconds to find, but I think I'll stop there :)
AshamedCaptain 5y ago
I actually find the entire layout of that website eerily similar to FrontPage templates from the late 90s. It's also similarly broken on my web browser. Maybe I have to pick up IE5.5 ? I ponder if that was the point .

cwizou 5y ago

I thought this was gonna be about how we've been tying data or documents in native mobile apps to their program of origin, making the use of several apps on a same document very complicated (or importing data from other apps). iOS went all hog on this and it's been a pain for "pro" workflows. 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] [1] : https://www.w3.org/People/Raggett/book4/ch02.html https://www.w3.org/People/Raggett/book4/ch02.html

emaro 5y ago
> 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? 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).
- cwizou 5y ago
  That's a very fair point, I guess I skipped over that part, my bad. 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.

emaro 5y ago

I agree with the author in general. I think the web would benefit from a better distinction of documents and the web. However it is not that easy, because there are valid in-betweens, like Jupyter notebooks. Therefore I'd prefer a real progressive web over a document web and a app web. Do the fancy features, but also make sure your site works in a very simple environment. 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.

javier10e6 5y ago

One well written document can spin out many programs. One well written program cannot spin out a well written document. Is up to savvy developers and ultimately a computer to give thumbs up to a program. A document on the other hand has a subjective bar for approval. When documents and programs clash (the program not doing exactly what the document asks), to people's chagrin, the program wins.

tiborsaas 5y ago

I like his app very much, nice and clean.

curryst 5y ago

> Furthermore, you're recreating functions of the browser almost immediately. There is no need to do that. The user is already running a program that can do everything your code does faster. All you have to do is put the content in the right format and it's all handled for you. 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.

mckinley_ 5y ago
I think you're dismissing static site generators too quickly. An efficient static site generator will work very well for a lot of websites, because most of them aren't made up of >1,000 pages. 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.

slightwinder 5y ago

Interface-wise, a document is a static application and an application is just a dynamic document. In the flat 2d-world of computers they both are opposite ends of a spectrum and it's somewhat natural to move on this spectrum from one side to the other depending on your requirements and circumstances. 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.

gambler 5y ago

"An idiot admires complexity, a genius admires simplicity." 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.

deleted 5y ago

[deleted]

bsedlm 5y ago

and nouns aren't verbs (actions) yet both are words?

jonnycomputer 5y ago
wait until I noun and verb you with my thesaurus attack.

juancampa 5y ago

Broadly speaking, there are 3 types of media web: documents, interactive documents, applications. The Web is great for the first two and not so great for the last one. 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.

kixiQu 5y ago

The author cites two examples of "unnecessary complexity on websites." 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 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.

barryf 5y ago
Thanks, kixiQu. I'm the author of the linked post and I enjoyed - and agreed! - with much of the thinking behind the original article. I'd use a static site generator in a normal use case, but I think it's fine to experiment on my own site.
mckinley_ 5y ago
I'll admit I was a bit too harsh about it. I saw an opportunity to use a Terry Davis quote and took it. 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.

mckinley_ 5y ago

Hey, I wrote this! I guess now's as good a time as any to make an account. I wasn't very happy with this one when I uploaded it, but I didn't want another file in the blog graveyard.

jl6 5y ago

Obligatory link to Gemini which needs to be posted in every HN thread where people complain about the complexity of the web: https://gemini.circumlunar.space/ https://gemini.circumlunar.space/

temporallobe 5y ago

This is vastly oversimplifying the concept of a “document”. Many times, documents have dynamic content, and therefore must be processed through some kind of controller back-end. 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).