←back to thread

463 points 8organicbits | 1 comments | | HN request time: 0.253s | source
Show context
al_borland ◴[] No.44308824[source]
I like the spirit of it, but the execution isn't what I'm looking for. With this being a hosted solution, it makes me dependent on another SaaS tool for little personal projects. If it's a little counter needed for an afternoon, that's not such a big deal. However, if I'm looking for a scrappy little app I may use for years, this is a problem. Plus, no matter how low the learning curve gets, it will still exist, so I want something that I can use for the long term for things like this. This makes my mind go to approachable and easy languages that allow the user to easily throw a GUI on it. I don't think code needs to be completely abstracted away, just made easy and tailored to what people will do. Look at how many people on MySpace were able to learn some CSS. Maybe they copy and paste someone else's stuff at first, but that's the foot in the door before they eventually look at how to tweak it.

I typically end up using basic HTML/CSS/JS for stuff like this today. If I really need backend code, I'll use basic PHP (no frameworks or anything). But this ties me to a browser, which I'm not always a fan of. Some of these fairly scrappy little projects at work (done in the browser like this, and with AutoHotKey) have been going for 10+ years now, with very little maintenance. The AHK script I haven't touched in probably 8 years, since I moved to macOS at work, yet people still use it countless times per day. If AHK decides to stop operating, it's no big deal, the code that exists will still run. The same can't be said for these SaaS solution to this problem. People looking for scrappy solutions aren't looking to remake their solution every time a founder decides to move on to something else more interesting or profitable.

replies(6): >>44309092 #>>44310041 #>>44310325 #>>44310762 #>>44311079 #>>44313560 #
slightwinder ◴[] No.44310041[source]
This looks like something that should be done like a TiddlyWiki. A TiddlyWiki is a whole Webapplication in a single HTML-File. Traditionally, when you change something, you just save the HTML-File and it self-replicates with the new data. There are now also TiddlyWikis which can save to backends and probably some other ways.

Building a whole platform around self-replicating HTML-files with optional backend-access seems to be the more reliable solution for small personalized stuff. At least it has a strong resilience.

replies(3): >>44310115 #>>44310185 #>>44312535 #
panphora ◴[] No.44310115[source]
I'm building a self-modifying HTML runtime inspired by TiddlyWiki [0]. It lets you build "HTML apps" in a single file with plain CSS/JS. These apps are shareable and hostable, but you can also download and use them locally as offline apps [1].

The cool thing is each HTML file is able to modify/overwrite itself, so users can use the app's own UI to modify it (e.g. a dashboard where users can add new fields by clicking a button to clone a DOM node, everything's persisted).

The key insight: collapsing the UI/state/logic layers into a single self-contained HTML file eliminates entire categories of complexity - no build steps, no deployment, no state synchronization. Everything you need is just right there.

[0] https://hyperclay.com/

[1] https://hyperclay.com/hyperclay-local

replies(3): >>44310272 #>>44310814 #>>44316898 #
1. dmwilcox ◴[] No.44316898[source]
It looks cool. Two quick things: - the pricing page is an unstyled 404 right now - the docs subdomain requires javascript to display at all which is fine I guess but odd because the examples are viewable without javascript enabled

Otherwise really interesting, thanks for sharing!