←back to thread

463 points 8organicbits | 2 comments | | HN request time: 0.435s | 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 #
1. rchaud ◴[] No.44312535[source]
Apps need a local server to work (especially if it writes to a local database), or be shipped in some kind of executable file format for the OS. As someone who can't code native apps but is decent enough in PHP, I've discovered that the way to solve my own problem is to run a bash script that loads an Apache server, then loads the index.php file of my app, all of which is stored locally on my hard drive. Works on mobile too, although I have to manually launch an Apache server first through termux.

Modern computing badly needs the ability to support building our own local apps without a remote web server dependency. This is how computing worked in the pre-internet age. HyperCard could connect to a database as could Filemaker Pro. Windows had something similar where GUI-based apps could read/write to an Access DB. These tools have been deprecated and only live on in some subscription-based SaaS.

replies(1): >>44314197 #
2. al_borland ◴[] No.44314197[source]
PHP has its own built-in web server for local dev and testing. I tend to just use that when I need it.

cd ~/html

php -S localhost:8000