8 ms·

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

47 points by korynunn 11y ago

mc_hammer 11y ago
i like this. data binding without some html hybrid. animations... nice test app. you did a lot right. ill try this out :)
- interphoal 11y ago
  Me too! The data binding is especially nice :-).
korynunn 11y ago
Huh.. Github seems to be stripping newlines from the .js sources :/.. It's 1am here, I'll fix that tomorrow.
kowdermeister 11y 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.
- joshstrange 11y 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.
  - kowdermeister 11y 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 11y ago
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?
- deleted 11y ago
  [deleted]
- joshstrange 11y 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).
- korynunn 11y ago
  This should be resolved now.
keedot 11y 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).
- korynunn 11y 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/ 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 11y 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 11y 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.
yellowapple 11y 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.
- joshstrange 11y 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 11y 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.
fiatjaf 11y 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?

47 points by korynunn 11y ago

i like this. data binding without some html hybrid. animations... nice test app. you did a lot right. ill try this out :)

interphoal 11y ago
Me too! The data binding is especially nice :-).

korynunn 11y ago

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

kowdermeister 11y 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.

joshstrange 11y 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.
- kowdermeister 11y 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 11y ago

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?

deleted 11y ago
[deleted]
joshstrange 11y 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).
korynunn 11y ago
This should be resolved now.

keedot 11y 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).

korynunn 11y 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/ 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 11y 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 11y 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.

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

joshstrange 11y 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 11y 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.

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