←back to thread

463 points 8organicbits | 2 comments | | HN request time: 0.432s | 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 #
owebmaster ◴[] No.44310272[source]
Hyperclay is quite interesting, well done! But to use it we need to install an app? I think the UX of tiddlywiki that just work is better
replies(1): >>44310422 #
1. panphora ◴[] No.44310422[source]
No app installation needed, Hyperclay files are just HTML files, so they work like TiddlyWiki in that regard. You can download them and use them locally with any text editor, or even implement TiddlyWiki's saving mechanism if you prefer that workflow.

The key difference is when you want to share your creation on the web. With TiddlyWiki, you typically share a read-only version, requiring visitors to download and save their own copy. With Hyperclay, you can host that same HTML file on any server and live-edit it directly in your browser (if you're the owner). When people clone it, their clone is shareable and available on the web.

So you get the best of both worlds: the simplicity of a single HTML file that "just works" offline, plus the ability to publish it as a living document that you can edit directly in the browser.

Think of it as TiddlyWiki's philosophy extended to the shared web. Same single-file simplicity, but now your changes can be seen by others.

replies(1): >>44310627 #
2. owebmaster ◴[] No.44310627[source]
> Think of it as TiddlyWiki's philosophy extended to the shared web.

Sorry but I'm having issues seeing this as a feature. TiddlyWikis can be shared as easily as sending an attachment. Running a server, tho, is not simple at all for the common user.