Can i just say that clearly everyone knows its not the best tool for an actual serious project, but theres nothing wrong with whimsy. Its fun to do things because you can, that doesnt mean its going to become a serious tool. We just had a story about "Stupid Projects From The Stupid Hackathon"[1], just because its not a serious tool doesnt mean we should be throwing the hate, lets just take it for what it is, a bit of fun and a project you do because you can.
The problem with whimsical projects is that eventually people make things in them thinking they are serious, and then other people have to maintain said things.
well, some people would argue javascript is [still] a mess. Douglas Crockford has spent a career pointing out a lot of the weak spots (while still loving the language mind you). PHP started out as a non-serious project, and today it's had some serious problems (multi-threading to name one).
However, on the other hand, there are also projects that start out as non-serious and get serious quick - the Linux kernel comes to mind.
I guess it can go two ways, but I'd contend a project that is started out with short-cuts because the author doesn't anticipate or plan for it to scale, will have a much tougher time doing so.
This isn't a problem in 5.5+ if you know what you're doing. That the language has a lot of people with no idea what they're doing is a testament to the fact PHP is easy to use and most others aren't for a novice, not that the language sucks.
I'm not the biggest PHP fan but since 5.3 most of the criticisms are unwarranted.
No PHP was not created as "stupid project" (meaning knowingly not a good idea), it was a very real project for Rasmus meant for his own webpages and after with a few other people. He merely didn't expect so many people to start using too.
Originally he was not creating a language, but a set a scripts for common features.
Well, it's the responsibility of the people who think some implementation requires this library to maintain it themselves, and as such whether or not that secondary implementation is intractable or not shouldn't really have any bearing on evaluation of OP's project... I could agree with this precautionary argument if somehow you were being forced to create/maintain such an application (for your job or something), but otherwise there's no difference.
>Can i just say that clearly everyone knows its not the best tool for an actual serious project, but theres nothing wrong with whimsy.
Besides it just starting and not having a big community atm, I don't see nothing "clear" about it now being "the best tool for an actual serious project".
Is it the "eww PHP" knee-jerk reaction some people have?
This is really cool. We have a few internal automation scripts built with PHP but its a pain to train non-technical users on using the command line. This would make it very easy to create a simple UI and make those tools more accessible, not to mention easier to bundle and distribute.
I agree.
I inherited some perl scripts around my work, and getting users up and running on them is kinda a pain (plus playing find the cpan depenency...)
New functionality is in php on the internal site which makes distributing better. Another way to distribute tools though is not a bad thing.
When it said "GUI framework", I kind of expected a way to make cross-platform apps with their native UI controls, not a web view with an embedded PHP executable.
Can you list some native UI controls that you'd like to use but can't recreate in HTML? I am writing a similar framework and would like to know the use-cases for doing this.
You can recreate almost anything in css/html but you'd have to write a different style for each OS yourself, and it will never match the actual "feel" of the UI. It'll be a little off.
Also, for example Mac OS X has lots of little widgets like the share button.
Maybe someone could make a Bootstrap-like project for these kinds of things?
I recently spent an afternoon trying to get a webapp to accept drag and drop emails from outlook. I didn't manage. I am considering making a native app to interact.
I can see this being pretty useful for utility type apps on the desktop. If you already have a lot invested in PHP then it seems like it would be really comfortable. Since it's basically just running a local server, it's going to be just like writing a web app except (I assume) with access to the local file system and system calls.
There's a few comments here about using native GUI widgets and such but I think that's a tricky approach. Dealing with long-running state of a native app seems very un-PHP. I consider myself fairly experienced with PHP but I'm not familiar with creating background threads with PHP which you'd need for a responsive GUI.
My greatest fear with all of these various wrapper frameworks is that they become abandoned. With a node.js/Javascript one at least there are several out there and the code is likely to be portable from one to the next. With this PHP one, you'd be committed to Nighttrain.
There is pthreads, PCNTL on posix systems, and Semaphores. The Implementation is pretty basic, but it works. The main issue are no native framework bindings other than the very old PHP-GTK... (edit, just read about wxPHP and QT...whoops)
Honestly, I still have a soft spot for PHP, mainly because its so easy to develop small things quickly. I'd love to see it move into other applications, much like JavaScript has...but the world is against the language, so I dont see that happening.
A cool. I knew there was some type of thread support. I figured most PHP devs would be more comfortable with the short running "page" concept rather than diving into threads and long-running stateful apps.
Anyway, I feel the same way about PHP. It's simple and easy and if you use it for the right job then it just works great. I think a lot of the hate is based on old, sloppy PHP code. Modern PHP apps are organized and use frameworks that don't look radically different from more popular languages.
The problem with things like pthreads in PHP is that 98% of the time your runtime is via mod_php5, and spinning threads off of an Apache worker instance is one of the worst ideas imaginable.
I (once, ignorantly) tried to do some kind of super lightweight background-like worker with pthreads in PHP instead of bringing in a full queue and worker design and it turned out that there is absolutely 0 capability of doing it with the slightest hint of sanity. Having libraries like that is cool, but it's not for what PHP was designed for: web pages. Arguably and controversially, web applications are even a stretch for the language, but the support is and has been getting better with actual classes, namespaces, and tooling support like Composer and agreed-upon libraries like Doctrine. Then again, I just fled a company who's entire infrastructure was dependent on cronjobs running tasks using relational databases as queuing mechanisms with very little use of ORMs. It doesn't really matter if the language gets better, because the bar isn't really getting raised, unfortunately. After making the language more desirable (which has been done), a community effort needs to be made to shame and call out bad code, which might end up requiring a jump to 6.0 finally and breaking backwards compatibility with everything that's changed since 4.x (mysql_escape_string, mysql_x instead of mysqli_x or PDO, etc.) At least non-parseable code isn't going to fester bad practices.
yea that is kinda what I was thinking as far as why native GUI widgets wouldn't be a good idea - because that leads down the path of long-running stateful UI process which I think is very un-PHP in lots of ways!
First it's not a GUI Framework,it's a webview that uses a Python GUI framework with a PHP server. I bet one could create the exact same tool on top of node-webkit,since you'll be basically running a server.
The hell,you could do the exact same stuff with next to no "serverside" javascript by launching a PHP server yourself in node-webkit,with the advantage of using a better webview because i'm pretty sure the one used in wxPython is pretty old.
HTML/CSS is a GUI framework and besides you said it yourself:
Python GUI framework with PHP "bindings"
I don't think you should be dismissive of what the OP has done. You clearly believe this should be done differently. If that's the case I encourage you to spend your time and effort to do so just as the OP did. And then be brave enough to post your work on HN just as the OP was.
I don't understand why this would not be a good idea for some of the commenters here. It can be useful to develop something for the desktop without learning c++ or c# (even if c# is rather easy), Adobe Air is not a solution of course. Yes it's a webview but how many developers know how to create a web app ? More than c#/c++/java/...
I enjoy projects like this (and others like node-webkit and cordova) because it lets me build prototypes relatively quick for my company (an ad agency). I'm strongest in HTML/CSS/JS and PHP so I don't have to spend time learning another language for something that is meant to be a demo anyways. I always tell them that if they want to get serious with one of the prototypes that we'd have to look into doing it the proper way. Although sometimes a project can be simple enough to just continue using it.
node-webkit lets me fiddle with the chrome + i have the ability to install packages with npm.
I can see this being used in internal systems (to replace command line commands for non-technical colleges) but can't see the value in actual end user products
As people are noting, there are other GUI toolkits for PHP. In fact there is growing interest in using PHP for more than just web apps, and I think this is only going to increase as PHP develops further as a general purpose language, and more and more non-web libraries mature. Then again I may be biased [1]
I think the title is a bit misleading; proper GUI frameworks currently available for PHP are wxPHP (working, and you may export PHP code from wxFormBuilder), Qt (experimental, I think) and GTK (probably abandoned).
I wish there was something like this for Haskell :(... Currently I'm aware of threepenny-gui[0], but that launches in the actual browser (correct me if I'm wrong), which isn't exactly what you'd want.
I should maybe add that the main reason I posted this project to HN was I noticed they need a push, i.e.: contributors.
Oh, yeah, about the submission title, I couldn't find anything that described it better, even after a lot of head scratching. No, I'm not eloquent, I know... ;)
This is a good project, it opens the desktop platform to PHP developers.
I am no fan of PHP myself and for this kind of requirement I would use node-webkit which provides seamless integration of the webview and host JS (node.js)
But the most important thing here is that it opens the doors to desktop programming to PHP devs and therefore we may see more useful apps for the desktop being developed, previously some PHP devs may have had some interesting concepts for the desktop but they weren't able to make them happen due to their lack of skills or time to learn GUI programming.
I shuddered when I saw this. It was like looking at the inverse of Java Applets. While interesting as a flight of fancy for the developer; I would hope a real GUI toolkit would be used for a serious application.
This is really a good question. I haven't done any native GUI in quite some time, but last time I did Qt and WxWidgets were sort of "top tier" for cross platform. Are people still largely on these, are are there better alternatives now?
> Create your next OS X, Windows or Linux desktop application in pure PHP
No, thank you.
More specifically, I spent last Saturday setting up PocketMine (a Minecraft server) for my kids. This remarkable piece of engineering is a console app done completely in PHP and one of the first things it logged was "Can't keep up! Is the server overloaded?". That's a completely idle server on a beefy box. And all I could think was how regrettable it was that a clearly capable programmer voluntarily painted himself in a corner by picking a language that wasn't fit for the job. Same thing with GUI in PHP - yes, it's doable, yes, there's probably a demand for it, but this demand is misplaced and misguided and it's not worth of endorsing. It's like giving devs a heavier weight to sink deeper into a tar pit instead of giving them a rope for getting out. Desktop apps should never ever be written in PHP unless it's some sort of quick and disposable hack, which is likely not what this project has in mind.
I understand that. It's a clever and elegant hack and I appreciate it, but ultimately it is not a viable cross-platform desktop app development option, which is, however, what it says on a tin.
That is, I have a problem with the labeling, not the contents.
the "Can't keep up!" error is common in a regular minecraft server, so it may not have as much to do with the fact that pocketmine was written in php. Although, i could be completely wrong about this (probably).
Nope, you're not wrong. That's part of minecraft and had nothing to do with PHP. I have a 200 meg server.log file that was run on a dedicated server, and in it there are 570,000 lines that say that -- out of 2,461,927. In other words, 23%.
[1] https://news.ycombinator.com/item?id=8621886