There is a good reason for the PHP not working out of the box. With Nitrous you have to choose the type of Box you want - in this case, it would be PHP. But with Codio, a Box is a Box with everything you need. Which means you are not restricted as to what you can use it for.
Check out the docs on using PHP in Codio https://codio.com/s/docs/specifics/php/, but it's a simple matter of `parts install php5 php5-apache2 && parts start apache`, and you're up and running.
There are a lot of advantages to coding in your browser. You mentioned just one of them. But primarily it means you have no stack to install and configure, as Codio Boxes provide all that for you. Also, you will find that server development is much faster, as the connection between Codio Boxes and the internet is much faster than that of your desktop.
Other advantages include collaboration, teaching/learning, and of course no need to install or keep anything updated on your desktop - other than your browser of course.
A number of them, but Pascal is a rare enough inclusion to have made me try it out — only to find that it shouldn't have been included in the list of supported languages, because it's not. Better to list fewer features but implement them well, in my opinion.
I understand where you are coming from, but its difficult to decide when such a feature becomes a feature. We have syntax highlighting for Pascal, so you could argue that we support it, but of course, there is a lot more that we could do to make Pascal devs lives easier and more fruitful.
quite a strange take, IMO. i guess you could just as easily claim "Support for over 60 languages out of the box" by integrating Codemirror [1], though i would consider this to be quite disingenuous.
without singing up, it's hard to say how much is there, but autocomplete, some form of function & class list and a syntax checker / linter would be a minimum to claim any form of language support in the context of an IDE.
Chrome's internal code editor may be good for editing client side code, but its no good for server-side code. Codio provides a full-stack server-side dev environment. So it's much more of an IDE than Chrome will ever be.
The reason is that Github does not always pass on your email to us, and we need to be able to contact you. Also, your Github username is not always available on our system, so you have to verify or choose a different one, as someone else may already be using it on our system.
Thank you for your clarification. Yet I wish more app creators would understand how I feel about these things (others might think so too):
You don't ever need to contact me unless it is for confirming accounts, which you don't have to, because I just oauth-handled you one. Username collisions could be handled by suggesting mangled or decorated names but aren't really the issue here. I am way more concerned about my email address.
It is not to be treated as a commodity and I hate the follow-up emails that I immediately receive, each and every one of them.
I understand the concerns that cause this behavior and believe it can be quite hard on today's market, so "hooking" in users by getting their email address might seem necessary. Yet I feel strongly about the whole thing. I don't want to give out email addresses and oauth is an appropriate way of handling identity and access. Not only is asking for an address redundant but it's encroaching. Maybe without this barrier you could improve the bounce rate.
It's funny how many comments we've had about the music on our video. I wasn't sure at first, but Freddy, our CEO chose it so didn't want to upset him ;)
Check out the docs on using PHP in Codio https://codio.com/s/docs/specifics/php/, but it's a simple matter of `parts install php5 php5-apache2 && parts start apache`, and you're up and running.