Skip to content

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

Comments

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

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?

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.

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.