Show HN: Fastn, a JavaScript tool for building user interfaces

http://korynunn.github.io/fastn/

by korynunn • 11 years ago

47 38 11 years ago

korynunn.github.io

mc_hammer• 11 years ago

i like this. data binding without some html hybrid. animations... nice test app. you did a lot right.

ill try this out :)

interphoal• 11 years ago

Me too! The data binding is especially nice :-).

korynunn6• 11 years ago

Huh.. Github seems to be stripping newlines from the .js sources :/.. It's 1am here, I'll fix that tomorrow.

kowdermeister2• 11 years ago

"Nothin to see here! Check out index.js"

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.

joshstrange8• 11 years ago

You mention react but it's does the same thing does it not? JSX is transformed into stuff like React.DOM.li('text', {/options/}) (<- I've only played with react and only written JSX so IDK if that's even right) which looks very similar to what is shown here.

kowdermeister2• 11 years ago

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.

finnn• 11 years ago

Mixed Content: The page at 'https://korynunn.github.io/fastn/' was loaded over HTTPS, but requested an insecure stylesheet 'http://fonts.googleapis.com/css?family=Roboto:400,300,100'. This request has been blocked; the content must be served over HTTPS.

Can we stopped with the mixed content and go full HTTPS already?

joshstrange8• 11 years ago

I don't disagree with your premise but let's not lose our shit over a demo page with mixed content. In fact HN is linking to the HTTP version which (obviously) doesn't display this warning and now even the HTTPS version is working. This was not a slight by the developer just an oversight probably left over from developing the landing page locally (which was quickly fixed).

korynunn6• 11 years ago

This should be resolved now.

keedot2• 11 years ago

I never like to criticize when someone creates something new. But decades of professional experience (having seen this concept come and go repeatedly over the years), taught me that HTML is your friend. I inherited a project that uses this concept, and there is no maintenance. Not because it's stable, but because it's more delicate than a faberge egg, so we never ever ever touch it.

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

korynunn6• 11 years ago

I've had this criticism many times in the past, but after doing exclusively JS rendered DOM for about 5 years now, I personally could never go back.

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?

keedot2• 11 years ago

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.

visarga• 11 years ago

But for any app of sufficient complexity, keep your markup out of your code

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.

yellowapple11• 11 years ago

This might be classified as a "nailgun" rather than a "framework" if the only thing I'm nailing is paper to cardboard. The whole "Nothin to see here! Check out index.js" indicates to me that this is the precise opposite of a solution to the problem of more and more sites relying exclusively on piles and piles of Javascript with zero regard for accessibility, privacy (by making the site useless for those who disable Javascript to that effect), performance, etc.

joshstrange8• 11 years ago

I'm quite stumped at the backlash against only rendering into the DOM and not sending down rendered HTML... Also, as for people who disable JS... Very bluntly: fuck them.

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.

JustSomeNobody• 11 years ago

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.

Zikes• 11 years ago

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.

roneesh• 11 years ago

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.

yellowapple11• 11 years ago

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

peterhunt• 11 years ago

Please don't spread FUD about JavaScript as a detriment to accessibility. It most certainly is not.

yellowapple11• 11 years ago

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

korynunn6• 11 years ago

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 :)

korynunn6• 11 years ago

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

yellowapple11• 11 years ago

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

fiatjaf• 11 years ago

This seems like a pain to write, and even harder to read.

What are the advantages in comparison to virtual DOM based frameworks out there?

Show HN: Fastn, a JavaScript tool for building user interfaces

Related Stories