Accessibility: Screen readers read DOM, not HTML. As long as you produce good DOM, screen readers will work fine.
Privacy (JS off): You can't make a complex web-app without JavaScript, and statistically speaking, everyone has it on always.
Performance: This can be measured in may ways.
- Server time: fastn is just static files, so server time is negligible.
- Transport time: fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times. The trivial example app is 31KB, a large AWS-like application at work is about 40KB.
- Initialisation time: fastn is very fast. On my old slow work PC, the homepage loads 165ms after page ready, and its about a 700ms wait from hitting the refresh button, to everything being shown.
But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
Also, the next issue people usually have is SEO. Here is the google result for the fastn homepage, which has absolutely no HTML in the body: http://imgur.com/tZBSau8
Search engine traversal of JS-only sites is still imperfect; the problem of crawling a site that's dynamically generated from Javascript alone is probably Turing-complete :)
Accessibility: Screen readers read DOM, not HTML. As long as you produce good DOM, screen readers will work fine.
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.
- Most screen readers handle DOM updates just fine.
- I'm defining a web-app as something that feels like an application, not a website. If you are making a news site, fastn probably isn't the way to render everything. You can however just use fastn enhanced functionality, since it isn't a framework, just a tool to make chunks of UI.
- on average, 99% of users have JavaScript installed. As above, if your target audience is `literally everyone`, sure, fastn probably isn't the way to go. Having been a library developer for nearly a decade now, I am intimately aware that different browsers have differences. Fastn should work the same on all modern browsers, and if you find any bugs, let me know and I'll fix them :).
- Delays from loading additional files will be negligible. Not sure how to back that statement up tho ¯\_(ツ)_/¯
- As mentioned, rendering a fastn app on the client is very fast, faster than serving an equivalent page from ASP.net for example, even in a 1:1 race. The issue with server-side templating is that there is one server rendering N requests, whereas with client-side rendering, the N clients are doing the heavy (actually pretty light) lifting.
- I spend an enormous chunk of my time doing performance analysis and improvements. Have a look at recent commits to fastn or enti (the databinding module) and you will see quite a few commits with "performance" in them. We have non-trivial applications using fastn that perform at extremely acceptable speed (hundreds of fields, with live validation, across multiple tabs, renders in around 150ms)
- My work PC is only a few times faster than my Nexus 5. Btw, the homepage renders in 1.2s(~500ms JS) on my phone.
I hope you do give it a go. Fastn isn't a tool for every job, that's the point, it's just a tool. It's up to the developer to decide if it is appropriate.
It has been developed mostly with cordova apps in mind (and yes, they have been made with it, and are quite snappy), where abandoning HTML is actually really nice. It makes writing apps more like how you would do it native, in code, not a markup language.
- Most screen readers handle DOM updates just fine.
You sure about that? Because last I checked (and as I indicated in the linked comment), that's not actually true (at least not without some serious consideration from the app developer's side of things).
The rest of your comment, pleasantly-surprisingly, is good to hear (though I'm concerned that lower-end devices aren't getting enough attention; I know firsthand (from witnessing it with my coworkers and even with myself) how easy it is to assume that everyone has wonderful hardware and accidentally create something that readily bogs down hardware with even the slightest amount of age), and I do wish you the best of luck with this.
Comments
Accessibility: Screen readers read DOM, not HTML. As long as you produce good DOM, screen readers will work fine.
Privacy (JS off): You can't make a complex web-app without JavaScript, and statistically speaking, everyone has it on always.
Performance: This can be measured in may ways.
- Server time: fastn is just static files, so server time is negligible.
- Transport time: fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times. The trivial example app is 31KB, a large AWS-like application at work is about 40KB.
- Initialisation time: fastn is very fast. On my old slow work PC, the homepage loads 165ms after page ready, and its about a 700ms wait from hitting the refresh button, to everything being shown.
But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)
Also, the next issue people usually have is SEO. Here is the google result for the fastn homepage, which has absolutely no HTML in the body: http://imgur.com/tZBSau8
Search engine traversal of JS-only sites is still imperfect; the problem of crawling a site that's dynamically generated from Javascript alone is probably Turing-complete :)
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.
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.
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.
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).
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.
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...
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.
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.
[0]: https://news.ycombinator.com/item?id=9815655
- Most screen readers handle DOM updates just fine.
- I'm defining a web-app as something that feels like an application, not a website. If you are making a news site, fastn probably isn't the way to render everything. You can however just use fastn enhanced functionality, since it isn't a framework, just a tool to make chunks of UI.
- on average, 99% of users have JavaScript installed. As above, if your target audience is `literally everyone`, sure, fastn probably isn't the way to go. Having been a library developer for nearly a decade now, I am intimately aware that different browsers have differences. Fastn should work the same on all modern browsers, and if you find any bugs, let me know and I'll fix them :).
- Delays from loading additional files will be negligible. Not sure how to back that statement up tho ¯\_(ツ)_/¯
- As mentioned, rendering a fastn app on the client is very fast, faster than serving an equivalent page from ASP.net for example, even in a 1:1 race. The issue with server-side templating is that there is one server rendering N requests, whereas with client-side rendering, the N clients are doing the heavy (actually pretty light) lifting.
- I spend an enormous chunk of my time doing performance analysis and improvements. Have a look at recent commits to fastn or enti (the databinding module) and you will see quite a few commits with "performance" in them. We have non-trivial applications using fastn that perform at extremely acceptable speed (hundreds of fields, with live validation, across multiple tabs, renders in around 150ms)
- My work PC is only a few times faster than my Nexus 5. Btw, the homepage renders in 1.2s(~500ms JS) on my phone.
I hope you do give it a go. Fastn isn't a tool for every job, that's the point, it's just a tool. It's up to the developer to decide if it is appropriate.
It has been developed mostly with cordova apps in mind (and yes, they have been made with it, and are quite snappy), where abandoning HTML is actually really nice. It makes writing apps more like how you would do it native, in code, not a markup language.
You sure about that? Because last I checked (and as I indicated in the linked comment), that's not actually true (at least not without some serious consideration from the app developer's side of things).
The rest of your comment, pleasantly-surprisingly, is good to hear (though I'm concerned that lower-end devices aren't getting enough attention; I know firsthand (from witnessing it with my coworkers and even with myself) how easy it is to assume that everyone has wonderful hardware and accidentally create something that readily bogs down hardware with even the slightest amount of age), and I do wish you the best of luck with this.