Show HN: Fastn, a JavaScript tool for building user interfaces
korynunn.github.io
korynunn.github.io
I'm sure for some small projects with very infrequent layout changes, this could be nice to work with. But for any app of sufficient complexity, keep your markup out of your code be it through DOM construction or in string HTML. (React being the one implementation that MAY prove to be the exception to prove the rule, though it's too early to tell at this point).
I write large-scale web front-ends as my day-job, they used a number of tools, but the one thing in common is the HTML-free approach. It creates much more manageable codebases, encourages reusability, allows for easy composition, and massive flexibility.
You mention that you "don't touch it" due to decades of experience. Have a look at the example app (https://github.com/KoryNunn/fastn/blob/gh-pages/example/) as an example of app structure. Yes, it's a trivial example, but it's not really that different to the non-trivial apps I build at work.
Maybe it's time to give it a go again?
I'd rather divide the app into components, each one with its own HTML, CSS and JS, plus the AJAX handlers on the server.
Simply separating HTML from JS is not enough. I remember having to hunt a lot from file to file when I was using jQuery to build websites, because the HTML was in one file, the JS was in completely other file. It wasn't efficient.
I think the declarative approach here, which seems inspired from ReactJS is the nicest. I don't ever want to write direct HTML any more. I prefer to use a fully developed language to declare the page. In such a language you can use repetition, functions and variables to express your markup in a smarter way.
Bad sign for me. There's many valid reasons to have a markup available for we applications. Embedding layout this deep into code is just messy for me. The best acceptable way (for me) so far is React.
Of course some might like it for some use cases.
ill try this out :)
Can we stopped with the mixed content and go full HTTPS already?
Are there security concerns at running JS? Sure, but you can't take away a HUGE building block of the web and expect everything to just work. It would be like taking away C from your computer, the whole thing comes crashing down. This and frameworks like this are normally for building interactive interfaces and/or full web apps which (let's all say this together) ARE NOT POSSIBLE WITHOUT JAVASCRIPT. PERIOD. The web is a constantly moving target and if frameworks like this break accessibility then maybe accessibility tools need to be re-written/updated to handle client-side rendering (which is where the web is largely going, optionally with an initial render on the server side).
If we are talking about a blog then sure, needing JS is just stupid, my blog works just fine with or without JS but if I'm building a web app there is no way I can reasonably deliver both a cutting edge JS web app AND a static, submit-the-page-to-do-anything app. 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 hear this shit from people all the time about how you "don't need JS"... Sure you don't need JS just like you don't need users which is where you will be if you deliver a shitty non-interactive website.
TL;DR: People not using JS are simply not worth the effort to support and if screen readers can't handle JS client-side rendering it's the readers then need to change not the web. It's simply unreasonable to expect all web developers to account for every single edge case. Taking away JS is taking away one of the building blocks of the web and is a BAD idea.
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.
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.
[0]: http://www.sitepoint.com/javascript-dependency-backlash-myth...
So... fuck you.
> If we are talking about a blog then sure, needing JS is just stupid, my blog works just fine with or without JS but if I'm building a web app there is no way I can reasonably deliver both a cutting edge JS web app AND a static, submit-the-page-to-do-anything app.
You clearly haven't used very many of these "web APPS" you champion, then.
I'd say that a hefty chunk (if not a majority) of "Show HNs" involving Javascript-heavy anything are riddled with bugs, among said bugs being elements moving around as others load. It's just like web pages in the 90's; for every excellent and well-known app, there tend to be several mangled ones.
EDIT: come to think of it, DuckDuckGo (which I otherwise absolutely love) is a good example of what's being referred to; some elements (particularly for instant answers and "sponsored" results) take longer to load than the search results, and I've found myself frequently clicking the wrong link because of my intended link shifting down without warning. This was especially prevalent prior to the recent redesign (nowadays it seems to be less of a problem).
While maybe this doesn't fit your definition of "web app", it's still relatively JS-heavy by default (though DDG is also an excellent example of progressive enhancement / graceful degradation) and is a decent demonstration of web-app-like concepts (and, in my belief, fits the actual definition of "interactive web app" quite well).
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...
What framework are you using that allows you to design interactive web apps without JS?
>> 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"?
So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
>> 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.
When I saw "C" I just meant "basic building block" of which rust is. JS is the only "language" of the web other than something like NPAPI which google is phasing out. Now there is P/NaCL but that's not widely used AFAIK or at least it's not used for building something like a web app, it's more for games. Pretty much: yes you can get by without C but it's because you can always fall back to assembly, the same is not true for the web.
----
Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS. This is what I'm advocating JS framework use for. As for a blog/news it's fine if they use a JS framework as long as they can fall back to a non-js page or render the js page on the server side (this only works for non-interactive sites).
Just to give you an idea of where I'm coming from, at my $dayJob I work on a large non-public web app that uses popups, sortable tables, live-updating tables of data, interactive google maps, interactive calendars, and more. For this it's simply not possible to not use JS (even though some people still pretend it is because "We didn't use JS from the start and it worked fine" ... no, it didn't. In fact we had to add JS because clients complained and they keep asking for higher and higher levels of interactivity with the web app which require more and more JS.
This is a Rails consultancy, so... Rails. We use Foundation for most things view-side (which, admittedly, involves some Javascript, but only for certain parts; said parts aren't used very often), but pretty much all the heavy lifting is done controller-side. We do like using AJAX here and there, mind you, but only when actually necessary.
Sure, it ain't Trello with its drag-and-drop doodads and such, but we've built plenty of rather excellent web apps without such gizmos. That degree of interactivity isn't strictly necessary, and - in fact - can often be a distraction.
For my personal projects, I've mostly been using Elixir lately (with the Sugar framework), and Pure instead of Foundation for CSS-related things.
> So how do screenreaders handle jQuery? Because at the end of the day React and jQuery manipulate the DOM in the same way. React renders to a virtual DOM then diff's that with it's representation of the real DOM and applies only that diff in the same way you might do $('#myElement').css('color', 'red); Some frameworks like angular even have modules specially for screenreaders (https://docs.angularjs.org/api/ngAria).
Not as well as you'd think.
Screenreaders do read the DOM rather than directly from HTML documents, so a JS-only site that's otherwise static wouldn't have very many problems in all likelihood. The problems arise when the DOM is manipulated; screenreaders (including Aria) have tended to have rather pessimal behavior when encountering things like JQuery popups (for example), whether that means failing to read the popup entirely, reading only part of it, reading only an "OK" button, reading it but then reading everything after it even if said everything has already been read, etc. I mentioned these things in another comment on this thread [0].
This isn't to mention that JS-only apps tend to be very mouse and touch heavy. This is a non-starter for most blind users, who AFAIK tend to be very keyboard-centric.
> Trello is a perfect example of what I would consider a "web app", it's simply not possible to recreate without JS.
Maybe not exactly, but all its functionality is arguably possible without any Javascript whatsoever.
Let's start with moving cards between lists. Currently, one has to drag-and-drop. There's little reason why that can't instead be implemented as left/right arrow buttons on each card, each resulting in a POST to the server telling it to move the card with the specified ID to the next list in whichever direction. The server then updates the card on its end and sends back the updated HTML.
Then, there's the reordering of cards. Again, totally possible; just put up/down arrow buttons on each card. Same deal as before; server performs the reorder and sends back the result.
For adding cards to lists (and adding new lists to boards), there are already links present to do those things; making them do the same thing as above (leave all the processing to the server, which then sends back the updated HTML) would work quite alright.
You then have the side menu. The pop-out would indeed be impossible without Javascript, but its functionality wouldn't; the "Add Members..." button could point to a separate member add page (or be replaced with the current result of clicking that button, which is simply a text box prompting for an email address to search for), while the member list and the activity feed can easily be rendered server-side.
Same story for the individual list menus; the pop-out requires Javascript, but the rest is trivial to render server-side as part of the list's div.
Then we have the card screen, which can easily be its own page. Like above, pretty much everything here can be done without Javascript with very little workflow difference - comments, labels, checklists, attachments, you name it. All the buttons you see on the right of the card window in current Trello can easily direct to screens for creating each thing.
Now, perhaps the above hypothetical no-JS Trello isn't as "interactive" as you'd like, but it would already be far more accessible, relying less on DOM updates and drag-and-drop operations while being much friendlier to keyboard users and - in all likelihood - performing just as well if not better (even with page loads factored in). And, of course, this would be a perfect candidate for progressive enhancement, layering Javascript on top of the HTML-only layer in order to add the more "interactive" things like drag-and-drop and popout menus and working as a "single-page" app.
I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.
I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.
> I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost?
None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.
> It's simply not worth the resources
It costs resources if it's not something you consider right from the get-go.
In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.
> "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.
I agree with this. That doesn't mean that the existence of Javascript can always be assumed.
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 :)
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.
- 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.
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...
What are the advantages in comparison to virtual DOM based frameworks out there?