Show HN: Fastn, a JavaScript tool for building user interfaces (opens in new tab)

This library is clearly intended to create dynamic and interactive interfaces, too. If you've got JS disabled, whatever you build with it wouldn't work if you built it with literally any other JS framework or library anyways.

There's no more reason for people to get angry over this JS library than there is to get angry over jQuery, Angular, React, or anything else people have been using to build fully functional products on the internet for years.

In my opinion, most sites should at least maintain a core subset of functionality that can work without JS. Sites existed before JS that let people read news and engage in commerce, there's no reason we should lose all that.

Also, as we now enter a future where billions of people who never used a desktop computer begin mobile banking, being able to conduct business without JS might be one avenue to combat fraud.

When a web site takes over 10 seconds to load and elements are jumping all over the place as things are rendered, the first thing I'll try is disable Javascript. Next I just say hell with it and not visit the site.

So... fuck you.

> If you think that's an easy thing to do then you've either never done it or the web app your were working on didn't deserve to be called a web app.

I actually do this on a daily basis as my dayjob. If you're using a proper server-side framework, this is quite trivial.

Of course, I already expect you'll retort with some half-assed no-true-Scotsman ("well your web apps aren't real web apps!"), in which case I'd likely ask for your definition of "web app", why said definition is unattainable without creating some Javascript-only monstrosity, and why said monstrosity isn't implemented instead as a native application if it really does go beyond what a more sane use of HTML/CSS/JS/some-server-side-scripting can offer.

> if screen readers can't handle JS client-side rendering it's the readers then need to change not the web.

And how would you go about implementing that? A text-to-speech interface isn't like a visible webpage, where you can easily scroll around and jump from thing to thing and notice that some random DOM element has changed. Perhaps the screenreader could read newly-created DOM elements, but that'll become really annoying for elements that frequently change/disappear/reappear, as is often the case for web apps of the variety that you advocate.

This isn't to mention that not all screenreaders are auditory. Quite a few blind computer users use braille displays. How will your web app work with such displays? How will it work with a keyboard and no mouse (since what good is a mouse pointer if you can't see the pointer on the screen)? Or is your answer to just say "fuck them"?

> It would be like taking away C from your computer, the whole thing comes crashing down.

That's not quite true (and, in fact, is rather amusing in this day and age of C-ABI-compatible languages like Rust being the latest hot shit). Plenty of operating systems are written in languages other than C, and it's very much possible to have a computer without any C code at all. Hell, even with C, removing C won't do a whole lot; the computer is executing compiled machine code, not trying to run C directly.

---

In my opinion, rendering into the DOM exclusively is just as much an affront to the concept of a "semantic" web as using HTML tables for creating a page layout. Save the Javascript for things that actually need interaction; for everything else, plain HTML is not only sufficient, but even superior, since it's less likely to break on some confounding variable like whether I'm using Chrome or Firefox (or, god forbid, Internet Explorer) or whether I'm blind and my screen reader doesn't readily handle elements flying in and out of existence at arbitrary points in time.

That's the point of the "semantic" web, after all: HTML for content, CSS for presentation, Javascript for interaction. Just because breaking away from that is popular doesn't mean it's a smart thing to do.

This isn't to say that such behavior is always unacceptable, of course; there are web apps that do JS-only things rather well (Trello, for example). That tends to be the case when a JS-only approach is absolutely necessary. 99% of the time, however, HTML would be more than sufficient, with maybe some Javascript here and there to make things prettier. For the remaining 1%, a public API would do wonders for those seeking to build more accessible clients, in which case the web app being JS-only wouldn't be quite as much of a problem.

Of course, at least Trello has a warning in <noscript>...</noscript> tags telling users to enable Javascript. The bit of HTML my comment responded to didn't even have that courtesy.

Your viewpoint would be more acceptable if Javascript weren't the sluggish and fragile pile of shit it currently is and has been throughout the entirety of its existence. Until that core problem is fixed, the backlash will continue, and the fuck-you will be mutual.

---

EDIT: to further clarify my approach, I'd be totally fine with something like progressive enhancement [0], which is arguably much more robust than relying on JavaScript existing. Web apps do, after all, have a tendency to break rather horribly even between modern browsers, let alone slightly-outdated ones; having some defense against that is the responsible thing to do.

[0]: http://www.sitepoint.com/javascript-dependency-backlash-myth...

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

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

[0]: https://news.ycombinator.com/item?id=9815655

Javascript in and of itself isn't a detriment, but many of its uses are. That's not FUD, that's reality. If we're going to charge right into this Web 2.0 future of Javascript-only doodads, then there are a multitude of things which need to be considered, like "will a screen reader properly handle my JQuery popups?" [0] or "will a screen reader properly identify a DOM update and read it? [1] or "will a screen reader handle my password dialog in a secure manner?" [2]. And these are all with basic, HTML + bits-of-JS pages, let alone a full-on JS-only web app.

That second article makes an excellent point, by the way: that the concept of "interactivity" usually sought after might very well be a biased view of what an ideal interface should look like. Interactivity means different things to different users, and in the same vein can be either a blessing or a curse; it isn't a magical universal solution to all the world's problems.

[0]: http://stackoverflow.com/questions/18475332/screen-reader-jq...

[1]: http://www.sitepoint.com/ajax-screenreaders-work/

[2]: http://www.sitepoint.com/show-password-javascript-accessibil...

I think it's great that you created something that you find useful and works for you, and continue to create it after receiving negative criticism. I also think it's great that you're putting it out there, and wish you well with it. I'll end with that, as I don't want to be harsh or overly critical.

Not entirely the same. React forces the template into a single render function. In this case the whole code is about element rendering. Presentation layer generating code can be anywhere, that's why I think it's messy.

Of course some might like it for some use cases.