Some weeks ago, I got tired of using imgur for hosting screenshots and stuff, partially because I was trying to share work-related content and using a public site like imgur doesn't seem appropriate.
I then looked around for existing, simple self-hosting tools, but all I found where huge near-community apps like Gallery2, Coppermine, ownCloud or ownstagram (with commenting, rating, folders, tags, ...) or PHP scripts from before there was PHP 5.
Long story short: None of them fit my need, so I built my own. It's based on Silex (Symfony2's micro-framework sister) and Twig and only offers the bare minimum. Files are placed in the local filesystem, a database is not needed. Apache2 is the default supported webserver, but we have Hosty in production using nginx over SSL as well.
Uploading is only allowed for registered users (and users have to be configured in a config file), viewing is allowed to anyone having the link to a file. It's not intended to be a public file hosting service, so do not try to add some public register form or something like that ;-)
Hosty can be used inside a LAN without Internet access; no external resources are being used. It's published under MIT and deliberately doesn't add any promotional links or "Created by Hosty" footers.
Sometimes I’m missing the Good Ol’ Days. You know, when you where able to download some PHP files as a ZIP, extract them, maybe change some configuration and be done. You didn’t have to bother with a bunch of other tools just to get some script ready.
(This is, by the way, no offense to this project at all! I just couldn’t resist to write this.)
Aside from Composer (which is a good thing for managing dependencies), I'm not sure why you would think "this is how people develop and deploy PHP stuff nowadays". The author uses these tools out of choice, not convention. Just like some Ruby devs use Bower and others don't.
I agree with the other reply -- this isn't so much of an indictment of PHP, as it is front-end development in general.
Sure, to keep it simple you could download your JS and PHP deps once and bundle them all up in one nice zip. I think many apps provide a "dist" or "release" bundle (this one, in fact, does) in which you don't have to care about Composer, Bower or npm. However, to properly organize deps or define build processes for development, why not use some of the (frankly) common tools available?
It's funny how HN could see a simple unzip-and-go app and scoff "amateur hour hobby project". But if someone takes a more formal approach to their hobby app it can flip and scoff "over-engineered bloated setup".
Things got more complicated when I decided not to just use CSS/JS from some CDN, but have it locally available. Then I needed to postprocess the CSS to remove @include rules.
Most of the build process is meant to create small, versioned files, so users don't need to download full jQuery/Bootstrap stuff. I would feel bad for not optimizing my assets.
Oh, I fully agree with how you have everything set up and organized. It's clear you tried to be as formal as possible with organizing the app, it's dependencies and build processes, for _development_. People are just misunderstanding that bit or nitpicking. Like I said, it's damned if you do, damned if you don't.
Don't sweat it, people would've complained either way. Like you said earlier, it's a build requirement, not a runtime one, and there are advantages to using these tools.
For the life of me do not understand why anyone would require Node's package manager as a requirement for a PHP application.
One of the few strengths of PHP is that there doesn't have to be a "build process."
You don't even have to compile CSS and JS, really, but I guess people aren't comfortable with js or css which isn't machine generated. Fair enough - there are benefits to that, but as general practice, it's needless complexity.
> If you know a better way to install grunt-contribs, please tell me.
I would just not use grunt. I understand it's not required to run it, but even as a build dependency, unless you already have Node installed and running, it's a lot of overhead for relatively little benefit, I think.
I'm on the fence on this one. On one hand, I'm fond of package managers. On the other, there's a TON of crap every time I run bower install... I've yet to figure out the best way of doing things. I'm thinking of using bower-installer, ship with a copy of the assets, and include bower.json, but not bower_components/. The other alternative is obviously CDNs, but then you're maintaining assets manually
PHP already has a package manager though (Composer.)
Granted, the amount of friction involved depends on personal preference, and whatever environment you're working in, but why require a package manager in another language (and, potentially, the language itself) when one exists for the language you're actually deploying in?
I'm sympathetic to your point. Where I work, we use Grunt and npm for our PHP projects, and I'm in the process of replacing them (slowly but surely) with PHP-based versions of the tools we use, and replacing Gruntfiles with Makefiles. It's experimental, currently, but I feel like it's doable. The only dependency then is PHP and Composer, which I think is nice.
I include bower_components/ in .gitignore and use grunt-bowercopy[0] to move the files you actually want from bower_components/ to public/{js,css} or wherever. Files get committed once they're in public/ and I only re-run the grunt task when I want to upgrade a lib. I can understand people thinking this is overkill for a small project, but when you have dozens of libraries it's nice to have dependencies and their versions clearly defined.
>You don't even have to compile CSS and JS, really, but I guess people aren't comfortable with js or css which isn't machine generated. Fair enough - there are benefits to that, but as general practice, it's needless complexity.
23 comments
[ 483 ms ] story [ 3794 ms ] threadI then looked around for existing, simple self-hosting tools, but all I found where huge near-community apps like Gallery2, Coppermine, ownCloud or ownstagram (with commenting, rating, folders, tags, ...) or PHP scripts from before there was PHP 5.
Long story short: None of them fit my need, so I built my own. It's based on Silex (Symfony2's micro-framework sister) and Twig and only offers the bare minimum. Files are placed in the local filesystem, a database is not needed. Apache2 is the default supported webserver, but we have Hosty in production using nginx over SSL as well.
Uploading is only allowed for registered users (and users have to be configured in a config file), viewing is allowed to anyone having the link to a file. It's not intended to be a public file hosting service, so do not try to add some public register form or something like that ;-)
Hosty can be used inside a LAN without Internet access; no external resources are being used. It's published under MIT and deliberately doesn't add any promotional links or "Created by Hosty" footers.
https://github.com/MediaCrush/MediaCrush
Building your own is easy and fun, though, I don't blame you.
(This is, by the way, no offense to this project at all! I just couldn’t resist to write this.)
Is this how people develop and deploy PHP stuff nowadays?
Sure, to keep it simple you could download your JS and PHP deps once and bundle them all up in one nice zip. I think many apps provide a "dist" or "release" bundle (this one, in fact, does) in which you don't have to care about Composer, Bower or npm. However, to properly organize deps or define build processes for development, why not use some of the (frankly) common tools available?
It's funny how HN could see a simple unzip-and-go app and scoff "amateur hour hobby project". But if someone takes a more formal approach to their hobby app it can flip and scoff "over-engineered bloated setup".
Most of the build process is meant to create small, versioned files, so users don't need to download full jQuery/Bootstrap stuff. I would feel bad for not optimizing my assets.
One of the few strengths of PHP is that there doesn't have to be a "build process."
You don't even have to compile CSS and JS, really, but I guess people aren't comfortable with js or css which isn't machine generated. Fair enough - there are benefits to that, but as general practice, it's needless complexity.
I made it more obvious in the readme that you do not need build tools to run Hosty. Seems like that confused a lot of people.
I would just not use grunt. I understand it's not required to run it, but even as a build dependency, unless you already have Node installed and running, it's a lot of overhead for relatively little benefit, I think.
Granted, the amount of friction involved depends on personal preference, and whatever environment you're working in, but why require a package manager in another language (and, potentially, the language itself) when one exists for the language you're actually deploying in?
[0]: https://www.npmjs.com/package/grunt-bowercopy
You don't minify your production js?