| - 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.