
Show HN: Fastn, a JavaScript tool for building user interfaces - korynunn
http://korynunn.github.io/fastn/
======
keedot
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).

~~~
korynunn
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/](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?

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

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

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

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

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

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

ill try this out :)

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

------
finnn
Mixed Content: The page at
'[https://korynunn.github.io/fastn/'](https://korynunn.github.io/fastn/') was
loaded over HTTPS, but requested an insecure stylesheet
'[http://fonts.googleapis.com/css?family=Roboto:400,300,100'](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?

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

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

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

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

~~~
joshstrange
While I agree in concept in reality this is normally not possible. For a
company like Google? Sure but for most companies out there they just aren't
going to have the developer and QA resources to continuously test both JS and
no-JS flows. For banks? Yes they can probably support both but honestly banks
will probably move to MORE js to thwart fraud as in making sure you are a real
person based on our mouse movements or other things. As for news sites, 10000%
they should work without JS, the printed word is their bread and butter (even
with some place coming up with more interactive news stories) so they should
have no trouble supporting no-js browsers. There is a fear that they may just
say "fuck you" to non-js people though if it significantly affects their
advertizing (Lack of tracking or dynamic ad injection).

~~~
yellowapple
There's a good article on progressive enhancement (which is, alongside / in
addition to graceful degredation, what's usually referred to when one talks
about JS/non-JS hybrid flows) that addresses the cited pain points and
"myths". [0] The claim that PE is "twice the effort" is directly addressed;
basically, it's not twice the effort at all if one actually designs one's app
to support PE/GD from the start (or otherwise starts with bare server-
generated HTML and adds on layers of interactivity from there).

[0]: [http://www.sitepoint.com/javascript-dependency-backlash-
myth...](http://www.sitepoint.com/javascript-dependency-backlash-myth-busting-
progressive-enhancement/)

------
fiatjaf
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?

