I'm aware of that. My point was more about DOM changes, which is typically the reason why someone would write a JS-only web app in the first place. That's something that screen readers still handle rather poorly, as I indicated in another comment in this thread. [0]
Of course, if you've managed to address those things in fastn, then I'd be pleasantly surprised.
> You can't make a complex web-app without JavaScript
Sure you can. It might not be quite as "interactive" as you'd like, but interactivity isn't really a requirement.
Really, though, my preference is something like progressive enhancement, where the app degrades gracefully should something be missing (like Javascript). In such a context, perhaps fastn would indeed be a good fit as part of that final layer of Javascript.
> everyone has it on always.
Not true. Plenty of corporate environments block Javascript for security reasons.
Of course, it's easy to think that way. "My site is only loaded by people who have Javascript enabled, so everyone must use Javascript; never mind that my sample size might be small, or that I'm not properly logging connections where my JS blobs didn't get to run".
This isn't to mention that not all JS runtimes are equal. Safari's different from Chrome, which is different from Firefox, which is different from Opera, which is different from Internet Explorer, which is (supposedly) different from Spartan, etc.
At this point, I should note that neither of the two previous points had anything to do with the privacy rationale for turning Javascript off.
> fastn is just static files, so server time is negligible.
This assumes that there aren't delays from having to load additional files, which is an issue with HTTP/1.x (though not with HTTP/2, IIRC).
> fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times.
Yes, but that would be offset by having to actually produce the DOM client-side, would it not? It would also be offset by the performance penalty of having a bunch of Javascript running, though I admittedly haven't tested fastn on slower machines yet, so perhaps you've solved that particular problem that other JS-heavy things tend to have.
It's like saying I can download a Ruby script faster than a C source file and citing it as an example of how Ruby performs better than C.
> Initialisation time
That's not what I especially care about, since that's reasonable. My concern is with long-term performance; a Javascript-heavy page or app can easily end up pegging a CPU core or gobble memory or lock up a browser session or tab. Have you benchmarked that sort of thing and verified that fastn is consistently fast? Have you verified fastn's CPU and memory footprints?
Remember that the point of server-side things is to reduce the workload on the client. Said workload doesn't go away after initialization.
Meanwhile...
> On my old slow work PC
Define "old" and "slow". Would it be older or slower than a midrange laptop? How about a Chromebook or some other netbook-derivative? A budget smartphone or tablet (or perhaps one that was top-of-the-line two years ago)? Or perhaps one of those cheap Celeron-based desktops that the likes of Staples and Wal-Mart sell for pennies?
These categories of hardware are abundant, and yet tend to be hit the hardest with even the slightest Javascript-related performance issue.
> But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
Nah, that's just me being a bit abrasive to make a point.
Don't get me wrong; fastn looks pretty cool, and I'd definitely be inclined to use it. It's just the "abandon HTML entirely and pretend that Javascript is the end-all-be-all of web development" that rubbed me the wrong way.
